RoutingServer
Atom
14.11.2012
Mikhail Sukhov


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

Идея заключается в создании отдельного (=внешнее) приложения, которое бы могло запускаться (как обычное 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  >
Yury Smykalov

Фотография
Дата: 14.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

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


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


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

transdex

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


Mikhail Sukhov


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


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

Начало:

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

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

Конец:

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

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

Спасибо:

Mikhail Sukhov

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


transdex

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


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

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

loading
clippy