RoutingServer
Atom Ответить
13.11.2012


Есть идея сделать совместный проект роутера маркет-данных и транзакций.

Идея заключается в создании отдельного (=внешнее) приложения, которое бы могло запускаться (как обычное exe или как сервис), настраиваться, подключаться к торговым системам (всем, что поддерживает S#). Приложение выступает как серверное, и дает возможность подключаться из других программ (как на локальном компьютере, так и через интернет). Такими клиентами смогли бы выступать роботы, аналитические программы, торговые системы, ищущие данные и т.д.

Что дает такая программа:

1. Возможность подключаться к ТС вне локального компьютера. Например, иметь возможность слать заявки на другой компьютер. Особенно полезно для тех, кто управляет чужими счетами, и при этом клиент сильно стремается давать ключи. Или в рабочее время за счет работодателя пишет роботов и торгует с работы.Blushing

2. Позволять подключаться из разных программ к одной ТС. Например Квик Смарт и Альфа не дают торговать нескольким роботам одновременно. А запихивать новый (=глючный) робот в один процесс со старым (=стабильным) роботом, чтобы последний не отбросил копыта при смерти первого, не самый простой процесс.

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

4. Возможность отделиться от ограничение разрядности некоторых систем. Квик, например, дает только 32 бита, и роботу позволено кушать всего 1.5 гига.

5. Встроенные возможности риск-контроля. Частично пункт 3 + примитивные (но железные) настройки, не позволяющие роботу сделать непоправимое. Как бы мы ни старались в новых версиях S#Laugh

6. Простенький кабинет с возможностью детальной статистики. Не аналитика, но данные все, чтобы можно было выгрузить как раз в аналитику.

7. Эмуляционный режим, чтобы проверять робота на настоящих данных с настоящими сетевыми лагами.

8. Умный роутинг данных с фильтрами, компактный протокол.

9. Интеграция роутера с Гидрой, чтобы через единую точку получать еще и исторические данные. Да-да, стаканы с начала сессии и ОИ, тики за неделю для формирования стартовой истории, свечки по СнП за год и прочее-прочее.

Думаю, у многих тут уже потекли слюньки. Поэтому сразу определимся зачем я все это написал. Сделать эту работу лучше командой. Проект этот в любом случае стартанет в рамках S#. Но что точно - он не будет доступен ни на боксе, ни на кодеплексе.Wink Поэтому, я предлагаю определится всем тем, кто уже замышлял о подобном (а я уверен, что эти 9 фич касаются практически всех, кто пишет и работает с ботами), и отписаться (лучший контакт - скайп контакт). Разработка будет вестись в закрытом репозитарии (не на S# сервере, а новое место). Все, кто будет участвовать, будут иметь доступ к результату (возможно к версиям 2.0 и т.д., если таковые будут). Все, кто не будет - я думаю объяснять не нужно.



Спасибо:




22 Ответов
Yury Smykalov

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


Замечательная идея!
Сейчас свободного времени немного, но, надеюсь, смогу нанести непоправимую пользу :)

Мой скайп: smykalovy
Спасибо:

agat50

Фотография
Программист
Дата: 15.11.2012
Ответить


Угу, была такая идейка. Сам стокшарпом не пользуюсь, собственные либы, но в рамках познания wcf сервисов мог бы помочь написать такой сервис под квик (т.е. п.4), со своей или стандартной стокшарповской либой.
Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 15.11.2012
Ответить


agat50 Перейти
Угу, была такая идейка. Сам стокшарпом не пользуюсь, собственные либы, но в рамках познания wcf сервисов мог бы помочь написать такой сервис под квик (т.е. п.4), со своей или стандартной стокшарповской либой.


Можно подумать насчет заменяемых модулей для сторонних коннекторов к торговым системам. Но этот блок точно самый минимальный. Вся реальная работа на другом конце - клиент-серверном взаимодействии.

Насчет WCF то я тут не уверен что он сможет справиться с нагрузкой. Хотя очень бы хотелось сделать решение на нем как на самом продвинутом с моей т.з. платформе.
Автор топика
Спасибо:

agat50

Фотография
Программист
Дата: 15.11.2012
Ответить


Mikhail Sukhov Перейти
agat50 Перейти
Угу, была такая идейка. Сам стокшарпом не пользуюсь, собственные либы, но в рамках познания wcf сервисов мог бы помочь написать такой сервис под квик (т.е. п.4), со своей или стандартной стокшарповской либой.


Можно подумать насчет заменяемых модулей для сторонних коннекторов к торговым системам. Но этот блок точно самый минимальный. Вся реальная работа на другом конце - клиент-серверном взаимодействии.

Насчет WCF то я тут не уверен что он сможет справиться с нагрузкой. Хотя очень бы хотелось сделать решение на нем как на самом продвинутом с моей т.з. платформе.


WCF привлекает встроенными фишками типа авторизации и шифрования. По скорости - насколько я понял, на 127.0.0.1 весь оверхед с лёгкостью влезает в 1мс, нагрузка - ну вроде проблемы только начиная с 3000+ клиентов. Думаю, правильная настройка позволит это оптимизировать. Собственно, я наверное напишу тест под свою библиотеку в рамках обучения как модуль, с авторизацией и т.п. + примеры коннектов на java, c, c#. А потом можно дописать интерфейсы к главному приложению. Как напишу пообщаемся поподробнее.

P.S. Вообще как вы мудро заметили, коннекторы хорошо бы размещать у самих клиентов. И коннектиться уже к ним с логикой на сервере.
Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 15.11.2012
Ответить


agat50 Перейти
коннекторы хорошо бы размещать у самих клиентов. И коннектиться уже к ним с логикой на сервере.


Логику коннектора как раз лучше размещать на сервере. Чтобы клиент, подключившись, не ломал себе голову о том, откуда данные, из Квика Плазы или еще откуда. Главное - это портфель. Выставил заявку по портфель 1, отправил на сервер, а сервер уже сам решает, в какой шлюз нужно отправлять заявку. У нас сейчас уже сделан такой роутинг, но он в рамках локального процесса.
Автор топика
Спасибо:

agat50

Фотография
Программист
Дата: 15.11.2012
Ответить


Mikhail Sukhov Перейти
agat50 Перейти
коннекторы хорошо бы размещать у самих клиентов. И коннектиться уже к ним с логикой на сервере.


Логику коннектора как раз лучше размещать на сервере. Чтобы клиент, подключившись, не ломал себе голову о том, откуда данные, из Квика Плазы или еще откуда. Главное - это портфель. Выставил заявку по портфель 1, отправил на сервер, а сервер уже сам решает, в какой шлюз нужно отправлять заявку. У нас сейчас уже сделан такой роутинг, но он в рамках локального процесса.


Ну тут вопрос терминологии. Есть такая сейчас модная вещь, "продажа сигналов". Смысл этого мне не особо понятен, но на примере удобно. Есть 1к клиентов с квиками, и 1 сервер который этим квикам рассылает тразакции и соответсвенно следит за исполнением. Вот я хочу сделать "сервис" на стороне клиента с квиком, который бы позволял к нему посылать транзакции, получать результаты о выполнении и т.п. Данные - вообще другой разговор. Сначала чисто торговый модуль - заявки, стоп заявки, создание, перемещение, снятие и т.п.
Спасибо:

westtrd

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


Mikhail Sukhov Перейти
agat50 Перейти
Угу, была такая идейка. Сам стокшарпом не пользуюсь, собственные либы, но в рамках познания wcf сервисов мог бы помочь написать такой сервис под квик (т.е. п.4), со своей или стандартной стокшарповской либой.


Можно подумать насчет заменяемых модулей для сторонних коннекторов к торговым системам. Но этот блок точно самый минимальный. Вся реальная работа на другом конце - клиент-серверном взаимодействии.

Насчет WCF то я тут не уверен что он сможет справиться с нагрузкой. Хотя очень бы хотелось сделать решение на нем как на самом продвинутом с моей т.з. платформе.


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

Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 15.11.2012
Ответить


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


На C# была LSE написана. У нас задача куда как скромнее.
Автор топика
Спасибо:

transdex

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


Mikhail Sukhov Перейти


На C# была LSE написана. У нас задача куда как скромнее.


Была... Не очень удачный пример.

Начало:

"Самые ранние стадии тестирования уже показывают соответствие мировым стандартам в области производительности, скорости и масштабируемости, необходимым для оказания услуг по вводу и реализации."

http://www.microsoft.com...ve/casestudy.aspx?id=451

Конец:

"Не так часто увидишь, чтобы столь крупная организация выбрасывала на помойку свою инфраструктуру, но и столь громкие публичные провалы, подобные тому, что случился у Лондонской фондовой биржи, случаются очень редко."

http://www.xakep.ru/post/48746/

Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 15.11.2012
Ответить


transdex Перейти

Была... Не очень удачный пример.


