OnTradeTransaction
Интересует ответ разработчиков - почему событие OnTradeTransaction не гарантированно ?
Наверное разработчики уже устали отвечать. Попробую ответить за них: OnTradeTransaction не может быть гарантированно по определению, т.к. оно является событием. Даже если событие гарантированно отсылается, гарантированно принять его нельзя. Представьте что в момент отсылки события пользовательский терминал выключится или разорвется соединение с интернетом - событие не сможет быть обработано. Вероятность этого конечно низка, однако не исключена.
Вместо того, что бы анализировать события, необходимо анализировать состояние торгового окружения, и только если торговое окружение изменилось принимать нужные решения. OnTransaction можно использовать только в очень ограниченных случаях, и как правило в своей работе лучше обходится вообще без него. Посмотрите на MetaTrader 4, в нем нет OnTransaction и все прекрасно обходятся без него.
Наверное разработчики уже устали отвечать. Попробую ответить за них: OnTradeTransaction не может быть гарантированно по определению, т.к. оно является событием. Даже если событие гарантированно отсылается, гарантированно принять его нельзя. Представьте что в момент отсылки события пользовательский терминал выключится или разорвется соединение с интернетом - событие не сможет быть обработано. Вероятность этого конечно низка, однако не исключена.
Вместо того, что бы анализировать события, необходимо анализировать состояние торгового окружения, и только если торговое окружение изменилось принимать нужные решения. OnTransaction можно использовать только в очень ограниченных случаях, и как правило в своей работе лучше обходится вообще без него. Посмотрите на MetaTrader 4, в нем нет OnTransaction и все прекрасно обходятся без него.
В мт4 изза отсутствия неттинга вообще гораздо проще управлять позициями в отличие от мт5 ,поэтому там от OnTransaction ни холодно ни жарко.
Т.е. событие не гарантированно только из-за технических соображений ? Если всё работает, значит терминал должен 100% это событие гарантировать ?
В мт4 изза отсутствия неттинга вообще гораздо проще управлять позициями в отличие от мт5 ,поэтому там от OnTransaction ни холодно ни жарко.
Т.е. событие не гарантированно только из-за технических соображений ? Если всё работает, значит терминал должен 100% это событие гарантировать ?
Неттинг никак не влияет на необходимость OnTradeTransaction.
На второй вопрос только сами разработчки смогут ответить. Замечено лишь, что OnTrasaction работает крайне стабильно. Потери в получении события выявлены не были.
Неттинг никак не влияет на необходимость OnTradeTransaction.
Неттинг влияет на учёт позиций и именно из-за него столько проблем с таким простым вопросом, а OnTradeTransaction нужен также для учёта позиций.
В мт4 изза отсутствия неттинга вообще гораздо проще управлять позициями в отличие от мт5 ,поэтому там от OnTransaction ни холодно ни жарко.
Т.е. событие не гарантированно только из-за технических соображений ? Если всё работает, значит терминал должен 100% это событие гарантировать ?
Разработчики выбирают приоритетные свойства продукта. Приоритетным свойством МТ4 была простота работы c MQL4.
У МТ5 очевидным приоритетом первого уровня является скорость (и гибкость). Нельзя получить все характеристики продукта на максимуме. Это противоречит теории.
Самый шустрый продукт неизбежно будет требовать от клиентского программиста намного больше (знаний, опыта и усилий).
Бог с ними, с этими техническими проблемами. Давайте рассуждать трезво.
Допустим, вы разрабатываете MT5 и перед Вами стоит задача: написать HFT-блок для торговых действиях.
С одной стороны от сервера в очередь поступают записи о транзакциях, с другой стороны эти записи надо передать в XXX-эксперт.
В XXX-эксперте, внутри обработчика OnTradeTransaction(), у юзера может быть любая "порнография"!
Абсолютно непонятно сколько эта функция будет выполняться.
В очереди могут скапливаться сотни записей поступивших от сервера, но ещё не переданных XXX-эксперту.
Что в этой ситуации можно гарантировать? Скорость или полноту данных?
А есть ли вообще смысл "складировать" глубоко устаревшую информацию для функции, которая по своей сути способствует только HFT?
Ребята!
Читаю и удивляюсь...
OnTradeTransaction позволяет не "копаясь" ни где, получать САМУЮ оперативную информацию
по ордерам и сделкам!
Просто Вы не умеете пользоваться этой функцией.
Ребята!
Читаю и удивляюсь...
OnTradeTransaction позволяет не "копаясь" ни где, получать САМУЮ оперативную информацию
по ордерам и сделкам!
Просто Вы не умеете пользоваться этой функцией.
Вы тоже не умеете. Уже десятки страниц на тему OnTradeTransaction понаписали, а одного так и не поняли: OnTradeTransaction сервисная функция для решения узкоспецифических задач, использовать ее в торговле, как делаете это вы нельзя. Разные умники поначитаются ваших опусов, а потом подобные темы создают: "Почему, видите ли, OnTradeTransaction не гарантированно" - да потому что, эксперт не должен создавать свое торговое окружение через OnTradeTransaction, как делаете это Вы, а опираться только на то, что есть в системе, конкретно в истории ордеров и сделок.
С одной стороны - да. А с другой стороны: как быть в тех случаях, когда запрос отослан на сервер, но операция еще не выполнена? Как определить, в каком состоянии мы находимся, если оперировать только списком ордеров и позиций (и историей счета)?
В МТ4 такой проблемы нет, т. к. все торговые операции там синхронные. Но в итоге получаем меньшее быстродействие.
С одной стороны - да. А с другой стороны: как быть в тех случаях, когда запрос отослан на сервер, но операция еще не выполнена? Как определить, в каком состоянии мы находимся, если оперировать только списком ордеров и позиций (и историей счета)?
В МТ4 такой проблемы нет, т. к. все торговые операции там синхронные. Но в итоге получаем меньшее быстродействие.
Если время между отправкой приказа и наступлением следующего сигнала на вход в рынок превышает время исполнения ордера, то ничего делать не надо. Логика здесь проста: отправили асинхронный приказ, вышли из потока и забыли о нем. Ждем следующего момента проверки сигнала. Если к этому моменту торговое окружение не изменилось - эксперт снова ищет сигнал на вход и повторяет приказ на вход в рынок. Если же наоборот, все прошло удачно, и приказ исполнился, эксперт, проанализировав окружение, поймет, что у него есть позиция, и повторно открывать новую позицию не будет. Т.е. в данном подходе, состояние эксперта гарантировано соответствует состоянию рыночного окружения.
Сложнее дело обстоит в высокочастотном трейдинге, где новый сигнал может наступить через время сопоставимое с исполнением приказа (6-100 мсек). В этом случае без блокировки не обойтись. Эксперт должен запомнить время последней отсылки приказа. Если в OnTransaction пришла какая-то ошибка, то блокировка сбрасывается и эксперт снова может выполнять торговые действия.
Замечу, что OnTradeTransacton, на который так многие любят молиться, ни как не помогает при HFT. Новый сигнал на вход может поступить быстрее чем приход ответа о успешном выполнении транзакции в OnTradeTransaction. Блокировка необходима не зависимо от того, используете Вы OnTradeTransacton или нет.
Как же Вы спросите контролировать ошибки, вылезающие в OnTradeTransaction? На это можно ответить встречным вопросом: Как Вы измените торговую логику эксперта на лету при получении ошибки? - Никак. Ошибки возникают если до этого не делать соответствующих проверок (наличие денег, кол-во объема и т.д. и т.п.). Но если она возникла, исправить Вы уже ничего не сможете. Поэтому лучшее что можно сделать в OnTradeTransaction, это вывести эту ошибку в лог (что бы потом исправить логику эксперта), и сбросить блокировку, если она используется. Для этого и ничего другого, OnTradeTransaction и нужно использовать.
Сейчас понабегут разные адепты Микаласа и начнут закидывать меня помидорами - пусть. Но я повторял и буду повторять, что надежная торговая логика может быть организована только если основывается на торговом окружении терминала. Все остальное - не работает.
Интересует ответ разработчиков - почему событие OnTradeTransaction не гарантированно ?
OnTradeTransaction есть результат ответа сервера на запрос OrderSendAsinc.
Сама функция OrderSendAsinc асинхронная, что указано даже в названии. Это означает что функция запульнула в сервер запрос и вернула ответ программе о результатах отправки (удалась ли отправка или нет).
То есть по принципу петух пропел а там хоть и не рассветай. Именно поэтому ответ сервера в OnTradeTransaction не гарантирован. Мало ли чего там может случиться.
Есть две подобные функции OrderSend и OrderSendAsinc.
Первая синхронная и молча ждёт ответа от сервера сколько бы времени ни понадобилось (возвращает результат обработки сервером запроса).
Вторая асинхронная она не ждёт ответа сервера, а сразу возвращает результат операции (но возвращает не результат обработки запроса, а результат был ли запрос отправлен серверу удачно).
OrderSendAsinc просто необходим в случае когда решения нужно принимать быстро. Тесты показывают что OrderSendAsinc запросто справляется с отправкой сотни запросов в секунду (но эта скорость обусловлена тем что она не ждёт ответа сервера).
Именно для приёма "запоздалого" ответа терминалом и генерируется событие OnTradeTransaction (запоздалого условно, тк прога пошла дальше а не синхроном получила ответ, на самом деле счёт запаздывания на секунды и миллисекунду).
Отличием от работы OrderSend ещё в том что OnTradeTransaction может генерироваться по одному ордеру несколько раз, сообщая терминалу вновь поступившую информацию об обработке запроса сервером. Это означает что в OnTradeTransaction мы видим этапы обработки ордера.
Ордер принят сервером OnTradeTransaction
Ордер поставлен в очередь OnTradeTransaction
Ордер ... OnTradeTransaction
Ордер ... OnTradeTransaction итд
Для точной идентификации по какому ордеру пришёл ответ в событие OnTradeTransaction все события кроме первого события по ордеру подписаны тикетом.
Первое событие подписано и тикетом и request_id. request_id пользователь получает сразу после отправки ордера от функции OrderSendAsinc. Таким образом происходит связывание конкретной итерации OrderSendAsinc и результатов получаемых в OnTradeTransaction.
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования