Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Спасибо, papaklass, за такой расширенный ответ!
Но я "напрягся" не потому, что при массовом снятиии ордеров происходит реджект, а
потому, что ТРЕТЬЕ снятие ордера не проходит (а может быть и второе, обратите внимание на время отсылки команд).
QD 0 23:49:30.774 Trades '11000': cancel order #6743665 sell limit 1.00 RTKM-3.15 at 11978
JH 0 23:49:30.774 Trades '11000': cancel order #6743740 sell limit 1.00 TRNF-3.15 at 88843
GL 0 23:49:30.264 Forts_trader (TRNF-3.15,H1) Ордер не удалён! Билет = 6743740; Код возврата = Слишком частые запросы
Значит это может произойти в штатном режиме работы, ведь может случится ситуация, когда
три (ДВА) советника одновременно пошлют команду OrderSendAsync (что очень вероятно) и одна из них не пройдёт!!!!!
Вот что печалит более всего.
Скорее печалит ваше осознанное нежелание ответить на самый простой вопрос, заданный мной уже трижды.
Скорее печалит ваше осознанное нежелание ответить на самый простой вопрос, заданный мной уже трижды.
Логи я отослал вам личным сообщением
Неужели не получили?
Логи я отослал вам личным сообщением
Неужели не получили?
Я задаю в четвертый раз один и тот же вопрос - сколько транзакций в пачке прошло, пока не сработала защита от флуда?
Это именно защита, а не ошибка. И речи ни о каком "2-3 транзакция приводит к ошибке" не может быть.
Логов я не прошу. Я прошу ответить только на простой вопрос.
Если ответа не будет, то тема будет снесена за заведомую ложь.
Я задаю в четвертый раз один и тот же вопрос - сколько транзакций в пачке прошло, пока не сработала защита от флуда?
Это именно защита, а не ошибка. И речи ни о каком "2-3 транзакция приводит к ошибке" не может быть.
Логов я не прошу. Я прошу ответить только на простой вопрос.
Если ответа не будет, то тема будет снесена за заведомую ложь.
В первой пачке прошло 16 транзакций ( начало 19.09.2014 23:49:30.257)
Во второй пачке 2 тразакции ( начало 19.09.2014 23:49:30.773)
P/S Спасибо за объяснение, что стоит защита, хорошо бы об этом написать в документации.
Результаты разбирательства будете публиковать?
Результаты разбирательства будете публиковать?
Оказалось, что со стороны терминала или сервера ошибок нет. Дело в том, что у нас буфер подтверждения/ожидания на 16 ожидающих транзакций, которые вы полностью использовали и вследствие достаточно большого пинга(50-70 мс) до торгового сервера (+ исполнение/регистрация на бирже) не успевали получать ответы. Поэтому сразу идущие следующие транзакции были отклонены как частые.
Если бы вы торговали с более близкого расстояния и меньшей сетевой задержкой, то получали бы подтверждения быстрее и отказов "частые операции" получали бы меньше.
Вначале при первом взгляде показалось, что в очереди зависли старые блокирующие транзакции, но эта догадка не подтвердилась. С толку сбили логи, которые на самом деле выравниваются чуть по другому. В очереди никаких зависших транзакций нет.
В официальном билде 1010 мы увеличили буфер ожидающих подтверждения транзакций до 64, что дает возможность проводить массовые асинхронные транзакции даже при больших сетевых задержках. Обновитесь на эту версию, подключившись к MetaQuotes-Demo, если ваш брокер еще не обновился сам.
По ограничению очереди подтверждений надо понимать, что это важное условие, защищающее торговые серверы от трейдерских ошибок и перегрузок. Авторам программ нужно аккуратно относиться к доступной мощности и не использовать ее в грубом режиме. То есть, всегда оценивать реакцию брокера/биржи, которым могут не понравиться массовые торговые операции, особенно если они не приводят к сделкам.