<HELP> for explanation

Блог им. inferno

Алготрейдинг: Путь Заявки

Трейдеры, торующие руками, редко задумываются над тем, что происходит с заявкой после нажатия кнопки бай/селл. В нормальных условиях это приводит к выводу ее на биржу во мгновение ока, что визуально подтверждается в торговом терминале. Но иногда заявки теряются. Возможно каждый замечал, что клик по кнопке, бывает не срабатывает. Что это? Возможно кривые руки, а возможно заявка где то застряла. При этом совсем неочевидо, к каким финансовым последствиям это может привести.
При разработке торговых роботов эта проблема стоит наиболее остро.
Итак, торговый робот имеет сигнал и готов подать заявку (трейдер — нажать бай/селл). Что дальше?
  1. Робот отправляет ее в брокерский софт на локальной машине (трейдер — в терминал)
  2. Софт брокера пытается заслать заяку на сервер брокера.
  3. Если с интернетом порядок, заявка покидает локальный компьютер
  4. Гуляет по хостам в интернете
  5. Если сервер брокера доступен, добирается до него
  6. Если софт на сервере в порядке, регистрируется в БД брокера, и пытается уйти набиржу
  7. Если канал с биржей стабилен, добирается туда.
  8. Софт на бирже фиксирует получение заявки
  9. Выводит ее на рынок, и фиксирует этот факт
  10. и отправляет результат брокеру



дальше в обратном порядке


  1. софт биржи отправляет результат брокеру
  2. канал биржа-брокер
  3. софт брокера
  4. интернет канал трейдера
  5. клиентский софт брокера у трейдера
  6. торговый робот (терминал)

Общеизвестно, что любой софт иногда глючит, а интернет каналы нестабильны. Поэтому, путь заявки может прерваться на любом из перечисленных шагов. Что делать если это таки случилось?
Руко-трейерам проще, можно применить аналитическое мышление и прочее, хотя и здесь, при форсмажорных обстоятельствах, многие умудряются закрывать миллионные прибыли по позициям, которые они не открывали, а наутро получать открытые позы в обратную сторону.
При разработке роботов следует учитывать каждое из этих мест, где заявка сдохнет.
Особенно для хфт, которые не ждут ответа по каждой заявке, перед отправкой следующей, а фигачат без остановки.
И что делать, если заявка потерялась?

Для начала, удостовериться, что она действительно потерялась :)
Как? Даже это не легкая задача. Установить таймаут? Так ведь раундтрип в разные периоды, взависимости от условий, может варьироваться от 10 мс. до 30 и более сек.
В любом случае, прекратить торговлю незамедлительно, до выяснения обстоятельств.

Фухх… Устал писать…
Видимо, продолжение следует...
 
 

Это какой брокер и какая прога так тебя???
avatar

berensh

berensh, прога самописная, брокеры всякие.
inferno, Торгуй по телефону! прога отдохнет)))
berensh, уважаемый поделитесь, в S#, указанные проблемы решены, и если да то как?
inferno, Простите, не знаю(( Это к Сухову или Муханчикову
berensh, упс. не туда написал. айм сори.
На самом деле не так страшен черт… Практически все нормальные SDK имеют встроенную поддержку таймаутов. Тоесть, даже если сигнал потерялся в интернете, все равно клиенская часть обязана оповестить робота, что произошел тайм-аут при регистрации заявки. Тоже самое справедливо и для брокерской стороны.

Насчет остановки работы. Тут все зависит от логики. Если это не принципиальная заявка, то можно и продолжить работу (например, заявка на усреднение позиции), если позволяет ММ. Если это критическая заявка (переворот, стоп-сигнал), то да, лучше остановить работу.

Вообще тайм-ауты лучше вообще не отслеживать. Потому что они вносят только шум в алгоритм. Получили тайм-аут, а спустя секунду нормальный ответ, что заявка встала в стакан. Лучше следить не за таймаутами, а за потоком данных. Именно он является хорошим индикатором того, что что-то не так с данными. А заявку всегда можно ручками «поправить», чтобы робот не перезапускать.
Mikhail Sukhov, вся проблема в том что если произошел таймаут, то неизвестно, дошла ли заявка брокеру, вышла на биржу или нет. Где она сдохла, на пути туда или обратно?
Как ее учитывать для дальнейших действий?
inferno, проблемы на самом деле нет. Если у нас критическая по логике заявка, мы так и так ждет ее ответа. Тоесть и робота останавливать не нужно, так как он сам себя остановил свои ожиданием ответа (пусть и бесконечного).

Если заявка некритическая, то можно смело плюнуть на ее ответ.

Вот и все. Никаких страшилок на ночь =)

Минус поставил не я.
Mikhail Sukhov, а если я за роботом не слежу, и ручками поправит не вариант, что тогда? Допустим раз в месяц смотрю что да как… Я тут пишу про безотказные системы.
inferno, Во-первых, я очень рад, что такое сообщение опубликовали. Познавательно, правда.

Во-вторых, безотказных систем не существует. Вообще. Делая таймауты и прочие проверки, вы только усложняете логику робота. И вместе ухода от редких ошибок вы привносите в робот новые, и частые ошибки.

И в третьих, то, что я описал выше, как раз является своего рода распространенным подходом борьбы с тайм-аута в заявках. Не нужно с ними бороться. Или робот сам себя застопорит своей логикой (если не так, то надо исправлять робота), или эта ошибка не критическая.
Mikhail Sukhov, согласен, чем сложнее логика, тем больше потенциальных ошибок. И с подходом «забей на несущественное» тоже соглашусь. Но, насчет безотказности поспорю. Можно определить конечное число развития событий, и выстроить безглючный алгоритм, для каждого события, который делает все правильно (в отличие от импульсивного трейдера).
inferno, импульсивный трейдер потому и делает много ошибок, что слишком много нервничает и много додумывает ;o)
Ждём продолжение, особенно про решения
avatar

