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

VassilSanych: ra81: Тогда наши действия вполне линейны и определенны. Ага. Только бессмысленны. Пото...

2013-02-21T18:23:33Z

VassilSanych:

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

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

ra81: Тогда наши действия вполне линейны и определенны. Ага. Только бессмысленны. Потому что заявки ...

2013-02-21T18:12:55Z

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

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

2013-02-21T14:09:37Z

VassilSanych:

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

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

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

2013-02-21T13:53:26Z

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

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

2013-02-21T11:30:47Z

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

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

Идеального решения нет. Очередь событий в одном потоке позволяет быть уверенным, что обработка не бу...

2013-02-21T08:49:02Z

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

Добрый день. Обращаюсь прежде всего к разработчикам, ну и к опытным специалистам по части алго. Есть...

2013-02-21T08:11:07Z

Добрый день.

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

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