Пишу класс для работы с рыночными данными. Есть вариант написать контроль котировок.
Суть в том, что бы проверить актуальность нового тика, т.к. последний пришедший тик последний вообще или нет. Понятно, что это перестраховка, но не помешает..
Думаю примерно так:
Тик же это не время, он приходить по-разному. Я так понимаю, можно грубо сравнить чтоб последний тик не старше чем, например, 5 секунд или чутка больше, ИНАЧЕ нужно принудительно актуализировать данные? В общем, интересно, кто как решал этот вопрос. Ведь нужно постоянно иметь при торговле актуальные котировки. А закачивать их нужно только в случае надобности, что бы не закидывать сервер лишним запросами и свои ресурсы тоже не расходовать на каждом тике.
Там и так последние цены, читаем справку
tick
[out] Ссылка на структуру типа MqlTick, в которую будут помещены текущие цены и время последнего обновления цен.
Там и так последние цены, читаем справку
tick
[out] Ссылка на структуру типа MqlTick, в которую будут помещены текущие цены и время последнего обновления цен.
Так читал же. А если обновление было не последнего тика, а раньше? Или практически не может быть такого что будет пробел в котировках? В справке же не сказано, что при вызове MqlTick будет принудительная подкачка. Я теоритически рассуждаю, что может быть обновление цен, например, минуту назад, если какой-то перебой в связи или ещё какой-то касяк. Тогда нужно понять, что произошла рассинхронизация. Как это тогда проверить?
Так читал же. А если обновление было не последнего тика, а раньше? Или практически не может быть такого что будет пробел в котировках? В справке же не сказано, что при вызове MqlTick будет принудительная подкачка. Я теоритически рассуждаю, что может быть обновление цен, например, минуту назад, если какой-то перебой в связи или ещё какой-то касяк. Тогда нужно понять, что произошла рассинхронизация. Как это тогда проверить?
У меня сделано так. С начала недели каждые 5 секунд проверяю, не начал ли ДЦ давать котировки. Как начнет, каждые 5 секунд последний момент прихода котировки по каждому инструменту фиксируется в памяти, а каждые 10 секунд делается проверка.
Если за последние 10 секунд не было обновления котировки ни по одному из нужных инструментов ни в одном из обрабатываемых ДЦ, это расценивается как разрыв связи со всеми ДЦ. У меня их много, если их до 10, лучше ослабить это требование до 30 секунд.
Если 60 секунд не было тиков от одного ДЦ - это разрыв связи с ним одним.
По каждому инструменту границу не выставляю, необходимости не увидел. Учитываю лишь в торговле, если они есть, требования ДЦ считать котировку "запоздавшей" и не торговать по ней. Встречались значения 30 и 120 секунд. Вообще-то это редкость.
Проверить разрыв связи с ДЦ (по протоколу TCP) средств не знаю. Вероятно, потому, что их не может быть, ведь каждая такая проверка будет добавлением в трафик, долбить адресат лишними запросами нехорошо. Во всяком случае, попытки даже получить пинг по крайне легкому, минимально нагружающему сеть и вообще не нагружающему приложения протоколу ICMP от серверов Metatrader не удавались. Вероятно, эта функция сетевого оборудования заблокирована MQ.
Статистика примерно такая: при сборе тиков по 25 инструментам с 37 ДЦ за позапрошлую неделю был 991 разрыв связи с одним ДЦ и 34 разрыва связи со всеми ДЦ одновременно. Напоминаю, что это были разрывы потоков котирования именно по моим ограничениям выше. Был рисунок https://www.mql5.com/ru/forum/221552/page123#comment_6305833 с характеристиками по всем ДЦ и всем инструментам, но сейчас он почему-то исчез. Наверное, модераторы нашли в приведении технических данных рекламу ДЦ, хотя ни один не упоминался.
У меня сделано так. С начала недели каждые 5 секунд проверяю, не начал ли ДЦ давать котировки. Как начнет, каждые 5 секунд последний момент прихода котировки по каждому инструменту фиксируется в памяти, а каждые 10 секунд делается проверка.
Если за последние 10 секунд не было обновления котировки ни по одному из нужных инструментов ни в одном из обрабатываемых ДЦ, это расценивается как разрыв связи со всеми ДЦ. У меня их много, если их до 10, лучше ослабить это требование до 30 секунд.
Если 60 секунд не было тиков от одного ДЦ - это разрыв связи с ним одним.
По каждому инструменту границу не выставляю, необходимости не увидел. Учитываю лишь в торговле, если они есть, требования ДЦ считать котировку "запоздавшей" и не торговать по ней. Встречались значения 30 и 120 секунд. Вообще-то это редкость.
Проверить разрыв связи с ДЦ (по протоколу TCP) средств не знаю. Вероятно, потому, что их не может быть, ведь каждая такая проверка будет добавлением в трафик, долбить адресат лишними запросами нехорошо. Во всяком случае, попытки даже получить пинг по крайне легкому, минимально нагружающему сеть и вообще не нагружающему приложения протоколу ICMP от серверов Metatrader не удавались. Вероятно, эта функция сетевого оборудования заблокирована MQ.
Статистика примерно такая: при сборе тиков по 25 инструментам с 37 ДЦ за позапрошлую неделю был 991 разрыв связи с одним ДЦ и 34 разрыва связи со всеми ДЦ одновременно. Напоминаю, что это были разрывы потоков котирования именно по моим ограничениям выше. Был рисунок https://www.mql5.com/ru/forum/221552/page123#comment_6305833 с характеристиками по всем ДЦ и всем инструментам, но сейчас он почему-то исчез. Наверное, модераторы нашли в приведении технических данных рекламу ДЦ, хотя ни один не упоминался.
Да никто ничего не стирал. Вот этот пост.

- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Пишу класс для работы с рыночными данными. Есть вариант написать контроль котировок.
Суть в том, что бы проверить актуальность нового тика, т.к. последний пришедший тик последний вообще или нет. Понятно, что это перестраховка, но не помешает..
Думаю примерно так:
Тик же это не время, он приходить по-разному. Я так понимаю, можно грубо сравнить чтоб последний тик не старше чем, например, 5 секунд или чутка больше, ИНАЧЕ нужно принудительно актуализировать данные? В общем, интересно, кто как решал этот вопрос. Ведь нужно постоянно иметь при торговле актуальные котировки. А закачивать их нужно только в случае надобности, что бы не закидывать сервер лишним запросами и свои ресурсы тоже не расходовать на каждом тике.