Еще как удачный. Она столько лет существовала на .NET и успешно справлялась с нагрузкой. У нас же все на порядки скромнее.
Автор топика
Спасибо:

transdex

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


Mikhail Sukhov Перейти
Она столько лет существовала на .NET и успешно справлялась с нагрузкой.


Не так долго. И не так успешно.

Microsoft платформа разрабатывалась 4 года, затраты 68 млн долларов. Введена в строй в 2007. Не вышла на проектные показатели latency. В 2008 первый масштабный крах. Потери трейдеров оцениваются в 3 млрд фунтов. в 2009 смена руководства биржи и решение о смене платформы. В январе 2010 начата миграция на linux платформу. В феврале 2011 закончена. Примерно так.

У нас конечно все скромнее.

Тем не менее, я затрудняюсь понять, для какой целевой группы трейдеров этот роутер предназначен.

Для начинающих(=сливающих)? Зачем им чего-то роутить.Тем более управлять чужими счетами.
Для продвинутых(=зарабатывающих)? Зачем им зоопарк из смарткомов и алоров? Управлять удаленно чужим Квиком на чужом писюке без UPSa через сети общего пользования?
Если идет речь о latency, причем здесь подгрузка истории дневок за 20 лет? (Слегка утрирую RollEyes )
Зачем подгружать стаканы с начала сессии, если это сервис (24х7). Или он будет падать 5 раз на дню?
И зачем здесь жестко вшитый риск-контроль? Вы ведь все равно потом напишите в лицензии, что ни за что не отвечаете Smile .

PS. Я не программист ( в смысле, код не пишу), просто хочется понять стоит ли уже начать откладывать деньги, выделенные на завтрак, с целью последующего приобретения сего замечательного девайса.






Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 16.11.2012
Ответить


transdex Перейти

Не так долго. И не так успешно.


Несколько лет, и успешно. Это когда на нем стали нереальных HFT появляться (не чета нашим), тогда и пришлось переделывать. Но я так понял, там просто сама система была кривая, а не язык программирования.

Да что я говорю. До ноября 2012 биржа РТС крутилась на SQL. И ничего, никто не умер. Так что тут C# будет выше крыше.

У нас конечно все скромнее.

transdex Перейти

Для продвинутых(=зарабатывающих)? Зачем им зоопарк из смарткомов и алоров? Управлять удаленно чужим Квиком на чужом писюке без UPSa через сети общего пользования?


Начинающие-продвинутые - это неправильная классификация. Я описал в начале юзер таргетинг.

transdex Перейти

Если идет речь о latency, причем здесь подгрузка истории дневок за 20 лет? (Слегка утрирую RollEyes )


Речь о latency я не поднимал.

transdex Перейти

Зачем подгружать стаканы с начала сессии, если это сервис (24х7). Или он будет падать 5 раз на дню?


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

transdex Перейти

И зачем здесь жестко вшитый риск-контроль? Вы ведь все равно потом напишите в лицензии, что ни за что не отвечаете Smile .


А причем тут лицензия S# и риск менеджмент? Это как кровать с физикой сравнивать. Несравнимые понятия.

transdex Перейти

PS. Я не программист ( в смысле, код не пишу), просто хочется понять стоит ли уже начать откладывать деньги, выделенные на завтрак, с целью последующего приобретения сего замечательного девайса.


А кто сказал, что это на продажу?Laugh
Автор топика
Спасибо:

agat50

Фотография
Программист
Дата: 16.11.2012
Ответить


transdex Перейти
....



На линуксе она кстати тоже падала у них потом вроде. Дело не в системе, можно моно на линуксе сделать. Вообще пройдёмся по пунктам.

п1 - спорно, но наверное удобно когда хочется отделить логику от терминала, для защиты идей например, демонстрации страт и т.п.

п2 - удобно, если есть много ботов написанных разными людьми, у меня всё в одной программе крутится, в пулах задач, но я пишу один.

п3 - дополнительная программа аля удалённый терминал, проще имхо vnc.

п4 - понятно, имхо нужно редко, данные имхо надо хранить в базах.

п5 - удобно, когда клиент может сам настроить на какой инструменте торговать, частота сделок мб, доступ к информации. Но имхо клиент это не оценит, чужая прога на компе всё-равно.

п6, п7 - имхо, не нужно

п8, п9 - думается в связи с кривостью экспорта данных из квика, многим нужен нормальный датафид, реал тайм свечки, мб не особо быстрый, но удобный в работе из программ. Лично я готов платить, например, 250р в месяц за такую вещь.

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

