Конец пакета. - страница 3

Новый комментарий
 
pronych:

Странно. А у меня даже сомнений не возникало, что он получает данные прямо из информационного центра вселенной. А-а-а... Ну надо же... куча настроек... посылать данные... Как всё интересно-то....

А что вы хотели, живя на окраине вселенной управлять всей вселенной ... ? = )))
 
Serj_Che:
А что вы хотели, живя на окраине вселенной управлять всей вселенной ... ? = )))

Пожалуй да, именно этого и хочу.

Чтоб меня иногда спрашивали - А что ты хочешь, Лёша?! И чтоб мой ответ был услышан.

Тогда будет гармония...

 
pronych:

Могу предположить, что данные с сервера терминал получает пакетами через определенные интервалы времени. В других платформах этот период можно даже задавать и как правило он составляет 30-100ms.

Обычно существует необходимость сначала принять весь пакет, обработать все события, а затем выполнить какой-либо расчет или принять решение на основе всех принятых параметров.

 Например, необходимо рассчитать в индикаторе некую величину по пятнадцати стаканам.  

В последнем пакете, на текущем временном срезе  пришло 5 обновлений из 15 используемых стаканов. То есть  5 событий.

Как экономно и в то же время без задержек построить алгоритм, чтоб обработать эти пять событий, и только потом уже рассчитать ту самую величину по всем пятнадцати стаканам?

Понятно, что такого события или флага как EndOfFrame тут не существует. А должен быть. Кто сталкивался, что придумать? 

Может разработчики подскажут или сделают такую возможность? 

Каким бы ни был протокол поверх TCP/IP данные все равно будут передаваться по TCP/IP, каждый пакет которого имеет фиксированный размер (см. RFC по TCP/IP). Более того, существует такая вещь как PING, проверка времени отклика сервера, так что 30-100 ms это при нормальных условиях нечто сверхъестественное для приема пакета. Еще более того, если вы работаете через прокси, время отклика будет еще больше...

 
elugovoy:

Каким бы ни был протокол поверх TCP/IP данные все равно будут передаваться по TCP/IP, каждый пакет которого имеет фиксированный размер (см. RFC по TCP/IP). Более того, существует такая вещь как PING, проверка времени отклика сервера, так что 30-100 ms это при нормальных условиях нечто сверхъестественное для приема пакета. Еще более того, если вы работаете через прокси, время отклика будет еще больше...

Ваще безразлично какой протокол на нижнем уровне, хоть nrz... Важен только верхний.

Суть в том, что биржа транслирует дату, как я понимаю, порциями, и с определенным периодом. И  количество стаканов  в каждой  порции мы не знаем. Потому что приходят только изменения начиная с предпоследней отправленной порции. Но если знать, что происходит последнее событие текущей порции, то все глобальные расчеты можно делать именно в этот момент, в паузе между порциями.

По хорошему не нужно вообще никаких событий, кроме EndOfFrame, когда последний принятый пакет обновлен в структуре MT5. и тру-флажки на каждый стакан, обновления которого в нем пришли. Ну там инит/деинит еще...

А сейчас мы не знаем какое(от конца) событие из последнего пакета обрабатывается в текущий момент, по этому глобальные расчёты приходится выполнять в каждом BookEvent'e, каждого пакета. А их в нем может быть много больше одного (необходимых).

( пакет = пакет верхнего протокола = порция) ( стакан = BookEvent)

 

Грубо говоря, было бы удобней и быстрей в разы получить один BookEvent  на все стаканы   в одном пакете! 

 

void OnBookEvent()//
  {
   if((bool)SymbolInfoInteger(_Symbol, SYMBOL_BOOK_CHANGED){BookUpdate(_Symbol);}
   if((bool)SymbolInfoInteger(S1     , SYMBOL_BOOK_CHANGED){BookUpdate(S[0]);}
   if((bool)SymbolInfoInteger(S1     , SYMBOL_BOOK_CHANGED){BookUpdate(S[1]);}
   if((bool)SymbolInfoInteger(S2     , SYMBOL_BOOK_CHANGED){BookUpdate(S[2]);}
   GlobalBookUpdate(S);
  }

где 

SYMBOL_BOOK_CHANGED = признак, что стакан по символу был изменен  на последнем пакете

BookUpdate() и  GlobalBookUpdate(S)  свои функции для работы со стаканами

Идеальный вариант! Не надо никаких счетчиков!

 

pronych:

...

SYMBOL_BOOK_CHANGED = признак, что стакан по символу был изменен  на последнем пакете

Вообще мысль здравая. Но определить какому пакету принадлежит обновление стакана без дополнительной обвязки синхронизации со стороны разработчиков не получится.

OnBookEvent может вообще быть не первым на стеке. В этом случае если пришел новый пакет за время ДО определения какому пакету принадлежит обновление, теряются обновления предыдущих пакетов.

 

У нас нет никакой дискретности и все данные доставляются асинхронным потоком без таймаутов. Так было всегда с самой первой нашей платформы в 2000 году.

Поток котировок и стаканов цен платформы полностью зависит от исходного потока провайдера ликвидности. Причем в реальности на самом деле можно легко столнутся с ситуацией, когда провайдер шлет снепшоты стаканов дискретно, что практически не бывает у потоковых бид/аск цен.

 

 Кгхм... Тады понятно. Будем довольствоваться тем, что TheXpert признал мысль здравой... ))

Ренат, тогда последний вопрос по этой теме.

Откройте тайну, правильно ли я понимаю, что мт-сервер брокера  ФОРТС  получает стаканы дискретно и потом один за другим вереницей выпуливает их уже в моем направлении? и какой у них стоит период?

конкретно "открытие" интересует, боюсь такой вопрос донести их саппорту я буду не в силах))

 

pronych

1. Советую изучить протоколы Plaza II и FIX Московской биржи( кажется MT5 по FIX работает). 

2. Очень просто определять в каком стакане произошли изменения

void OnBookEvent( const string &a_symbol )
{
  if ( a_symbol == _Symbol )
  {
    //Смотрим изменения....
  }
}
 

И ещё...

Если Вы не хотите перебирать весь стакан и интересует только цена(без объёма),

то можно в приведённый выше код вставить:

double best_ask = SymbolInfoDouble( _Symbol, SYMBOL_ASK );
double best_bid = SymbolInfoDouble( _Symbol, SYMBOL_BID );
1234
Новый комментарий
Причина обращения: