Альтернативный Альфа-Коннектор

Новый коммит http://stocksharp.codepl...changeset/changes/15488

Долго не обновлял, по причине глобальных переделок. Часть из них сделана по аналогии Сергея. Что в итоге получилось?

1) Полностью асихронная модель приема данных от терминала. Все приходящие данные заворачиваются в очередь. Обработкой очереди занимается отдельный поток. Таким образом блокировки терминала минимальны. Поток минимально обрабатывает очредную порцию данных и передает ее выше, в обертку для таблиц. Каждая таблица имеет свою очередь и обрабатывает ее своим потоком. Парсит данные и передает их тем, кто на них подписался. Получаем многопоточный прием данных. По каждой таблице приходить будет в своем потоке.

2) Асинхронная подача заявок. Заявки при регистрации ставятся в очередь. Сюда же входят ордера на отмену заявок. Все ордера ставятся в очередь. Очередь обрабатывается своим потоком. Он извлекает ордера по очереди и начинает регистрацию. Регистрация неблокирующая, то есть управление возвращается сразу после подачи заявки. Если произошла ошибка при регистрации/отмене ордера, то формируется сообщение об ошибке и кладется в очередь ошибок, которая в свою очередь обрабатывается своим потоком вызывающим события в зависимости от типа ошибки. Если ордер прошел нормально, то он помещатеся в список ордеров ожидающих подтверждения.

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

Подобный способ регистрации ордеров обеспечивает нормальную работу терминала при подаче ордеров. Он не завешивает его. Если подавать ордера с таймаутом, терминал перестает принимать данные пока ордер не зарегистрирован окончательно. Это может длиться больше 30 секунд в разных ситуациях. Тестовые прогоны показали достаточную надежность такой системы. На каждый поданный ордер приходит либо успех либо ошибка (отлавливается по событиям типо OrderRegisterFailed). Прогнал серии по 100 ордеров, общей массой в 1000 и больше. Расхождений не было найдено. Были расхождения при отключении терминала в момент подачи заявок.

Если ордер был успешно зарегистрирован, будет событие NewOrder, если была ошибка - событие OrderRegisterFailed. И аналогично для других операций.

Обеспечить обновление ордеров подобным способом невозможно.Поэтому методы Update работают через отмену/подачу нового ордера.

Если подать сразу 2 ордера, второй не пройдет и будет событие об ошибке. Это надо учитывать.Подача ордеров неблокирующая. У альфы есть предел по скорости подачи/отмены ордеров.



В остальном функционал остался прежний.

Это версия видать совсем дремучая. Уже давно переделано подругому. Только что влил новую. Никаких багов нет.

Целый день воюю с этими двумя последовательными ордерами. Тут вопрос в чем. Запускаю 2-3 стратегии на разных инструментах. Я не могу сказать в какой момент они отменят заявку или выставят ордер. А тут встречаются накладки - я специально для синхронизации завел в стратеги статичное поле LastOrderRegistrationTime и при регистрации жду для примера одну секунду от этого значения, а вот ордер отмену не могу предсказать (использую правила) и тут пару раз и проскачила ошибка:

13:36:02.234 | Error | Стратегия для XXXX | Заявка 3421621415 не была принята по причине System.Exception: Поручение не может быть принято, т.к. превышена предельная интенсивность..

Я вот и думаю, т.к. это явный косяк Альфы, то и обработку его зашить в коннектор. Иначе две и более стратегии придется вручную синхронизовать. Ведь один такой сбой и вся стратегия рушится, т.к. почему-то появляется дубликат заявки (все-таки в конце концов видать доходит до сервера).
К примеру в AlfaTrader можно свойство добавить что-то вроде RegisterOrderInterval (установить по умолчанию в секунду) и когда из очереди выбирать на установку или отмену заявки для последующей заявки ожидать этот интервал и плюс (возможно) дожидать ответа от Альфы (успешно или неуспешно)

Если две заявки почти одновременно, что скорее всего будет иметь место при срабатывании по окончанию свечи, то та что будет второй 100% будет failed.
Ну вообще каждая заявка будет иметь ответ. Либо новую сделку либо ошибку. Отсюда выставлять заявки имеет смысл как угодно, Только реализовать гарантированное исполнение. Написать хелпер методы, или министратегию, которая будет гарантированно проводить сделку, с учетом возможных ошибок регистрации и прочего. Время выставления заявки у альфы может варьироваться. 1 секунда у меня где-то.

В последней версии альфа-коннектора с транка ордера ложатся в очередь и вызываются последовательного из одного потока. Это должно решить параллельную работу стратегий.

Ну просто нужно в стратегиях учитывать что заявка может не исполниться в первый раз. Надо подать снова на исполнение. Или просто сделать метод отдельный. Использовать можно котирование для подачи заявок. Пока вроде бы котирование работает в моем коннекторе. Только пишет про ошибку. Залью чуть позже версию в которой уже и ошибок не пишет.

А то что пишет ошибку у Вас это нормально. Альфа не дает две заявки быстро исполнить. Надо учитывать сей факт. То что Сергей пишет про коннектор из транка, верно. Но я намеренно отказался от подобного метода подачи заявок. Почему написано в комментариях к коммиту. Да и даже при ожидании исполнения каждой заявки, заявка может исполниться с ошибкой. В любом случае надо учитывать в стратегии факт возможного ошибочного исполнения заявок. А то что Вы пишете мол заявка даже при ошибке регистрируется и появляется в терминале, Это позволю себе заметить наверняка не совсем так. При сообщении о предельной допустимости заявка точно не регистрируется сервером. Видимо ваши стратегии посылают снова заявки свои на исполнение.

Стратегия котирования под коннектор AlfaPlus от Родиона работает. Изредка случаются сбои, стратегия завершается без позиции. Сильно не разбирался, просто в основной стратегии контролирую этот момент и дублирую в случае чего. В целом коннектор работает шустренько. Продолжаю наблюдения.

новый коммит http://stocksharp.codepl...changeset/changes/15576

Особенностей нет. Просто фикс атомарной перерегистрации. Поскольку сам коннектор на самом деле перерегистрацию делает через отмену старой заявки и подачу новой, указал это в нужном свойстве. Стратегии типо котирования учитывают сей факт при работе.

Хорошее дело затеял, Родион

Приветствую, альфа строители.

Хотел спросить вам как дело с вашим коннектором. Я так понимаю их сейчас целых 2, и не понятно какой из них использовать. Мы хотим выпускать версию 4.1, и этот вопрос предлагаю решить окончательно. Чем альтернативный коннектор лучше текущего? Может быть их соединить в плане фич и багов? Надо уже и на дев ветку накатить все то, что в транке фиксилось, так как именно из дева будет собираться новая версия.