Совместная разработка PlazaTrader

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

Желательно сначала реализовать простейший интерфейс: получение стаканов, отправка ордеров.
Лучше threadsafe, если это не скажется на производительности.

ITrader - это красивый фантик, удобный для держания в руке. А я говорю о самой конфете, которую еще изготовить нужно. В плане Плазы тут довольно много дел. Вот мое видение того, что нужно сделать:

1. Описать метаданные, как это сделано для Квика (DdeSecurityColumns, DdeTradeColumns и т.д.). Я это уже показал на примере класса PlazaFutureColumns, но там колонки не реальные.
   
2. С помощью этих метаданных научиться строить конфиги ini. Как вариант, через PlazaTable (куда собственно и будут добавляться колонки из пункта 1). Сейчас их программно делать нельзя. И если роботу нужны спец колонки нужно менять формат ini схем. Я предлагаю до загрузки этих схем давать возможность менять из программно (парсить и менять ini файлы на лету). + как фича автоматически сканировать директорию при старте и создавать с правильным набором колонок сами PlazaTable. Возможно, здесь поможет TableSet.
   
3. Подписываться на потоки + задавать в них фильтры. Подписывать на тики, обновление инструментов.
   
4. Cтаканы. Производная от предыдущей задача.
   
5. Обработка заявок. Я уже сделал через класс Message заполнение полей для отправки транзакций. Это дело надо доделать. Плюс я думаю надо ввести поддержку экзотики (адресные, внесистемные заявки), чтобы можно было использовать брокерским компаниям, если они захотят.
   
6. Парсинг ответа. Я не знаю, в каком виде они приходят, но могу сказать, какой результат должен быть. Это должно быть PlazaException с кодом ошибки (чтобы не мучится сравнение строчек в коде). И код не ввиде числа (что не так уж лучше строчки), а нормального перечисления (enum).
   
7. Позиции, счета, волатильность, маржа. Это все нужно так же сделать (на основе пункта 1 и 2).
   
8. Работы с БД. У плазу клиента два режима. Первый пишет в БД, второй не пишет. Приоритетным мне кажется тот, который не пишет. Но вдруг кому то потребуется, чтобы писались данные (как я понял, это дело устроено с помощью SQLite). Так что нужно опция.
   
9. На форуме доступна x64 версия. Нужна прозрачная поддержка (без перекомпиляции) x86 и x64.
   
10. Обертка над роутером (чтобы так же, не ручками править конфиги, а программно).
    
11. Юнит тесты.
    
12. Документация (как xml, так и обычная). Если нужно сделать как у S#, то необходимо использовать Sandcastle.
    

Как то так. Если есть еще что, пишите. На след. неделе надо уже разбирать задачи.

Предлагаю взять пункт 10: программная обертка конфигов роутера. Я так понимаю, что править нужно будет следующие конфиги:
client_router.ini
P2ClientGate.ini
Остальные, судя по всему, к настройке роутера отношения не имеют.

Попытаюсь одолеть стаканы (п.4) после новогодней проруби. Или - ещё лучше - совместно с кем-либо 3 и 4.
У меня 4 вопроса:
1) получение не(редко)меняющихся данных (базовое ГО, зафиксированный в 16-30 курс $, размер комиссии биржи, расчётная цена, лимит изменения цены, последний торговый день, и т.д.) уже сделано или отнесено к потокам (п.3)?
2) будет ли в потоках ежесекундный курс $, теоретическая цена, индекс волатильности и т.п. дополнительные данные?
3) стоит ли (для будущих брокеров - нынешние уже так или иначе подключены к Плазе2, или алгохеджеров) обеспечивать универсальность по инструментам (1005 фьючерсов и 3590 опционов), или ограничется теми, которые нужны хотя бы внутридневным спекулянтам и арбитражёрам (на мой вкус - 18 фьючерсов и опционы на фьючерс РТС по 3 страйка коллов и путов)?
4) не следует ли ограничить глубину стаканов, кроме РТС, скажем - остальные 8 со спекулятивной ликвидностью до 20, а другие (включая опционы), т.е. с маркетмейкерской ликвидностью - до 5?

