Август 12th, 2014

Обзор подключения к торгам через Api SmartCom и Api Quik

, Must-read, by Алексей Ван.

Ты программист и выбираешь Api для подключения к бирже!? Это статья для тебя… В ней я опишу свой скромный опыт написания ботов с подключением через SmartCom и Quik. Попробую сформулировать своё отношение к одному и второму способу, а также опишу их сильные и слабые стороны БубноТанцы Господа. Я работаю по старинке и пишу свои приводы. Не пользуясь универсальными Api вроде StockSharp или TsLab. Поэтому любителям этих ваших модных Платных_Закрытых_Библиотеко_Каракасов просьба идти мимо. И мне это не предлагать!

Поскольку статья получилась довольно ядовитая, сначала опишу хорошие стороны одного и второго Api.

Хорошо:

Главная положительная черта Quik Api это надёжность. Единожды настроенное подключение TRANS2QUIK.dll не отсохнет и не повиснет. С DDE немного сложнее, но если правильно принимать и обрабатывать потоки, соединение также стабильно.

SmartCom хорош в плане простого и понятного интерфейса, человеко — ориентированностью, а также высокой скоростью выставления заявок (но тут всё не просто).

  Quik Api

Собственно к Quik нет полноценного Api для подключения. Т.е. не существует волшебной (открытой и бесплатной) библиотеки, подключив которую к своему проекту, можно было бы выкачивать из Quik данные и тут же отправлять через неё заявки. Вместо этого есть следующая связка :

 

Quik

Рис.2. DDE + TRANS2QUIK.dll + Qple + over9000Table = Quik Api

  Т.е. чтобы начать отдавать комисс со скоростью несколько раз в секунду потребуется:

  1. Поднять в своей программе DDE сервер
  2. Разобраться со встроенным в Quik языком Qple, чтобы можно было создавать (ну или хотя бы редактировать) скрипты по конвертации свечных массивов в таблицы.
  3.  Скрупулёзно, со слезами, создать эти 5 — 10 таблиц, данные из которых  понадобятся твоему роботу. Вывести их и принять у себя в роботе.
  4.  Прикрутить TRANS2QUIK.dll к своему проекту, и научиться подавать заявки, через этот мерзкопакостный интефейс.

 

Quik не удобен и на его изучение и реализацию придётся потратить очень много времени. На сайте разработчиков отсутствуют живые, и простые примеры с открытым кодом на которых начинающие программисты могли бы писать своих роботов. Библиотека TRANS2QUIK морально устарела лет 10 назад и хромает описание. Поддержка отсутствует. Всё сводиться к «Мы записали вашу просьбу» и «Смотрите мануал».

Отсутствуют некоторые типы ордеров. Стоп-рынок например. Если сработал стоп, зачем парится с лимитками? Всё плохо и надо крыть по любой цене. Счас напишут что надо связными заявками пользоваться. Хорошо. Только нахрена эти сложности? Там и так чтобы первую заявку отправить неделю надо колдовать.

Ещё год назад в ARQA на сайте и демо доступ не выдавали. Похоже договорились через откаты  каким-то чудом со всеми брокерами России и думают что развиваться в сторону конечного потребителя (трейдера) вообще не нужно. Что ощущается во всём.

Кроме того Quik не очень технологичен и уступает в скорости вообще всем… Есть мнение что пройдёт лет 5 — 10 и про такую платформу иже и не вспомнят…

 

  SmartCom 3.0 1.

 

У них есть инструкция! Красочная и понятная. Никакой неопределённости и плясок с бубнами*. Берём библиотеку, цепляем к проекту и всё*! Подключение* готово*!

У них есть живой пример! Т.е. небольшая программа на C#, в которой доступно показано как пользоваться теми или иными штуками из библиотеки. Для начинающего программиста это вообще мечта, попробовать просто пришить свою логику к готовому приводу. И судя по обсуждениям на форуме продукта, многие так и делают.

Конечно же, после своих не простых отношений с Quik, я был очень доволен SmartCom, когда начал с ним знакомство. Идея хороша, как и попытка её преподнести. Вот как это должно было выглядеть:

 

Смарт1

Рис.3. Простой Api SmartCom

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

2. Потоки уходящие с запросами могут вообще не возвратиться и в дальнейшем при попытке их вызвать всё опять падает   Ну и ладно, выходим из положения:

Смарт2

Рис.4. Api SmartCom

    3. Далее просто пошли не контролируемые потери связи. Читаем на форумах. Ни с того, ни с сего, сервер может потеряться от 2 до 10 раз в день. Пишут что это плата за скорость… Хорошо.

4. Далее выясняем… Не после всех потерей соединений можно восстановить связь с сервером. Нужно делать возможность полностью перегрузить Локальный сервер, переподписать все события и проч… Делаем поток, следящий за соединением, ничего особенного:

Смарт3

Рис.4. Пример простейшей схемы в Diagram Designer

далее…

5.     Заявки могут испаряться при передаче их серверу вообще без обратной связи. При этом сервер может, как уже быть мёртвым в этот момент, так и в обычном состояние при смерти. Надо делать потоки Эскорты каждой заявке, которые будут следить через определённое время, что произошло, дошла ли заявка, пришёл ли какой либо отклик или нет, что с потоком, который нёс заявку.

