Дублирование ордеров в ядре S#
Atom
21.02.2013
ra81


Добрый день.

Обращаюсь прежде всего к разработчикам, ну и к опытным специалистам по части алго. Есть такая проблема сейчас: когда пришел ордер событие вызывает обработчики, ну и все что на них висит поочереди отрабатывает. Если где происходит затык, мы получаем висяк всей системы.
Михаил уже было обмолвился что в стратегию будет заходить очередь всех событий в один поток. Это хорошее решение. Но там мне никто не ответил, поэтому задаю более развернутый вопрос здесь. Как будет это реализовано? Сделать очередь я и щас могу без проблем, но известно что между событием по ордеру и началом обработки может произойти изменение статуса ордера. Отсюда когда мы начнем ордер обрабатывать, получим уже другой статус и обработаем его. Но в очереди событий будет лежать еще одно событие с таким же статусом ордера. Это как-то плохо и нехорошо. Как планируется решить вопрос? Нет ли смысла начать дублировать объекты которые могут меняться при передаче в стратегии итд?? Если делать очереди то как-то тут надо обходить эту проблему.
Дублировать ордера (и другие объекты которые могут меняться) я могу и сам, но тогда скорее всего придется доработать Clone методы.

В общем как видится решение текущей проблемы с локами через очереди? Какую архитектуру нужно сделать? Как избежать подвешивания всего и вся если один из потребителей загнется?

Теги:


Спасибо:


VassilSanych

Фотография
Дата: 21.02.2013
Ответить


Идеального решения нет.
Очередь событий в одном потоке позволяет быть уверенным, что обработка не будет лочиться по пути к стратегии, и что при тестировании всё будет происходить в правильной последовательности и с хорошей производительностью. Многопоточность в этом случае (как сейчас) даёт излишний оверхед на контроль потоков и дополнительные проблемы синхронизации.
Асинхронность реальных событий никто не отменяет: как было запаздывание реагирования, так и будет.
Затыки с производительностью и проблемы распараллеливания собственной стратегии предлагаю решать разработчику стратегии.
Спасибо:

ra81

Фотография
Дата: 21.02.2013
Ответить


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

Сделки например дублировать нет смысла они неизменны. Ну и так далее.
Спасибо:

VassilSanych

Фотография
Дата: 21.02.2013
Ответить


ra81
и в событии посылать дубль а не оригинал, и дубль будет неизменен на всем протяжении.

Зачем работать с устаревшей заявкой? Может лучше предусмотреть её изменчивость?

Спасибо:

ra81

Фотография
Дата: 21.02.2013
Ответить


VassilSanych
ra81
и в событии посылать дубль а не оригинал, и дубль будет неизменен на всем протяжении.

Зачем работать с устаревшей заявкой? Может лучше предусмотреть её изменчивость?

Тут есть два варианта развития событий. Либо мы вводим кучу неопределенностей типо: ордер может измениться пока мы его обрабатываем, котировка может измениться между двумя нашими действиями, да еще дофига чего. Либо мы работаем с неким снимком на конкретный момент времени. Тогда наши действия вполне линейны и определенны. А уж чтобы не работать с устаревшими данными просто наращиваем мощность железа и все. Что выгоднее? Думаю вариант два выгоднее. Он линеен, легко прослеживается, легко масштабируется.

В общем жду таки разработчиков.

Спасибо:

VassilSanych

Фотография
Дата: 21.02.2013
Ответить


ra81
Тогда наши действия вполне линейны и определенны.

Ага. Только бессмысленны. Потому что заявки с таким статусом уже нет.
Информация снэпшота имеет смысл только для логирования.
Для торговли важно нынешнее состояние, а не то, как замечательно и логично мы обрабатываем состояние заявки, которое было пару секунд назад.


Спасибо:

gramp

Фотография
Дата: 21.02.2013
Ответить


VassilSanych
ra81
Тогда наши действия вполне линейны и определенны.

Ага. Только бессмысленны. Потому что заявки с таким статусом уже нет.
Информация снэпшота имеет смысл только для логирования.
Для торговли важно нынешнее состояние, а не то, как замечательно и логично мы обрабатываем состояние заявки, которое было пару секунд назад.




в любом случае мы работаем со снэпшотом, вопрос лишь в частоте его получения - кому-то важны микросекунды, кому-то минуты )
Спасибо:


Добавить файлы через драг-н-дроп, , или вставить из буфера обмена.

loading
clippy