Sekator

А что мешает проверять по таблице заявок квика. Качаете ее по dde или odbc в программу проверки и все дела. Это если задержка в 0,5-1 сек. некритична. А если критична, то лучше сразу озаботиться тем, чтобы избавиться от кучу промежуточных звеньев в Вашей схеме. Правда последнее уже будет стоить денег.
avatar

А. Г.

А. Г., опередили ))
вопрос.
ты отправил заявку роботом — сделал проверку — присвоен ли ей номер в системе или прошла ли транзакция. Даже в простеньком купайле это есть. и все
зачем городить огород не понимаю если честно
без обид :)
avatar

lambreken

lexakot, номер в какой системе? Часто у заявки есть 2 номера, брокера и биржи. Брокерский обычно приходит быстрее.
И если допустим номер не присвоен, где гарантия что заявка все же ушла на биржу, но робот этого не зафиксировал?
inferno, что значит — «часто у заявки есть 2 номера»?
приведите пример плз
то есть следуя логике «иногда у заявки нет 2х номеров. есть только 1, то ли брокера, то ли биржи, да хер разберешь» ??
lexakot, у смарткома есть свой номер, и даже есл и без него, то все еще намного сложнее
inferno, поверьте, легче. Все намного легче. Придется попотеть в части адаптера, но потом роботы будете делать уже действительно независимыми от системы. Не стоит роботов завязывать на особенности брокерского софта. Чревато.
inferno, брокерский номер от лукавого. Не используйте его вовсе. Так сделали например в СмартКом. Из-за этого у трейдеров наблюдаются проблемы с синхронизацией состояния.

Только биржевой номер, и ничего больше.
Mikhail Sukhov, да именно смартком имею ввиду
inferno, мы брокерский номер прячем глубоко в адаптере к СмартКом. И не выдаем его наружу. Так как и бесполезен, и дает путаницу в виде того, что заявка то ли зарегистрирована, то ли нет. Подозреваю, что вы пост написали на чувствах, что в очередной раз произошла с вами такая путаница.
Mikhail Sukhov, даже если забить на брокерский номер, путь заявки туда и обратно (без промежуточных уведомлений) будет длиннее. А ответ о том, что заявка зарегистрирована, обратно может и не дойти.
пс. путаницы не было. просто я хочу создать идеального робота.
Mikhail Sukhov, вот как это например обрабатывается в стокшарпе? Заявка ушла, и никакого ответа нет. Забиваем за несущественностью?
есть только вариант биржевой заявки и все — вот ее и контролировать
вобще не понимаю смысл вашего поста
это из разряда — «я купил 5 контрактов РИ, они в таблице сделок отображаются, в открытых позициях отображаются — как мне проверить, что они дошли до биржи и брокер не лжет»
lexakot, смысл не в этом. Смысл в том, что я купил 5 контрактов, и не получил ответной реакции. Они нив каких таблицах не отображаются, и непонятно что делать дальше.
inferno, почитайте на примере купайла и не мучайте себя философией ;)
www.qpile.ru/forum/7-82-1
функции RESULT_EX вполне достаточно:
После этого нам необходимо отследить статус транзакции и статус заявки (нужно помнить, что это две разные вещи).
Статус транзакции мы можем отследить с помощью массива значений, возвращаемых функцией SEND_TRANSACTION
Нас интересуют два параметра:
1) ORDER_NUMBER — регистрационный номер заявки в торговой системе,
2) RESULT_EX — расширенная диагностика выполнения операции
Возможные значения RESULT_EX:
«0» — транзакция отправлена серверу,
«1» — транзакция получена на сервер QUIK от клиента,
«2» — ошибка при передаче транзакции в торговую систему, поскольку отсутствует подключение шлюза ММВБ, повторно транзакция не отправляется,
«3» — транзакция выполнена,
«4» — транзакция не выполнена торговой системой, код ошибки торговой системы будет указан в поле «DESCRIPTION»,
«5» — транзакция не прошла проверку сервера QUIK по каким-либо критериям. Например, проверку на наличие прав у пользователя на отправку транзакции данного типа,
«6» — транзакция не прошла проверку лимитов сервера QUIK,
«7» — транзакция клиента, работающего с подтверждением, подтверждена менеджером фирмы,
«8» — транзакция клиента, работающего с подтверждением, не подтверждена менеджером фирмы,
«9» — транзакция клиента, работающего с подтверждением, снята менеджером фирмы,
«10» — транзакция не поддерживается торговой системой. К примеру, попытка отправить «ACTION = MOVE_ORDERS» на ММВБ,
«11» — транзакция не прошла проверку правильности электронной подписи.
Код для получения доступа к параметрам массива возвращаемого функцией SEND_TRANSACTION:
Code
result = SEND_TRANSACTION (30, transact)
N = get_value (result, " ORDER_NUMBER ")
M = get_value (result, «RESULT_EX»)

