westtrd, если я правильно понимаю, абстракцией данных в Плазе является таблица, а не стакан. Поэтому коммит относится ко всей таблице. Во время апдейта таблицы формирую список (на основе фиксированного массива - по Вашим советам) обновившихся стаканов. По коммит создаю событие, которое по этому списку апдейтит собственные структуры приложения. Точнее, в цикле по этому списку вызывается делегат для каждого изменившегося стакана. Можно наверно было бы формировать мультикаст делегат и не проходить в своем цикле, но это детали, не знаю, будет ли так быстрее.
Резюме: обрабатываю каждый коммит, для каждого коммита обновляю небольшой список изменившихся стаканов. Честно говоря, других вариантов не вижу.
westtrd
Стаж: 7 лет 8 месяцев Откуда: Belarus Сообщений: 1034
Означает момент завершения получения очередного блока данных. К моменту прихода этого сообщения можно считать, что данные полученные по данной подписке, находятся в непротиворечивом состоянии и отражают таблицы в синхронизированном между собой состоянии. Данное сообщение не содержит дополнительных данных и его поля data и data_size не используются.
Исходя из этого, все верно. Резюме тоже верное. Вопрос был в другом, я попытался взглянуть на эту проблему с другой стороны, а именно - как бы я решал эту проблему, связанную с коммитами в случае ограниченных стаканов (то есть, передача банального массива с маской). Но это мне представляется плохо решаемым по причине тяжелого SQL-ного прошлого.
В части архитектуры - тоже верно вроде все, за исключением того, как вы планируете решать проблему, связанную с медленными подписчиками или затыками со стороны подписчиков. В общем случае, без зеркальных стаканов не обойтись.
Вопрос был в другом, я попытался взглянуть на эту проблему с другой стороны, а именно - как бы я решал эту проблему, связанную с коммитами в случае ограниченных стаканов (то есть, передача банального массива с маской). Но это мне представляется плохо решаемым по причине тяжелого SQL-ного прошлого.
Так и сейчас на фортс обычное дело, если коммит приходит для изменения единственного инструмента - RI.
Цитата:
В части архитектуры - тоже верно вроде все, за исключением того, как вы планируете решать проблему, связанную с медленными подписчиками или затыками со стороны подписчиков. В общем случае, без зеркальных стаканов не обойтись.
Так же как и Вы, делаю развязку. Только Вы это делаете в самом начале, а я позже. Стаканы мне в конечном счете не нужны, много копировать не надо. А коллбэк у меня отрабатывается пока очень быстро: парсинг и вставка в сортированный стакан 500 нс под .net Это оценочно, по специальным тестам, т.к. непосредственный замер дает под Виндой интервал порядка разрешения счетчика. Т.о., задержка коллбэка пока не напрягает. Хотя заметил такую вещь, что если специально задерживаюсь в коллбэке (например, вывожу что-то на экран), участок коллбэка до этой тяжелой операции почему-то тоже начинает отрабатывать в среднем на 1-2 мкс дольше. То есть замедление в коллбэке может замедлять систему и в других местах.
Bell под .net и виндой вполне можно мерить с точностью до микросекунды где-то. Всё на что уходит меньше одного тика (обычно это как раз где-то в районе 500 нс помоему) вообще я не считаю за время Вообще для .net 500 нс это очень быстро. У меня слегка другие скорости
Я пока что так и не посмотрел когда у меня комиты приходят, но обязательно посмотрю и отпишусь.
Попробовал сейчас ещё раз замерить как часто приходит Commit. Получить задержки близкие к 0 миллисекунд получились только на старте пока что. Так что похоже по Commit действительно можно считать что данных по стаканам больше нет.
Но по документации вообще то Commit всего лишь означает что данные находятся в синхронизированном состоянии. Мне же нужно знать что данные а) находятся в синхронизированном состоянии и б) данных больше нет.
Пока что я просто считаю что Commit и означает что данных больше нет, но гарантий что биржа не начнёт выдавать например по 3 Commitа на апдейт я так понимаю нет.
modelka, может быть удастся обнаружить какую-нибудь закономерность в интервалах меджу коммитами, если в лог выводить информацию о смене состояния потока.
Спасибо, про удаление понятно. В общем то я смотрю что тема уже обсуждалась так что зря я сразу стал спрашивать надо было поискать
Я попался на пункте 1, когда нулями заполняют изначально. На "коротких" стаканах у меня эти нули отсветили и попали в Ask как минимальная цена предложения В общем я просто игнорирую такие записи и у меня вроде всё работает тьфу тьфу тьфу.
Последний раз редактировалось автором 15.02.2013 15:10, всего редактировалось 2 раза
Так и не понял, как собрать стакан используя "Потоки агрегированных стаканов".. Имеют ли поля replID, replRev, replAct специальное значение в контексте сборки стакана? Только по isin_id/price/volume/dir стакан собрать невозможно. Все что говорит "Шлюз ФОРТС Plaza-2" (p2gate_ru.pdf) про "Потоки агрегированных стаканов" это: >>>>>>>>>>>>>>>> Таблица 22. Поля таблицы orders_aggr Поле Тип Описание replID i8 Служебное поле подсистемы репликации replRev i8 Служебное поле подсистемы репликации replAct i8 Служебное поле подсистемы репликации isin_id i4 Уникальный числовой идентификатор инструмента price d16.5 Цена котировки volume i8 Объем агрегированной котировки moment t Время последнего обновления котировки dir i1 Направление котировки Примечания: • Записи в таблице могут обновляться полностью, т.е. обновляться может не только объём котировки (volume), но и инструмент, цена, направление. В случае наступления такого события считается, что предыдущая котировка вышла из стакана, а новая – появилась. • В таблице могут присутствовать записи с нулевым объёмом (volume = 0). Такие записи следует игнорировать. При этом, может происходит обнуление существующей котировки – это означает, что котировка вышла из стакана или заполнение нулевой котировки какими либо значениями – это означает, что котировка с новыми значениями вошла в стакан. <<<<<<<<<<<<<<
Вопрос тем кто в теме: а чем отличается собирание стакана из _REPL потоков от собирания стакана из полного ордер лога? И что вообще лучше? И если я сделал изначально стакан из _REPL, можно ли потом его дополнять инфой из полного ордер лога, или это нереально?
Вопрос тем кто в теме: а чем отличается собирание стакана из _REPL потоков от собирания стакана из полного ордер лога? И что вообще лучше? И если я сделал изначально стакан из _REPL, можно ли потом его дополнять инфой из полного ордер лога, или это нереально?
обсуждалось уже где-то как-то ) из полного ордерлога можно все сделки например ещё попутно собрать. дополнять не надо, надо заменять на полный ордерлог
Поиск
Правила
Пользователи
Профиль
Регистрация
Вход
