RoutingServer
Atom
14.11.2012


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

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

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

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

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

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

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

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

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

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

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

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

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



Спасибо:


< 1 2 3  >
transdex

Фотография
Дата: 16.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...che-Qpid/html/ch04.html

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

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

loading
clippy