Некоторые баги клиента и сервера

Новый комментарий
 
В процессе написания эксперта обнаружилось несколько багов в клиентской части и в серверной части.... А также есть пожелание к модификации функции, чтобы логика отрабатывалась четче. Итак

Клиент:
1. Функция int DayOfYear( ) возвращает неверное значение дня года при переходе на новые сутки. Если я запускаю терминал скажем 14.06.06 и не выключаю его несколько суток то возвращаемое значение всегда будет к примеру 165. Создается впечатление что терминал вычисляет это значение один раз при инициализации переменных и больше не пересчитывает его.
2. Функция bool IsConnected( ) некорректно работает при временных обрывах связи. После восстановления связи поток котировок возобновляется, терминал разрешает открывать ордера, состояние соединения в статусбаре терминала - ОК, но функция isConnected() продолжает выдавать false. Помогает только релогин.

Сервер:
1. Проблемы с установкой ордера где TP=STOPLEVEL. в большей половине случаев возвращается ошибка №130. Хотя некоторые ордера проходят. Хотелось бы внести определенность в поведение сервера при данных условиях.
2. Сервер разрешает выставлять ордера с SL<STOPLEVEL вплоть до SL=PRICE и ордер моментально закрывается или зависает. Возможно это не баг а настройки сервера. Просьба объяснить.

Пожелания:
1. Столкнулся со следующей ситуацией. Пытался реализовать трейлинг-стоп и одновременно выставлять ТП для ордера. Все работает чудесно пока расстояние до TP>STOPLEVEL. При достижении этого условия очевидно что я не могу изменять ордер и подтягивать стоп до самого достижения ТП. Это несколько неудобно и связано с реализацией функции OrderSend(). Она принимает одновременно новый SL и новый TP. Так вот желательно добавить проверку
if(oldTP != newTP) {
старый обработчик
}
else {
ничего не проверяем и ошибку 130 не возвращаем
}

Ведь на самом деле лоогично - я установил ТП давно когда рынок был далеко и менять его не хочу. Но реализация функции OrderSend() заставляет меня передавать старое значение ТП как новое и возвращает ошибку.

Просьба к разработчикам ответить возможно ли решение поставленных вопросов в следующих релизах программы.
 
Т.к. ответа от разработчиков нет, добавлю пост чтобы тема не потерялась :)
 
Еще одна ошибка в серверном ПО. Замечена при работе с различными брокерами поэтому не может объясняться настройками сервера.
Заключается в том что при выставлении ордеров с SL=STOPLEVEL+1 и TP=STOPLEVEL+1 иногда выдается ошибка №130. Единицу я прибавил потому что на форуме уже обсуждалась подобная тема и советовали к стоплевелу прибавить единицу. :) Только пожалуйста сейчас не советуйте прибавлять 2 :))))

Так вот насколько я понимаю эти ордера не выполняются потому что вероятно цена уходит немного а так как стопуровни очень близки к цене то выдается ошибка №130 хотя по всем правилам нужно выдавать ошибку №138!!! Иначе клиент не видит что цена изменилась и непонятно почему произошел отказ в обработке. Просьба пересмотреть приоритет выдачи номеров ошибок....
 
Это может быть из-за неправильной цены открытия.
Она ведь тоже должна быть на расстоянии STOPLEVEL+1
 
1. Мы много раз уже говорили, что эксперт работает на копии окружения. То есть копируются бид, аск, таймсерии, последнее известное время сервера. Функция DayOfYear работает с последним известным временем сервера (на момент старта эксперта или скрипта). Если хотите обновить это время, вызовите функцию RefreshRates

2. Вы используете датацентр?

3. Используйте STOPLEVEL+1. 2 прибавлять не надо.

Причём здесь ошибка 138? она у Вас возникнет при нулевом слиппаже.
 
1. Мы много раз уже говорили, что эксперт работает на копии окружения. То есть копируются бид, аск, таймсерии, последнее известное время сервера. Функция DayOfYear работает с последним известным временем сервера (на момент старта эксперта или скрипта). Если хотите обновить это время, вызовите функцию RefreshRates

2. Вы используете датацентр?

3. Используйте STOPLEVEL+1. 2 прибавлять не надо.

Причём здесь ошибка 138? она у Вас возникнет при нулевом слиппаже.


1. Спасибо понял
2. Не использую.
3. При STOPLEVEL+1 все равно иногда выдается ошибка №130. (Это я высказал предположение что она выдается в результате ухода цены и нужно выдавать №138 вместо №130)
 
3. При STOPLEVEL+1 все равно иногда выдается ошибка №130. (Это я высказал предположение что она выдается в результате ухода цены и нужно выдавать №138 вместо №130)

Цена ушла, но она попадает в диапазон слиппажа. Поэтому никакой ошибки 138 - реквота же нет.
А вот расстояние до стопа нарушилось.
 
3. При STOPLEVEL+1 все равно иногда выдается ошибка №130. (Это я высказал предположение что она выдается в результате ухода цены и нужно выдавать №138 вместо №130)

Цена ушла, но она попадает в диапазон слиппажа. Поэтому никакой ошибки 138 - реквота же нет.
А вот расстояние до стопа нарушилось.

В моем случае слиппаж равен нулю. Так что цена НЕ попадает в диапазон... И я получаю ошибку 130. Причем все расстояния до СЛ и ТП соблюдаются....
И я ведь не знаю про изменения цены поэтому с моей точки зрения сервер ругается на вполне корректный ордер.... Что посоветуете?
 
Если цена ушла но попадает в диапазон, то ордер откроется и ошибки нет...
Если же цена не попадает в диапазон, то нужно вернуть ошибку...
Т.к. клиент не знает об изменениях цены на сервере, то логичнее вернуть либо №135 (Price changed) либо №138 (Requote) но никак не №130 (Invalid SL or TP) потому как с точки зрения клиента все как раз валид... :)
Новый комментарий
Причина обращения: