Функция OrderSendAsync() - страница 8
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Потому что битые пакеты, обрывы связи и т.п. хрень. Ненадежно. Ненадежно -- надо отвязываться.
На всякий случай сообщу, что очередь торговых транзакций для выдачи в экспертов мы будем держать и отдавать.
Разрывы связи на исполнении - это проблема, пока не понятно как их лучше разруливать. В любом случае, после реконнекта все открытые позиции можно будет проверить штатно.
Потому что битые пакеты, обрывы связи и т.п. хрень. Ненадежно. Ненадежно -- надо отвязываться.
Давай мухи отдельно, котлеты отдельно.
обрывы связи нештатная ситуация для терминала и должна обрабатываться исключениями, в том числе и через анализ истории.
Но парсить историю на каждом Trade слишком дорогое удовольствие. Приход Trade ведь штатная ситуация и должна обрабатываться малозатратно.
Здрасьте. Вкурсе вообще что такое асинхронность?
Насколько я понимаю, вводя такую функцию для мультивалютных советников (для моновалютных советников инициатива теряет смысл), преследуется одна единственная цель - экономия времени за счет отсутствия задержки исполнения ордера на стороне сервера. Поправьте меня, если не прав.
Кроме этого остается только один критический по времени участок времени - передача пакета данных по каналам связи. Пытаясь отодвинуть "границу неизвестности" до уровня "кинул (пакет) и побежал дальше", вы имеете больше проблем, чем выгоды. Важно оценивать проблему в комплексе. Возможный тайм-аут, если он был, скорее всего повлияет не только на возможность торговли по конкретному инструменту, но и, в принципе, на отсутствие связи с сервером.
Кроме того, непонятно, как оценивать из советника: был ли торговый приказ потерян при передаче данных, либо он столь долго ожидает своей очереди на сервере? А значит, будут ошибки с дублированием торговых приказов, что приведет к нарушению ММ и, как следствие, увеличению рисков. По-моему, мнению, любому профессиональному трейдеру (советнику) необходимо убедиться, что его торговый приказ принят к исполнению сервером. Более того, чтобы в последующем однозначно идентифицировать состояние конкретно данного торгового приказа (в функции OnTrade()), необходимо некое уникальное значение, полученное от сервера, чтобы по нему строилась дальнейшая обработка (до момента совершения сделки (открытия/закрытия позиции)).
По аналогии с сетевой моделью OSI. Не надо лезть в канальный или физический уровень исполнения торгового приказа. Пусть эту транспортную функцию выполняет клиент (MT5). Работайте на прикладном уровне.
экономия времени за счет отсутствия задержки исполнения ордера на стороне сервера. Поправьте меня, если не прав.
За счет отсутствия ожидания результатов запроса. В целом да. Т.е. для отложек и маркет исполнении может быть очень полезно.
Кроме этого остается только один критический по времени участок времени - передача пакета данных по каналам связи. Пытаясь отодвинуть "границу неизвестности" до уровня "кинул (пакет) и побежал дальше", вы имеете больше проблем, чем выгоды.
Ну... нет. Просто пользоваться этим надо тогда, когда выгоды перекрывают проблемы.
По-моему, мнению, любому профессиональному трейдеру (советнику) необходимо убедиться, что его торговый приказ принят к исполнению сервером.
Тогда вам асинхронный вариант не подходит. Все решаемо.
TheXpert
Давайте еще раз, на пальцах. Грубо структурируем задержки:
1. Время предварительной проверки торгового приказа терминалом, "упаковка" его в отправляемый пакет и постановка в "сетевую очередь".
2. Время передачи пакета данных, содержащего торговый приказ, от клиента до сервера.
3. Время получения торгового приказа сервером и постановка в пул обработки и отправки на клиент уникального идентификатора данного тикета.
4. Время предварительной обработки корректности торгового приказа и размещение на торговой площадке.
Если чего неверно указал, прошу поправить. Я так понимаю, Вы не хотите ждать после выполнения первого пункта? Я же выступаю за обязательное наличие первых трех.
Для дальнейшей дискуссии необходимо ответить на два вопроса:
1. Пропорциональное отношение задержек. Т.е. в среднем, сколько времени в процентах занимает каждый из четырех вышеуказанных пунктов. Если распределение будет, к примеру, "0,5%-1,0%-1,0%-97,5%", то овчинка выделки не стоит.
2. Тайм-аут и его влияние на торговую стратегию. Честно говоря, не могу назвать ни одной ТС, которая бы не требовала четкого понимания: приказ был отправлен на серверн или нет. Это актуально и для долгосрочников, и для мультивалютного арбитража. Т.е. гарантия исполнения торгового приказа не может быть поставлена под сомнение. Приведите, пожалуйста, контрпример, если Вы не согласны.
По моему, самый простой способ решить проблему исполнения при разрыве - не создавать очередь исполнения (аннулировать исполнение) и при реконнекте сообщить пользователю об аннулировании. В этом случае будет меньше двойственных ситуаций.
Нужно возвращать тикет сервера. Это и будет гарантией того, что приказ дошел до сервера и принят им к обработке.
Громоздя хитрые пулы ожидания на стороне клиента - не то что неизящное решение, я бы назвал это грубой ошибкой проектирования клиент-серверной архитектуры MT5.
Громоздя хитрые пулы ожидания на стороне клиента - не то что неизящное решение.
Это то, что просили. Никто не заставляет пользоваться, если не нужно.
TheXpert
Давайте еще раз, на пальцах. Грубо структурируем задержки:
1. Время предварительной проверки торгового приказа терминалом, "упаковка" его в отправляемый пакет и постановка в "сетевую очередь".
2. Время передачи пакета данных, содержащего торговый приказ, от клиента до сервера.
3. Время получения торгового приказа сервером и постановка в пул обработки и отправки на клиент уникального идентификатора данного тикета.
4. Время предварительной обработки корректности торгового приказа и размещение на торговой площадке.
3 лучше разделить
3.1 постановка
3.2 отправка уида
Если чего неверно указал, прошу поправить. Я так понимаю, Вы не хотите ждать после выполнения первого пункта?
Да.
Я же выступаю за обязательное наличие первых трех.
А если пинг полсекунды? Пипец асинхронность. Смысл тогда вообще этот режим использовать?
Это то, что просили. Никто не заставляет пользоваться, если не нужно.
Вы мне так и не ответили на вопрос. Приведите, пожалуйста, конкретный пример, в каких случаях можно пренебречь гарантией исполнения торговых приказов ради скорости их отправки по разным символам?
Вы мне так и не ответили на вопрос. Приведите, пожалуйста, конкретный пример, в каких случаях можно пренебречь гарантией исполнения торговых приказов ради скорости их отправки по разным символам?
Не вопрос -- портфельный трейдинг + маркет исполнение.