transdex

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


Mikhail Sukhov Перейти

А кто сказал, что это на продажу?Laugh



Именно это особенно непонятно!
Возьмем к примеру продукт Smartquant под названием Quantrouter,

http://www.smartquant.com/quantrouter.php

который они предлагают за $600 в месяц и который некоторыми чертами напоминает предлагаемый Вами. (название точно похоже - роутер... Smile )
Продукт явно на продажу. Подозреваю, что его функциональность (и намного больше) легко реализовать слегка подправив архитектуру основного приложения Openquant и включив туда очереди. Возможно и MSMQ хватит, не говоря уже о каком-нибудь Qpid.
Но такой подход имеет один маленький недостаток. Его невозможно продать. Например MSMQ - это штатный компонент Windows. Кто ж его купит? Но если делать для себя, почему не использовать уже сделанное, и сделанное хорошо?

Как весьма абстрактный пример - роутер плазы. Сервис, который подключается к локальному роутеру плазы (P2_ClientGate), принимет потоки, парсит, раскладывает сообщения о событиях по очередям. И все... Минимум кода - да. И ЧТО там на другом конце очереди , и ГДЕ это, и сколько ИХ, и сколько раз ОНИ падают в час уже никого не волнует. И если что-то там упало, то не нужно ничего подгружать с начала сессии, просто перечитать нужную очередь сначала.
Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 16.11.2012
Ответить


transdex Перейти
Возможно и MSMQ хватит


Роутинг включает транспорт. Обратное неверно.

transdex Перейти

Как весьма абстрактный пример - роутер плазы.


Роутер - это класс программ, а не конкретная программа.
Автор топика
Спасибо:

transdex

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


Mikhail Sukhov Перейти


Роутинг включает транспорт. Обратное неверно.



MSMQ это не транспорт, а служба доставки сообщений. Без роутинга, в том числе динамического, это просто невозможно осуществить.

Mikhail Sukhov Перейти


Роутер - это класс программ, а не конкретная программа.


Роутер вообще-то класс устройств, а не программ, поскольку бывают чисто железные роутеры (типа рубильника). А когда-то роутинг телефонных сообщений осуществляли барышни на телефонных станциях.
И если РТС называет свою программу (P2MQRouter) конкретно роутером, почему другую нельзя?



Спасибо:

Serg

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


Идея хорошая. Хочу участвовать. skype, codeplex: sergshabal
Спасибо:

Alexander

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


Mikhail Sukhov Перейти
Насчет WCF то я тут не уверен что он сможет справиться с нагрузкой. Хотя очень бы хотелось сделать решение на нем как на самом продвинутом с моей т.з. платформе.


Лучше присмотреться к activemq \ zeromq всё же.

Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 18.11.2012
Ответить


Alexander Mukhanchikov Перейти

Лучше присмотреться к activemq \ zeromq всё же.


Это чисто транспорт. А WCF - это high level front end. Тоесть, ØMQ можно и в WCF использовать. А можно сделать и несколько точек доступа. В любом случае, лучше сделать хоть что, а там уже смотреть что нужно подтянуть. Перфекционизмом позаниматься.

Я нисколько не сомневаюсь в скорости передачи WCF. Меня смущал только xml протокол. Но я потом подумал, вспомнил fix, и понял, что для такого решения это не будет излишним оверхедом. Тем более, это сымитирует реальное fix общение, пусть и в другом xml формате.
Автор топика
Спасибо:

transdex

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


Microsoft открыла коды WCF channel для проекта Apach Qpid (AMQP).

http://blogs.technet.com...-qpid-moves-forward.aspx


Using the Qpid WCF client:

http://qpid.apache.org/b...ache-Qpid/html/ch04.html

AMQP (Advanced Message Queuing Protocol) — открытый протокол для передачи сообщений между компонентами системы. Основная идея состоит в том, что отдельные подсистемы (или независимые приложения) могут обмениваться произвольным образом сообщениями через AMQP-брокер, который осуществляет маршрутизацию, возможно гарантирует доставку, распределение потоков данных, подписку на нужные типы сообщений.
Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 19.11.2012
Ответить


Мы начинаем. Сейчас 5 человек (считал по тем, кто прислал скайп контакт). Больше желающих нет?
Автор топика
Спасибо:

dvoris

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


Mikhail Sukhov Перейти
Мы начинаем. Сейчас 5 человек (считал по тем, кто прислал скайп контакт). Больше желающих нет?

Есть :)
Спасибо:


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

loading
clippy