6.    Сервер, не смотря на то, что пишет, что есть Connect может уже умереть в это время и любое действие вызывает исключение. Включая AccessViolationException. Поэтому надо каждый вызов сервера делать левым потоком, с возможностью при перехвате исключения из любого места, или если какой-то поток перестал отвечать, уничтожать локальный сервер СмартКом и создать новый.

7.    Сервер может отваливаться по частям. В любой момент могут отсохнуть:

Данные стакана

Тики

Данные об изменившихся заявках

Выгрузка свечей и т.д.

Всё это может случиться как по отдельности, так и всё сразу.

В общем-то, все проблемы решаемы и каждая в отдельности не такая уж и страшная, но вот только ЗАЧЕМ это нужно?

 

Смарт4

Рис.5. Невероятно упрощённая обёртка глючного Api SmartCom

    8. По ночам из SmartCom иногда продолжают поступать свечи, в виде пустых интервалов! Я плакал…

9. Тестовый доступ к SmartCom отличается от реального!!! На тестовом сервере заявки периодически не проходят и отвергаются системой с объяснением: «Нельзя открывать разнонаправленные позиции с одного счёта»(ну или чёт похожее). И!! Иногда заявка сначала отвергается системой, причём приходит подтверждение о том, что она отвергнута штатно (System cancel), а затем (О ЧУДО!), через какое-то время (от нескольких секунд, до нескольких минут), заявка всё же проходит. Что в купе, а особенно последнее, не даёт нормально оттестировать SmartCom шлюз в своём роботе на демо счёте. И приходиться допиливать подключение уже на реальном счёте.

10. Наличие во многих местах различных проверок сказывается на конечной скорости выставления заявок и приёма данных.

Из всех этих проблем, очевидно, что SmartCom не очень надёжен. Хорошая такая, бэта версия, библиотеки для подключения к бирже. Не больше. Вот торгует у меня робот, вроде всё давно оттестировано, и автоматически, и в боевых условиях, и на учебном счету и реальном… А я всё равно просыпаюсь по ночам и бегу посмотреть, как у него дела и не случилось ли новых косяков в шлюзе. Которых, по всей видимости, и сосчитать не получиться.

 

Резюме

Конечно же, и первый и второй способ подключения к бирже одинаково хороши.

Но с Quik тут понятно. Старичка начали делать в нулевых и серьёзных претензий к разработчикам сложно предъявлять (постебать только остаётся). Делали из того что было и так, как это было заведено в то время, через …у. А теперь «старички» из начальства не дают проекту двигаться, тянут на дно балластом. Ну а что касается SmartCom, но это конечно полное разочарование. Ну как можно оставить столько багов в клиентской части, и напрочь забыть об оповещении о ошибках? БЛДЖАД!! Ну Вы хоть исключений в него добавьте, чтобы было понятно что с ним происходит!

Что же выбрать из этих отечественных чудо гуано платформ?  

Для уверенных в себе программистов SmartCom. Когда все исключительные ситуации выловлены, потоки изолированы, ордера сопровождены и любое неповиновение сервера, тут же вызывает его расстрел, а через секунду всё работает как надо, то работа со SmartCom начинает приносить радость.   Для тех, кто не в состоянии проконтролировать параллельную работу 20 потоков, однозначно Quik. Несмотря на свою топорность, он весьма не требователен и очень стабилен. Что на первых порах гораздо важнее скорости. Хотя тут следует джва раза подумать. В том, что SmartCom через пару версий станет стабильным, у меня сомнений нет, а вот в том, что Quik станет быстрее и понятнее, очень большие…

 

Ссылки:

http://quik.ru/ — сайт Quik

http://quik.ru/forum/ideas/7039/7039/ — один из эпичных срачей на форуме разработчиков, в котором юзеры, одурев от наглости, с 2005 года (ДЕВЯТЬ ЛЕТ!!!) пытаются безрезультатно добиться добавления Трэйлинг стопа в терминал. При этом ребята из тех поддержки, с каменным лицом, тролят умоляющих пользователей. Почитайте. В этом весь Quik…

http://www.itinvest.ru/software/smartcom/ — nuff said

http://smart-lab.ru/company/stocksharp/blog/105916.php — сравнение скорости выставление заявок SmartCom, Quik и Plaza II

http://forum.moex.com/viewtopic.asp?t=25629 — тоже, что и сверху, интересны комментарии разработчиков. Видимо на SmartCom 3 возлагались большие надежды в области безопасности соединения. Не вышло…

Back Top

Responses to “Обзор подключения к торгам через Api SmartCom и Api Quik”

  1. сразу скажу, что программист я очень слабый 100% самоучка, но тем не менее позволю себе высказаться.. ДДЕ коннект с квиком печальная вещь, жрет память, норовит отвалится и тд., для дешевого паркинга с небольшой оперативкой это не приемлемо вообще, загружать выгружать квик раз в сутки = усложнять. культурным выходом видится коннектор от bot4sale (раздает его за «сколько не жалко»), он состоит из 2-х модулей. Один на луа коллбэками тянет инфо из квика и шлет это все во 2-й модуль, com сервер к которому уже можно обращаться из любого языка программирования в тч си шарпа. память не жрет вообще, все стабильно. На фоне ДДЕ это просто мегавещь. Луа сам по себе тоже супер, простые алгоритмы могут быть созданы за считанные дни людьми с очень ограниченной компетенцией в программировании. C# — это все не на 5 минут (недель)

Добавить комментарий

Ваш e-mail не будет опубликован.