Мы определили статус транзакции, теперь нам необходимо отследить статус заявки.
Обратимся к таблице заявок (ORDERS) или таблице стоп-заявок (STOP_ORDERS).
Для начала определим кол-во строк в данной таблице:
K = GET_NUMBER_OF(“ORDERS”)
В данной таблице нас интересуют следующие параметры:
1) NUMBER — номер заявки в торговой системе
2) TRANS_ID — идентификатор транзакции
3) STATUS – статус заявки, значения: «ACTIVE» или «KILLED» или «FILLED»
Таким образом, мы знаем количество заявок (K), TRANS_ID (мы вводили его сами) и NUMBER (N)
Code
FOR i FROM 1 to K
trade = GET_ITEM («ORDERS », i)
If GET_VALUE (trade, " NUMBER ") = n
P = GET_VALUE (trade, «STATUS»)
RETURN
Else
……
End if
END FOR
lexakot, что вы будете делать (или ваш робот) если статус транзакции «0» — транзакция отправлена серверу, и этот статус не меняется уже 3 минуты?
inferno, все просто — контроль в цикле до тех пор пока состояние не изменится.
можно тупо для таких редких ситуаций как технические сбои на бирже сделать оповещение через интернет хозяину робота
скажем после 1 минуты статут остался висеть 0 — отправка на почту письма о сбое. а дальше человек включается и решает что делать. если есть новость от брокера о сбое на бирже — остановка. либо если нет доступа у человека к терминалу — просто проверка как и писал, в цикле. до тех пор пока статус не изменится
lexakot, что и следовало ожидать — ручное управление. А что ж делать автономному роботу без посторонней помощи?

Даже человек, как я уже сказал, тыкает кнопку «бай», например, и ждет реакции. А ее нет. Думает, может промахнулся, тыкает еще, опять ноль, еще несколько раз… может кнопка сломалась. Уходит разочарованный, а наутро оказывается в позе на больше чем все.
inferno, а идеального ничего нет
никакой робот ничего не сделает если биржу выключат на сутки
пусть он хоть обпроверяет свои статусы
lexakot, есть идеальное! никто ничего не сделает если биржу выключат (даже человек). Но робот может проверять доступность биржи, периодически. А статусы (смотря чьи), главное их интерпретировать правильно, и вовремя предпринимать действия или отказаться от них.
inferno, можно через какой-то тайм аут начать отправлять заявки на отмену торгового приказа, при удачной отмене повторить приказ, а если придет ошибка, то проверить позицию — если приказ исполнился, то позиция изменится, а если нет, значит приказ по какой-то причине не был принят и надо слать повторный.
inferno,

В таблице заявок Ваша заявка в квике должна появится в течении 1 секунды. Если ее там нет, то возможны всего четыре варианта:

Ваш робот ее не отправил;
Обрывалась связь клиентского места с сервером;
Не работает вывод таблицы в программу проверки;
У брокера проблемы с выводом заявок на биржу.

Первые три ошибки можно проконтролировать в роботе, последнюю все равно можно решить только вручную путем звонка брокеру.
А. Г., насчет 1 секунды не соглашусь, например:
— интернет затормозил
— на рынке начался большой движняк
— антивирус затеял проверку и забрал всю процессорную мощность
— биржа сломалась
— вискарь вылился на клавиатуру
— мыши сгрызли провод
— жена позвала обедать

а насчет 4-х причин, да, это как раз то, что я перечислил в посте, только сжато. Тем не менее, я бы предпочел рассматривать все звенья цепочки — программные модули на клиентский машине, у брокера и на бирже, и средства коммуникаций между ними.
с таким же успехом можно сказать, что причина только одна — что то пошло не так — и решение либо есть либо его нет.
avatar

inferno

inferno,

Какая у робота может быть жена, позвавшая на обед? И как робот может пролить вискарь на клавиатуру? :) А почти все остальное (кроме биржа сломалась) укладывается в проверку связи.

Ну а настраивать робота на техпроблемы на бирже — это бессмыслено. Если биржа сломалась, то надо робота выключать.
А. Г., да шучу, конечно, про жену и вискарь.

Спасибо за участие в дискуссии.

Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.

Залогиниться

Зарегистрироваться
....все тэги
Регистрация
UP