English
Русский
中文
Español
Português
日本語
Есть идея сделать совместный проект роутера маркет-данных и транзакций.
Идея заключается в создании отдельного (=внешнее) приложения, которое бы могло запускаться (как обычное exe или как сервис), настраиваться, подключаться к торговым системам (всем, что поддерживает S#). Приложение выступает как серверное, и дает возможность подключаться из других программ (как на локальном компьютере, так и через интернет). Такими клиентами смогли бы выступать роботы, аналитические программы, торговые системы, ищущие данные и т.д.
Что дает такая программа:
Возможность подключаться к ТС вне локального компьютера. Например, иметь возможность слать заявки на другой компьютер. Особенно полезно для тех, кто управляет чужими счетами, и при этом клиент сильно стремается давать ключи. Или в рабочее время за счет работодателя пишет роботов и торгует с работы.😊
Позволять подключаться из разных программ к одной ТС. Например Квик Смарт и Альфа не дают торговать нескольким роботам одновременно. А запихивать новый (=глючный) робот в один процесс со старым (=стабильным) роботом, чтобы последний не отбросил копыта при смерти первого, не самый простой процесс.
Отделить код роутера от робота, и в случае падении последнего, дать возможность закрыть позиции вручную, подключившись в данному роутеру. Предполагается, что такой роутер должен содержать минимум логики, поэтому по идее должен работать стабильнее.
Возможность отделиться от ограничение разрядности некоторых систем. Квик, например, дает только 32 бита, и роботу позволено кушать всего 1.5 гига.
Встроенные возможности риск-контроля. Частично пункт 3 + примитивные (но железные) настройки, не позволяющие роботу сделать непоправимое. Как бы мы ни старались в новых версиях S#😂
Простенький кабинет с возможностью детальной статистики. Не аналитика, но данные все, чтобы можно было выгрузить как раз в аналитику.
Эмуляционный режим, чтобы проверять робота на настоящих данных с настоящими сетевыми лагами.
Умный роутинг данных с фильтрами, компактный протокол.
Интеграция роутера с Гидрой, чтобы через единую точку получать еще и исторические данные. Да-да, стаканы с начала сессии и ОИ, тики за неделю для формирования стартовой истории, свечки по СнП за год и прочее-прочее.
Думаю, у многих тут уже потекли слюньки. Поэтому сразу определимся зачем я все это написал. Сделать эту работу лучше командой. Проект этот в любом случае стартанет в рамках S#. Но что точно - он не будет доступен ни на боксе, ни на кодеплексе.😉 Поэтому, я предлагаю определится всем тем, кто уже замышлял о подобном (а я уверен, что эти 9 фич касаются практически всех, кто пишет и работает с ботами), и отписаться (лучший контакт - скайп контакт). Разработка будет вестись в закрытом репозитарии (не на S# сервере, а новое место). Все, кто будет участвовать, будут иметь доступ к результату (возможно к версиям 2.0 и т.д., если таковые будут). Все, кто не будет - я думаю объяснять не нужно.
Kommentare (22)
Anmelden oder Konto erstellen, Melden Sie sich an oder registrieren Sie sich, um einen Kommentar zu hinterlassen
Замечательная идея! Сейчас свободного времени немного, но, надеюсь, смогу нанести непоправимую пользу :)
Мой скайп: 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 человек (считал по тем, кто прислал скайп контакт). Больше желающих нет?