1. Я думаю это размазано по нескольким пунктам. расчётная цена, лимит изменения цены, последний торговый день - это относиться к инструменту. базовое ГО, зафиксированный в 16-30 курс $, размер комиссии биржи - это наверное мой пункт 7.
2. Это все относиться к инструментам. Предлагаю выделить это в отдельный пункт - экспорт дополнительный параметров.
3. Экспортировать надо все. Плюс кстати хорошее замечание, надо подумать в сторону кэширования данных.
4. Супер, забыл об этой фиче.
4.1 Думаю нужен переключатель, какой именно стакан требуется, агрегированный или позаявочный.

+
+
+

5. Кстати, а биржа транслирует свое время? Если нет, то предлагаю это добавить в качестве нового пункта.

1. Я думаю это размазано по нескольким пунктам. расчётная цена, лимит изменения цены, последний торговый день - это относиться к инструменту. базовое ГО, зафиксированный в 16-30 курс $, размер комиссии биржи - это наверное мой
пункт 7.
2. Это все относиться к инструментам. Предлагаю выделить это в отдельный пункт - экспорт дополнительный параметров.
3. Экспортировать надо все. Плюс кстати хорошее замечание, надо подумать в сторону кэширования данных.
4. Супер, забыл об этой фиче.
4.1 Думаю нужен переключатель, какой именно стакан требуется, агрегированный или позаявочный.

+
+
+

5. Кстати, а биржа транслирует свое время? Если нет, то предлагаю это добавить в качестве нового пункта.[/quote]

...

1. А инструмент - это п.2 (я ещё ничего не получил, и квик в глаза не видел)?
3. А всё-таки зачем всё? Не слишком ли это усложнит работу?
4.1. Что такое агрегированный стакан - его общий объём при глубине 5, 20 , или 50, или просуммированы только заявки разных инвесторов с одной ценой?
5. Транслирует, например вместе со сделками (тиками), однако в сек., а не мс, поэтому для наших целей толку не много.
6. Предполагается ли запись всего подписанного с мс.(!) на жёсткий диск? Такие исторические данные у биржи даже купить нельзя. Кстати, может у кого-нибудь есть, хотя бы по РТС за разумный период подряд?
7. А воможна ли разработка последующих п. до завершения п.1-2?

Дата и время сервера: поток FORTS_FUTTRADE_REPL, таблица heartbeat, server_time

Хм, я как-то упустил момент, что поток может содержать несколько таблиц. Кажется, я не правильно понял модель потоков. Для чего это сделано?

...

1. А инструмент - это п.2 (я ещё ничего не получил, и квик в глаза не видел)?
3. А всё-таки зачем всё? Не слишком ли это усложнит работу?
4.1. Что такое агрегированный стакан - его общий объём при глубине 5, 20 , или 50, или просуммированы только заявки разных инвесторов с одной ценой?
5. Транслирует, например вместе со сделками (тиками), однако в сек., а не мс, поэтому для наших целей толку не много.
6. Предполагается ли запись всего подписанного с мс.(!) на жёсткий диск? Такие исторические данные у биржи даже купить нельзя. Кстати, может у кого-нибудь есть, хотя бы по РТС за разумный период подряд?
7. А воможна ли разработка последующих п. до завершения п.1-2?
[/quote]

1. Если речь про мой первый список - это пункт 3.
2. Работу как раз упростит (если кэширование не делать). А как Вы предлагаете? Скажем, как трейдеру получить весь список инструментов, чтобы найти нужный?
3. Второе. Чтобы видеть, с каким реально объемом стоят заявки.
6. Если про тики - то они вообще бесплатно раздаются. Если стаканы - то уже сложнее. И мне кажется, что это уже производная задача.
7. Сложно сказать.