OnTradeTransaction - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
С одной стороны - да. А с другой стороны: как быть в тех случаях, когда запрос отослан на сервер, но операция еще не выполнена? Как определить, в каком состоянии мы находимся, если оперировать только списком ордеров и позиций (и историей счета)?
В МТ4 такой проблемы нет, т. к. все торговые операции там синхронные. Но в итоге получаем меньшее быстродействие.
То, что асинхронные операции быстрее синхронных - миф, происходящий от не понимания происходящего. У асинхронных операций полный цикл совершения торгового действия разбит на несколько частей, в то время как у синхронной операции он один. Для асинхронной операции точно также требуется ответ сервера, исполнение на бирже происходит такое же, т.е. суммарно время занимаемое для асинхронной и синхронной операции практически одно и тоже. Преимущество асинхронных приказов - в возможности организации их параллельной отправки, т.е. можно отправить два и более приказа практически в одно и тоже время. Именно за счет этого и достигается высокая скорость работы (в сумме). Не для каждого эксперта требуется асинхронный режим отправки. В первую очередь, это необходимо разным арбитражерам, где требуется купить два и более инструмента одновременно, или HFT алгоритмам. Например HFT бот может отправить приказ на вход в рынок, а уже через 3-4 мсек, отдать противоположенный приказ, в этом случае дожидаться ответа от сервера о первом ордере - слишком долгая операция, поэтому для него требуется асинхронный режим отправки - без ожидания результата. В подавляющем большинстве экспертов такие скорости не нужны.
Вы тоже не умеете. Уже десятки страниц на тему OnTradeTransaction понаписали, а одного так и не поняли: OnTradeTransaction сервисная функция для решения узкоспецифических задач, использовать ее в торговле, как делаете это вы нельзя. Разные умники поначитаются ваших опусов, а потом подобные темы создают: "Почему, видите ли, OnTradeTransaction не гарантированно" - да потому что, эксперт не должен создавать свое торговое окружение через OnTradeTransaction, как делаете это Вы, а опираться только на то, что есть в системе, конкретно в истории ордеров и сделок.
И тут Остапа понесло....
Если у Вас есть личная неприязнь ко мне, то совсем не нужно выносить это в обсуждение
технических проблем, в которых Вы "сильно плаваете"...
Как раз Вы вводите людей в заблуждение своими напористыми терадами!
И тут Остапа понесло....
Если у Вас есть личная неприязнь ко мне, то совсем не нужно выносить это в обсуждение
технических проблем, в которых Вы "сильно плаваете"...
Как раз Вы вводите людей в заблуждение своими напористыми терадами!
Миша, привет! Как съездил на Формулу 1? Как погода в Сочи?
Привет!
Отлично! Купался в море (вода была 24 градуса).
Привет!
Отлично! Купался в море (вода была 24 градуса).
Круто, это очень теплая вода!
Если серьезно - ни каких претензий к тебе не имею. Если хочешь возразить по существу - welcome. Учить кого-то тем более нет желания. У каждого свой велосипед с квадратными колесами.
Если время между отправкой приказа и наступлением следующего сигнала на вход в рынок превышает время исполнения ордера, то ничего делать не надо. Логика здесь проста: отправили асинхронный приказ, вышли из потока и забыли о нем. Ждем следующего момента проверки сигнала. Если к этому моменту торговое окружение не изменилось - эксперт снова ищет сигнал на вход и повторяет приказ на вход в рынок. Если же наоборот, все прошло удачно, и приказ исполнился, эксперт, проанализировав окружение, поймет, что у него есть позиция, и повторно открывать новую позицию не будет. Т.е. в данном подходе, состояние эксперта гарантировано соответствует состоянию рыночного окружения.
Сложнее дело обстоит в высокочастотном трейдинге, где новый сигнал может наступить через время сопоставимое с исполнением приказа (6-100 мсек). В этом случае без блокировки не обойтись. Эксперт должен запомнить время последней отсылки приказа. Если в OnTransaction пришла какая-то ошибка, то блокировка сбрасывается и эксперт снова может выполнять торговые действия.
Замечу, что OnTradeTransacton, на который так многие любят молиться, ни как не помогает при HFT. Новый сигнал на вход может поступить быстрее чем приход ответа о успешном выполнении транзакции в OnTradeTransaction. Блокировка необходима не зависимо от того, используете Вы OnTradeTransacton или нет.
Как же Вы спросите контролировать ошибки, вылезающие в OnTradeTransaction? На это можно ответить встречным вопросом: Как Вы измените торговую логику эксперта на лету при получении ошибки? - Никак. Ошибки возникают если до этого не делать соответствующих проверок (наличие денег, кол-во объема и т.д. и т.п.). Но если она возникла, исправить Вы уже ничего не сможете. Поэтому лучшее что можно сделать в OnTradeTransaction, это вывести эту ошибку в лог (что бы потом исправить логику эксперта), и сбросить блокировку, если она используется. Для этого и ничего другого, OnTradeTransaction и нужно использовать.
Сейчас понабегут разные адепты Микаласа и начнут закидывать меня помидорами - пусть. Но я повторял и буду повторять, что надежная торговая логика может быть организована только если основывается на торговом окружении терминала. Все остальное - не работает.
Не совсем понятно, причем здесь время между возникновением сигналов? У каждого торгового сигнала есть свое время регистрации. После того, как сигнал зарегистрирован (возник), необходимо совершить торговую операцию. В итоге советник отсылает торговый приказ на сервер и работает далее. Приказ еще не исполнен сервером. Приходит новый тик. Советник заново анализирует свое состояние и выясняет, что имеется сигнал открытия, но среди рабочих ордеров нет соответствующей позиции (или ордера).
Вопрос: как советнику, не прибегая к данным от OnTrade или OnTradeTransaction, определить, по какой причине нет позиции? Причем причин может быть несколько:
1. Запрос на открытие отослан серверу, но сервер еще не дал ответ о результате выполнения приказа. Нужно ждать ответа.
2. Запрос еще не был отослан серверу. Нужно отослать приказ.
3. Запрос был отослан, пришел ответ от сервера о невозможности выполнения приказа. Нужно обработать сообщение об ошибке и принять решение о том, что делать далее.
4. Запрос был отослан, но сервер долгое время (каждый устанавливает это время сам, у меня - 1 минута) не отвечает (таймаут).
Я не вижу решения проблемы без использования OnTrade или OnTradeTransaction. Но Вы утверждаете, что оно есть. Поясните, какое. Потому как рассказывать про блокировки потоков в MQL4/5 странно - двух и более потоков здесь нет, есть только один поток. Кроме того, Вы оперируете выражениями "если все прошло удачно, и приказ исполнился", но вовсе не объясняете, как это было определено. А ведь именно в этом суть моего вопроса.
Не совсем понятно, причем здесь время между возникновением сигналов? У каждого торгового сигнала есть свое время регистрации. После того, как сигнал зарегистрирован (возник), необходимо совершить торговую операцию. В итоге советник отсылает торговый приказ на сервер и работает далее. Приказ еще не исполнен сервером. Приходит новый тик. Советник заново анализирует свое состояние и выясняет, что имеется сигнал открытия, но среди рабочих ордеров нет соответствующей позиции (или ордера).
Вопрос: как советнику, не прибегая к данным от OnTrade или OnTradeTransaction, определить, по какой причине нет позиции? Причем причин может быть несколько:
1. Запрос на открытие отослан серверу, но сервер еще не дал ответ о результате выполнения приказа. Нужно ждать ответа.
2. Запрос еще не был отослан серверу. Нужно отослать приказ.
3. Запрос был отослан, пришел ответ от сервера о невозможности выполнения приказа. Нужно обработать сообщение об ошибке и принять решение о том, что делать далее.
4. Запрос был отослан, но сервер долгое время (каждый устанавливает это время сам, у меня - 1 минута) не отвечает (таймаут).
Я не вижу решения проблемы без использования OnTrade или OnTradeTransaction. Но Вы утверждаете, что оно есть. Поясните, какое. Потому как рассказывать про блокировки потоков в MQL4/5 странно - двух и более потоков здесь нет, есть только один поток. Кроме того, Вы оперируете выражениями "если все прошло удачно, и приказ исполнился", но вовсе не объясняете, как это было определено. А ведь именно в этом суть моего вопроса.
Имеется в виду блокировка не потока, а блокировка отправки торгового приказа.
Встречный вопрос: предположим советник определил причину по которой торговый приказ не может быть исполнен (рынок закрыт, нет денег и т.п.) что дальше? Как советник исправит сложившуюся ситуацию? Добавит денег на счет или откроет рынок? Как знание причины ошибки отправки последнего приказа, поможет советнику торговать дальше?
Имеется в виду блокировка не потока, а блокировка отправки торгового приказа.
Вот здесь и вопрос: если сервер вернет ошибку исполнения приказа, то как об этом узнать, чтобы разблокировать возможность отправки повторного приказа? Опять же, если не используется OnTrade и OnTradeTransaction.
Встречный вопрос: предположим советник определил причину по которой торговый приказ не может быть исполнен (рынок закрыт, нет денег и т.п.) что дальше? Как советник исправит сложившуюся ситуацию? Добавит денег на счет или откроет рынок? Как знание причины ошибки отправки последнего приказа, поможет советнику торговать дальше?
Очень поможет. Недостаточность денег оставим, т. к. этот момент советник должен определить еще до отправки торгового приказа и уведомить трейдера сообщением (или каким-то другим способом). Соответственно торговый приказ вообще не отсылается.
Сообщение об ошибке может дать информацию о том, стоит ли вообще продолжать попытки отправки приказа. К примеру, если рынок закрыт, то не стоит тут же отсылать повторный запрос. Следует остановить торговлю на некоторое время (определяется разработчиком советника) и только потом вновь послать новый запрос (если еще действует торговый сигнал). Если же произошел реквот, то можно отослать новый запрос сразу же. Если произошла ошибка установки стопов (изменились Stop Level или Freeze Level за время отсылки приказа), то стопы корректируются соответственно новым данным и тут же отправляется новый запрос.
Так что знание торговой ошибки (а вообще - любой ошибки) и правильная ее обработка являются непременным условием работы любой "нормальной" программы.
Вот здесь и вопрос: если сервер вернет ошибку исполнения приказа, то как об этом узнать, чтобы разблокировать возможность отправки повторного приказа? Опять же, если не используется OnTrade и OnTradeTransaction.
Очень поможет. Недостаточность денег оставим, т. к. этот момент советник должен определить еще до отправки торгового приказа и уведомить трейдера сообщением (или каким-то другим способом). Соответственно торговый приказ вообще не отсылается.
Сообщение об ошибке может дать информацию о том, стоит ли вообще продолжать попытки отправки приказа. К примеру, если рынок закрыт, то не стоит тут же отсылать повторный запрос. Следует остановить торговлю на некоторое время (определяется разработчиком советника) и только потом вновь послать новый запрос (если еще действует торговый сигнал). Если же произошел реквот, то можно отослать новый запрос сразу же. Если произошла ошибка установки стопов (изменились Stop Level или Freeze Level за время отсылки приказа), то стопы корректируются соответственно новым данным и тут же отправляется новый запрос.
Так что знание торговой ошибки (а вообще - любой ошибки) и правильная ее обработка являются непременным условием работы любой "нормальной" программы.
Если рынок закрыт, то проверить это надо еще до отправки ордера.
В остальных случаях перечисленных Вами, торговый приказ следует отправить повторно. Таким образом, все ошибки можно разделить на две категории:
Если эксперт получил ошибку второго рода, его действия должны быть всегда одинаковыми и не зависеть от типа ошибки: а именно, он должен повторить свой торговый приказ, в надежде что на этот раз он исполниться. Контролировать же ошибки первого рода, эксперт должен еще до отправки торгового приказа. Следовательно, у эксперта нет необходимости корректировать свое поведение в зависимости от типа ошибки возвращаемой в OnTradeTransaction. Но в OnTradeTransaction можно писать о возникающих ошибках пользователю, а также сбрасывать блокировку на совершение новой торговой операции, если предыдущая торговая операция завершилась ошибкой второго рода. При этом, если OnTradeTransaction не наступит по каким-то причинам, блокировка все равно должна быть сброшена по таймауту. Таким образом, не будет иметь значение, приходит OnTradeTransaction или нет, просто с OnTradeTransaction повторные приказы будут выполнятся на максимально возможной скорости.
з.ы. FreezeLevel по-хорошему надо также анализировать до отправки приказа.