Очерёдность приходящих транзакций
Печатайте все транзакции, тогда будет видна связь.
Статья С чего начать при создании торгового робота для Московской биржи MOEX. "... вы можете запустить на своем счете советника TradeTransactionListener.mql5, который просто слушает события TradeTransaction и выводит краткую информацию по ним: ... "
Внимательней надо читать документацию.
- www.mql5.com
Печатайте все транзакции, тогда будет видна связь.
Так я все и печатаю. Код выше же привёл. Там нет фильтров.
Статья С чего начать при создании торгового робота для Московской биржи MOEX. "... вы можете запустить на своем счете советника TradeTransactionListener.mql5, который просто слушает события TradeTransaction и выводит краткую информацию по ним: ... "
У меня же и так всё пишется, к чему другие какие-то советники?
Внимательней надо читать документацию.
Судя по всему, косяк именно в этом. Приходят транзакции не в том порядке, в котором испольняются события. Хотя, это странно, я бы сказал. Порядок исполнения событий определённый и здесь без вариантов. Как говорится, яйцо курицу не снесёт. Так и здесь, ордер не будет принят, пока он не пройдут все проверки требуемые. Поэтому как получается разбежка в возврате сервером данных хаотичная это очень даже странно. Буду знать, что ж ещё сказать..
Судя по всему, косяк именно в этом. Приходят транзакции не в том порядке, в котором испольняются события. Хотя, это странно, я бы сказал. Порядок исполнения событий определённый и здесь без вариантов. Как говорится, яйцо курицу не снесёт. Так и здесь, ордер не будет принят, пока он не пройдут все проверки требуемые. Поэтому как получается разбежка в возврате сервером данных хаотичная это очень даже странно. Буду знать, что ж ещё сказать..
Я думаю здесь не большая потеря по сравнению с выигрышем скорости. Ведь если поставить чёткую очерёдность, то вообще отпадает смысл OrderSendAsync() а отсюда и
OrderSend() попадает туда-же.
Я думаю здесь не большая потеря по сравнению с выигрышем скорости. Ведь если поставить чёткую очерёдность, то вообще отпадает смысл OrderSendAsync() а отсюда и
OrderSend() попадает туда-же.
Вы не внимательно прочтали моё сообщение. Я не писал, что должна быть очередь исполнения или прихода данных о транзакциях в целом. Я имею ввиду, что если по факту тразакция конкретного тикета происходить в понятном порядке, например, ордер - сделки - позиция. То и приход данных об этой цепочке логично, что бы был таким же, а не хаотичных. Тоже самое, если состояние изначально ордера не определённое, а уже в финальной стадии ордер принят брокером, то должна в таком порядке и приходить информация а цепочке транзакций, а не наоборот.
Замечу, что на скорость эта никак не повляет. Ждать то не нужно синхронности. Асинхронно то всё-равно всё происходит. Но транзакция исполняется всё-равно синхронно, как ни крути. Не бывает такого. что бы ордер был принят изначально, а потом его состояние стало не определено. Это дичь.Вы не внимательно прочтали моё сообщение. Я не писал, что должна быть очередь исполнения или прихода данных о транзакциях в целом. Я имею ввиду, что если по факту тразакция конкретного тикета происходить в понятном порядке, например, ордер - сделки - позиция. То и приход данных об этой цепочке логично, что бы был таким же, а не хаотичных. Тоже самое, если состояние изначально ордера не определённое, а уже в финальной стадии ордер принят брокером, то должна в таком порядке и приходить информация а цепочке транзакций, а не наоборот.
Замечу, что на скорость эта никак не повляет. Ждать то не нужно синхронности. Асинхронно то всё-равно всё происходит. Но транзакция исполняется всё-равно синхронно, как ни крути. Не бывает такого. что бы ордер был принят изначально, а потом его состояние стало не определено. Это дичь.Да вроде нормально прочёл. Вот если представить, что выполняются не только ваши ордера... Все остальные должны ждать пока сервер отправит на терминал в определённой последовательности всю цепочку транзакций? А если вашим ордерам придётся ждать? Видимо начнём возмущаться скоростью исполнения.
Да вроде нормально прочёл. Вот если представить, что выполняются не только ваши ордера... Все остальные должны ждать пока сервер отправит на терминал в определённой последовательности всю цепочку транзакций? А если вашим ордерам придётся ждать? Видимо начнём возмущаться скоростью исполнения.
Да здесь суть не в этом. Принимать то можно неограниченное количество заявок. Суть в том, что ордер принят не может быть раньше, чем он поступил в обработку. Соответственно, что и приходить должно изначально в транзакции то, что он поступил в обработку, а не то, что он принят, а потом уже в конце он в обработке наконец то.. Понимаете? Это баг. На работу вроде как не влияет, по крайне мере, не замечено ещё косяков, но в плане понимания последовательности не получится выстроить цепочку, если не пошерстить форум и не почитать по этой теме.
Я к тому, что писало бы оно нормально, любой бы открыл терминал.. прогнал любой сов и поглядеть цепочку... - понял всё усвоил, и вопрос снять, даже без обмусоливания этих вещей, которые должны быть изначально понятны. Потому что я почитал вчера, и пришёл к выводу, что большинство форучан не догоняют вообще причины появления этой функции. Он до сих пор думают, что это нужно лишь при ассинхронной торговле. Это признак новичка. Ведь, и, в правду, кто не работал ни с чем, кроме как мкл, тому попробуй объясни что такое слушатель и вообще события. Я для себя решил, что это самый стабильный и быстрый, по крайне мере, теоритически, способ получать извещения и изменении состояния ордера или позиции, причём не важно, торговля ассинхронная или синхронная. Потому что иначе придётся порождать дополнителные циклы и переменные, что не есть хорошо, как в плане увеличенич размера кода, так и в плане скорости выполнения. Скорость нынче и так высокая, т.к. процы продвинулись прилично, а вот когда код визуально увеличивается в разы, это уже не есть хорошо, в плане сопровождения кода, если что..
Но вот проследить всю цепочку не получается. И это хреново. Есть кто-то со мной не согласен, предлагаю обсудить как можно проследить цепочку выполнения транзакции визуально..
... и пришёл к выводу, что большинство форучан не догоняют вообще причины появления этой функции.
Ну это уж совсем неправда.
Выделенная красным цитата из документации уже удалена в связи с исправлениями. Сейчас никакие транзакции не теряются.
- 2015.02.05
- www.mql5.com
Ну это уж совсем неправда.
Выделенная красным цитата из документации уже удалена в связи с исправлениями. Сейчас никакие транзакции не теряются.
Ну это уж совсем неправда.
Выделенная красным цитата из документации уже удалена в связи с исправлениями. Сейчас никакие транзакции не теряются.
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Решил я сегодня проверить всю цепочку приходящих транзакций. Если теоритически я всё это уже понимаю, но когда принтанул в журнале всё, я понял, что понимаю это иначе, а не так как есть, на самом деле.
Суть следующая.. Сова ставит 2 отложки в обе стороны. Отложки установились. Доходит дело до функции OnTradeTransaction(). Там вот такой код:
Вот, что в журнале вижу:
Выделенное жёлтым очень интересно и странно. Получается, что изначально, состояние ордера - принят:
Состояние ордера: ORDER_STATE_PLACEDА после состояние уже становится:
Состояние ордера: ORDER_STATE_STARTEDТ.е. ещё не принят. Это что за чушь? В тестере функция OnTradeTransaction() работает не корректно? Имею ввиду не работает даже, а возвращает данные.
Суть в том, что у меня всё работает правильно при торговле. Но вот выводит в журнал какую-то чушь. А я хотел проследить цепочку всю приходящих транзакций, что бы закрыть этот вопрос раз и навсегда.