English
Русский
中文
Español
Deutsch
Português
Есть идея сделать совместный проект роутера маркет-данных и транзакций.
Идея заключается в создании отдельного (=внешнее) приложения, которое бы могло запускаться (как обычное exe или как сервис), настраиваться, подключаться к торговым системам (всем, что поддерживает S#). Приложение выступает как серверное, и дает возможность подключаться из других программ (как на локальном компьютере, так и через интернет). Такими клиентами смогли бы выступать роботы, аналитические программы, торговые системы, ищущие данные и т.д.
Что дает такая программа:
Возможность подключаться к ТС вне локального компьютера. Например, иметь возможность слать заявки на другой компьютер. Особенно полезно для тех, кто управляет чужими счетами, и при этом клиент сильно стремается давать ключи. Или в рабочее время за счет работодателя пишет роботов и торгует с работы.😊
Позволять подключаться из разных программ к одной ТС. Например Квик Смарт и Альфа не дают торговать нескольким роботам одновременно. А запихивать новый (=глючный) робот в один процесс со старым (=стабильным) роботом, чтобы последний не отбросил копыта при смерти первого, не самый простой процесс.
Отделить код роутера от робота, и в случае падении последнего, дать возможность закрыть позиции вручную, подключившись в данному роутеру. Предполагается, что такой роутер должен содержать минимум логики, поэтому по идее должен работать стабильнее.
Возможность отделиться от ограничение разрядности некоторых систем. Квик, например, дает только 32 бита, и роботу позволено кушать всего 1.5 гига.
Встроенные возможности риск-контроля. Частично пункт 3 + примитивные (но железные) настройки, не позволяющие роботу сделать непоправимое. Как бы мы ни старались в новых версиях S#😂
Простенький кабинет с возможностью детальной статистики. Не аналитика, но данные все, чтобы можно было выгрузить как раз в аналитику.
Эмуляционный режим, чтобы проверять робота на настоящих данных с настоящими сетевыми лагами.
Умный роутинг данных с фильтрами, компактный протокол.
Интеграция роутера с Гидрой, чтобы через единую точку получать еще и исторические данные. Да-да, стаканы с начала сессии и ОИ, тики за неделю для формирования стартовой истории, свечки по СнП за год и прочее-прочее.
Думаю, у многих тут уже потекли слюньки. Поэтому сразу определимся зачем я все это написал. Сделать эту работу лучше командой. Проект этот в любом случае стартанет в рамках S#. Но что точно - он не будет доступен ни на боксе, ни на кодеплексе.😉 Поэтому, я предлагаю определится всем тем, кто уже замышлял о подобном (а я уверен, что эти 9 фич касаются практически всех, кто пишет и работает с ботами), и отписаться (лучший контакт - скайп контакт). Разработка будет вестись в закрытом репозитарии (не на S# сервере, а новое место). Все, кто будет участвовать, будут иметь доступ к результату (возможно к версиям 2.0 и т.д., если таковые будут). Все, кто не будет - я думаю объяснять не нужно.
コメント (22)
ログイン または アカウントを作成, コメントを残すにはログインまたは新規登録してください
Замечательная идея! Сейчас свободного времени немного, но, надеюсь, смогу нанести непоправимую пользу :)
Мой скайп: smykalovy
Угу, была такая идейка. Сам стокшарпом не пользуюсь, собственные либы, но в рамках познания wcf сервисов мог бы помочь написать такой сервис под квик (т.е. п.4), со своей или стандартной стокшарповской либой.
Можно подумать насчет заменяемых модулей для сторонних коннекторов к торговым системам. Но этот блок точно самый минимальный. Вся реальная работа на другом конце - клиент-серверном взаимодействии.
Насчет WCF то я тут не уверен что он сможет справиться с нагрузкой. Хотя очень бы хотелось сделать решение на нем как на самом продвинутом с моей т.з. платформе.
WCF привлекает встроенными фишками типа авторизации и шифрования. По скорости - насколько я понял, на 127.0.0.1 весь оверхед с лёгкостью влезает в 1мс, нагрузка - ну вроде проблемы только начиная с 3000+ клиентов. Думаю, правильная настройка позволит это оптимизировать. Собственно, я наверное напишу тест под свою библиотеку в рамках обучения как модуль, с авторизацией и т.п. + примеры коннектов на java, c, c#. А потом можно дописать интерфейсы к главному приложению. Как напишу пообщаемся поподробнее.
P.S. Вообще как вы мудро заметили, коннекторы хорошо бы размещать у самих клиентов. И коннектиться уже к ним с логикой на сервере.
Логику коннектора как раз лучше размещать на сервере. Чтобы клиент, подключившись, не ломал себе голову о том, откуда данные, из Квика Плазы или еще откуда. Главное - это портфель. Выставил заявку по портфель 1, отправил на сервер, а сервер уже сам решает, в какой шлюз нужно отправлять заявку. У нас сейчас уже сделан такой роутинг, но он в рамках локального процесса.
Ну тут вопрос терминологии. Есть такая сейчас модная вещь, "продажа сигналов". Смысл этого мне не особо понятен, но на примере удобно. Есть 1к клиентов с квиками, и 1 сервер который этим квикам рассылает тразакции и соответсвенно следит за исполнением. Вот я хочу сделать "сервис" на стороне клиента с квиком, который бы позволял к нему посылать транзакции, получать результаты о выполнении и т.п. Данные - вообще другой разговор. Сначала чисто торговый модуль - заявки, стоп заявки, создание, перемещение, снятие и т.п.
Я вот не уверен, что по ключевым сервисам шарп в состоянии с разумной латентностью справляться с подобной нагрузкой.
На C# была LSE написана. У нас задача куда как скромнее.
Была... Не очень удачный пример.
Начало:
"Самые ранние стадии тестирования уже показывают соответствие мировым стандартам в области производительности, скорости и масштабируемости, необходимым для оказания услуг по вводу и реализации."
http://www.microsoft.com/Rus/Casestudies_archive/casestudy.aspx?id=451
Конец:
"Не так часто увидишь, чтобы столь крупная организация выбрасывала на помойку свою инфраструктуру, но и столь громкие публичные провалы, подобные тому, что случился у Лондонской фондовой биржи, случаются очень редко."
http://www.xakep.ru/post/48746/
Еще как удачный. Она столько лет существовала на .NET и успешно справлялась с нагрузкой. У нас же все на порядки скромнее.
Не так долго. И не так успешно.
Microsoft платформа разрабатывалась 4 года, затраты 68 млн долларов. Введена в строй в 2007. Не вышла на проектные показатели latency. В 2008 первый масштабный крах. Потери трейдеров оцениваются в 3 млрд фунтов. в 2009 смена руководства биржи и решение о смене платформы. В январе 2010 начата миграция на linux платформу. В феврале 2011 закончена. Примерно так.
У нас конечно все скромнее.
Тем не менее, я затрудняюсь понять, для какой целевой группы трейдеров этот роутер предназначен.
Для начинающих(=сливающих)? Зачем им чего-то роутить.Тем более управлять чужими счетами. Для продвинутых(=зарабатывающих)? Зачем им зоопарк из смарткомов и алоров? Управлять удаленно чужим Квиком на чужом писюке без UPSa через сети общего пользования? Если идет речь о latency, причем здесь подгрузка истории дневок за 20 лет? (Слегка утрирую 🙄 ) Зачем подгружать стаканы с начала сессии, если это сервис (24х7). Или он будет падать 5 раз на дню? И зачем здесь жестко вшитый риск-контроль? Вы ведь все равно потом напишите в лицензии, что ни за что не отвечаете 🙂 .
PS. Я не программист ( в смысле, код не пишу), просто хочется понять стоит ли уже начать откладывать деньги, выделенные на завтрак, с целью последующего приобретения сего замечательного девайса.
Несколько лет, и успешно. Это когда на нем стали нереальных HFT появляться (не чета нашим), тогда и пришлось переделывать. Но я так понял, там просто сама система была кривая, а не язык программирования.
Да что я говорю. До ноября 2012 биржа РТС крутилась на SQL. И ничего, никто не умер. Так что тут C# будет выше крыше.
У нас конечно все скромнее.
Начинающие-продвинутые - это неправильная классификация. Я описал в начале юзер таргетинг.
Речь о latency я не поднимал.
Робот может падать раз 5 в час, и он теряет данные как только упал. Предполагается что сервер привнесет больше стабильности за счет своей минимальной логики.
А причем тут лицензия S# и риск менеджмент? Это как кровать с физикой сравнивать. Несравнимые понятия.
А кто сказал, что это на продажу?😂
На линуксе она кстати тоже падала у них потом вроде. Дело не в системе, можно моно на линуксе сделать. Вообще пройдёмся по пунктам.
п1 - спорно, но наверное удобно когда хочется отделить логику от терминала, для защиты идей например, демонстрации страт и т.п.
п2 - удобно, если есть много ботов написанных разными людьми, у меня всё в одной программе крутится, в пулах задач, но я пишу один.
п3 - дополнительная программа аля удалённый терминал, проще имхо vnc.
п4 - понятно, имхо нужно редко, данные имхо надо хранить в базах.
п5 - удобно, когда клиент может сам настроить на какой инструменте торговать, частота сделок мб, доступ к информации. Но имхо клиент это не оценит, чужая прога на компе всё-равно.
п6, п7 - имхо, не нужно
п8, п9 - думается в связи с кривостью экспорта данных из квика, многим нужен нормальный датафид, реал тайм свечки, мб не особо быстрый, но удобный в работе из программ. Лично я готов платить, например, 250р в месяц за такую вещь.
Вопрос зачем нужен центральный сервер. Теоретически можно там хостить ботов, раздавая права и т.п. В остальном это тупо датафид + доступ к торговым терминалам через интерфейсы, мб это раздельно проще реализовать.
Именно это особенно непонятно! Возьмем к примеру продукт Smartquant под названием Quantrouter,
http://www.smartquant.com/quantrouter.php
который они предлагают за $600 в месяц и который некоторыми чертами напоминает предлагаемый Вами. (название точно похоже - роутер... 🙂 ) Продукт явно на продажу. Подозреваю, что его функциональность (и намного больше) легко реализовать слегка подправив архитектуру основного приложения Openquant и включив туда очереди. Возможно и MSMQ хватит, не говоря уже о каком-нибудь Qpid. Но такой подход имеет один маленький недостаток. Его невозможно продать. Например MSMQ - это штатный компонент Windows. Кто ж его купит? Но если делать для себя, почему не использовать уже сделанное, и сделанное хорошо?
Как весьма абстрактный пример - роутер плазы. Сервис, который подключается к локальному роутеру плазы (P2_ClientGate), принимет потоки, парсит, раскладывает сообщения о событиях по очередям. И все... Минимум кода - да. И ЧТО там на другом конце очереди , и ГДЕ это, и сколько ИХ, и сколько раз ОНИ падают в час уже никого не волнует. И если что-то там упало, то не нужно ничего подгружать с начала сессии, просто перечитать нужную очередь сначала.
Роутинг включает транспорт. Обратное неверно.
Роутер - это класс программ, а не конкретная программа.
MSMQ это не транспорт, а служба доставки сообщений. Без роутинга, в том числе динамического, это просто невозможно осуществить.
Роутер вообще-то класс устройств, а не программ, поскольку бывают чисто железные роутеры (типа рубильника). А когда-то роутинг телефонных сообщений осуществляли барышни на телефонных станциях. И если РТС называет свою программу (P2MQRouter) конкретно роутером, почему другую нельзя?
Лучше присмотреться к activemq \ zeromq всё же.
Это чисто транспорт. А WCF - это high level front end. Тоесть, ØMQ можно и в WCF использовать. А можно сделать и несколько точек доступа. В любом случае, лучше сделать хоть что, а там уже смотреть что нужно подтянуть. Перфекционизмом позаниматься.
Я нисколько не сомневаюсь в скорости передачи WCF. Меня смущал только xml протокол. Но я потом подумал, вспомнил fix, и понял, что для такого решения это не будет излишним оверхедом. Тем более, это сымитирует реальное fix общение, пусть и в другом xml формате.
Идея хорошая. Хочу участвовать. skype, codeplex: sergshabal
Microsoft открыла коды WCF channel для проекта Apach Qpid (AMQP).
http://blogs.technet.com/b/port25/archive/2009/09/29/apache-qpid-moves-forward.aspx
Using the Qpid WCF client:
http://qpid.apache.org/books/0.14/Programming-In-Apache-Qpid/html/ch04.html
AMQP (Advanced Message Queuing Protocol) — открытый протокол для передачи сообщений между компонентами системы. Основная идея состоит в том, что отдельные подсистемы (или независимые приложения) могут обмениваться произвольным образом сообщениями через AMQP-брокер, который осуществляет маршрутизацию, возможно гарантирует доставку, распределение потоков данных, подписку на нужные типы сообщений.
Мы начинаем. Сейчас 5 человек (считал по тем, кто прислал скайп контакт). Больше желающих нет?