<HELP> for explanation

Блог им. Tyam

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

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

     Главная положительная черта QuikApi  это надёжность. Единожды настроенное подключение TRANS2QUIK.dll не отсохнет и не повиснет. С DDEнемного сложнее, но если правильно принимать и обрабатывать потоки, соединение также стабильно.
    SmartCom хорош в плане простого и понятного интерфейса, человеко — ориентированностью, а также высокой скоростью выставления заявок (но тут всё не просто).
    QuikApi
 
    Собственно к Quik нет полноценного Api  для подключения. Т.е. не существует волшебной (открытой и бесплатной) штуки, подключив которую к своему проекту, можно было бы выкачивать из Quik данные и тут же отправлять через неё заявки.
    Вместо этого есть следующая связка :
Обзор подключения к торгам через Api SmartCom и Quik
 
 
Рис.1. DDE + TRANS2QUIK.dll + Qple + over9000Table = Quik Api
 
    Т.е. чтобы начать отдавать комисс со скоростью несколько раз в секунду потребуется:
  1. Поднять в своей программе DDE сервер
  2. Разобраться со встроенным в Quik языком Qple, чтобы можно было создавать (ну или хотя бы редактировать) скрипты по конвертации свечных массивов в таблицы.
  3. Скрупулёзно, со слезами, создать эти 5 — 10 таблиц, данные из которых  понадобятся твоему роботу. Вывести их и принять у себя в роботе.
  4. Прикрутить TRANS2QUIK.dll к своему проекту, и научиться подавать заявки, через этот мерзкопакостный интефейс.
 
    Quik не удобен и на его изучение и реализацию придётся потратить очень много времени. На сайте разработчиков отсутствуют живые, и простые примеры с открытым кодом на которых начинающие программисты могли бы писать своих роботов. Библиотека TRANS2QUIK морально устарела лет 10 назад и хромает описание. Поддержка отсутствует. Всё сводиться к «Мы записали вашу просьбу» и «Смотрите мануал».
 
    Отсутствуют некоторые типы ордеров. Стоп-рынок например. Если сработал стоп, зачем парится с лимитками? Всё плохо и надо крыть по любой цене. Счас напишут что надо связными заявками пользоваться. Хорошо. Только нахрена эти сложности? Там и так чтобы первую заявку отправить неделю надо колдовать.
 
    Ещё год назад в ARQA на сайте и демо доступ не выдавали. Похоже договорились через откаты  каким-то чудом со всеми брокерами России и думают что развиваться в сторону конечного потребителя (трейдера) вообще не нужно. Что ощущается во всём. 
    Кроме того Quikне очень технологичен и уступает в скорости вообще всем... 
 
 
SmartCom 3.0
   
     1. У них есть инструкция! Красочная и понятная. Никакой неопределённости и плясок с бубнами*. Берём библиотеку, цепляем к проекту и всё*! Подключение* готово*!
 
    2.     У них на сайте есть живой пример! Т.е. небольшая программа на C#, в которой доступно показано как пользоваться теми или иными штуками из библиотеки. Для начинающего программиста это вообще мечта, попробовать просто пришить свою логику к готовому приводу. И судя по обсуждениям на форуме продукта, многие так и делают.
 
    Конечно же, после своих не простых отношений с Quik, я был очень доволен SmartCom, когда начал с ним знакомство. Идея хороша, как и попытка её преподнести. Вот как это должно было выглядеть:
 Обзор подключения к торгам через Api SmartCom и Quik
 
Рис.2. Простой ApiSmartCom
 
    1. Очень быстро выяснилось что занимать потоки приходящие с сервера больше чем на несколько секунд нельзя, т.к. это вызывает падение местного сервера
    2. Потоки уходящие с запросами могут вообще не возвратиться и в дальнейшем при попытке их вызвать всё опять падает
 
     Ну и ладно, выходим из положения:
 
 Обзор подключения к торгам через Api SmartCom и Quik
Рис.3. ApiSmartCom
 
    3. Далее просто пошли не контролируемые потери связи. Читаем на форумах. Ни с того, ни с сего, сервер может потеряться от 2 до 10 раз в день. Пишут что это плата за скорость… Хорошо.
    4. Далее выясняем… Не после всех потерей соединений можно восстановить связь с сервером. Нужно делать возможность полностью перегрузить Локальный сервер, переподписать все события и проч...
    Делаем поток, следящий за соединением, ничего особенного:
Обзор подключения к торгам через Api SmartCom и Quik
 
Рис.4. Пример простейшей схемы в DiagramDesigner
далее...
5.     Заявки могут испаряться при передаче их серверу вообще без обратной связи. При этом сервер может, как уже быть мёртвым в этот момент, так и в обычном состояние при смерти. Надо делать потоки Эскорты каждой заявке, которые будут следить через определённое время, что произошло, дошла ли заявка, пришёл ли какой либо отклик или нет, что с потоком, который нёс заявку.
6.    Сервер, не смотря на то, что пишет, что есть Connectможет уже умереть в это время и любое действие вызывает исключение. Включая AccessViolationException. Поэтому надо каждый вызов сервера делать левым потоком, с возможностью при перехвате исключения из любого места, или если какой-то поток перестал отвечать, уничтожать локальный сервер СмартКом и создать новый.
7.    Сервер может отваливаться по частям. В любой момент могут отсохнуть: 
Данные стакана
Тики
Данные об изменившихся заявках
Выгрузка свечей
и т.д.
    Всё это может случиться как по отдельности, так и всё сразу.
 
    В общем-то, все проблемы решаемы и каждая в отдельности не такая уж и страшная, но вот только Нахера это нужно?
Обзор подключения к торгам через Api SmartCom и Quik
 
Рис.5. Невероятно упрощённая обёртка глючного ApiSmartCom
 
    8. По ночам из SmartComиногда продолжают поступать свечи, в виде пустых интервалов! Я плакал...
    9. Тестовый доступ к SmartComотличается от реального!!! На тестовом сервере заявки периодически не проходят и отвергаются системой с объяснением: «Нельзя открывать разнонаправленные позиции с одного счёта»(ну или чёт похожее). И!!! Иногда заявка сначала отвергается системой, причём приходит подтверждение о том, что она отвергнута штатно (Systemcancel), а затем (О ЧУДО!), через какое-то время (от нескольких секунд, до нескольких минут), заявка всё же проходит. Что в купе, а особенно последнее, не даёт нормально оттестировать SmartComшлюз в своём роботе на демо счёте. И приходиться допиливать подключение уже на реальном счёте.
    10. Наличие во многих местах различных проверок сказывается на конечной скорости выставления заявок и приёма данных. Делая не возможным (либо не надёжным) реализацию скоростных стратегий через данный тип подключения.
    11. За это (SmartCom) ещё и заплатить придётся. 600 рублей в месяц.
 
    Из всех проблем описанных выше очевидно, что SmartComне очень не надёжен. Хорошая такая, бэта версия, библиотеки для подключения к бирже. Не больше. Вот торгует у меня робот, вроде всё давно оттестировано, и автоматически, и в боевых условиях, и на учебном счету и реальном… А я всё равно просыпаюсь по ночам и бегу посмотреть, как у него дела и не случилось ли новых косяков в шлюзе. Которых, по всей видимости, и сосчитать не получиться.
 
 
    Резюме:
 
    Конечно же, и первый и второй способ подключения к бирже одинаково хороши.
 
    Но с Quikтут понятно. Старичка начали делать в нулевых и серьёзных претензий к разработчикам сложно предъявлять (постебать только остаётся). Делали из того что было и так, как это было заведено в то время, через… у. Ну а что касается SmartCom, но это конечно полное разочарование. Ну как можно оставить столько багов в клиентской части, и напрочь забыть об оповещении о ошибках? БЛДЖАД!!! Ну, Вы хоть исключений в него добавьте, чтобы было понятно, что с ним происходит!
 
    Для htp торговли ни один из представленных способов подключения к торгам не подходит. Хоть SmartComи имеет хорошие показатели скорости выставления заявок (смотри ссылки ниже), то, что он несколько раз в день 100% падает и начинает глючить, для скоростных роботов может быть смертельно опасно.
   
    Что же выбрать из этих отечественныхчудо гуано платформ?
 
    Для уверенных в себе программистов SmartCom. Когда все исключительные ситуации выловлены, потоки изолированы, ордера сопровождены и любое неповиновение сервера, тут же вызывает его расстрел, а через секунду всё работает как надо, то работа со SmartComначинает приносить радость.
 
    Для тех, кто не в состоянии проконтролировать параллельную работу 20 потоков, однозначно Quik. Несмотря на свою топорность, он весьма не требователен и очень стабилен. Что на первых порах гораздо важнее скорости. Хотя тут следует джва раза подумать. В том, что SmartCom через пару версий станет стабильным, у меня сомнений нет, а вот в том, что Quikстанет быстрее и понятнее, очень большие...
 
    Ссылки:
quik.ru/сайтQuik
quik.ru/forum/ideas/7039/7039/ — один из эпичных срачей на форуме разработчиков, в котором юзеры, одурев от наглости, с 2005 года (ДЕВЯТЬ ЛЕТ!!!) пытаются безрезультатно добиться добавления Трэйлинг стопа в терминал. При этом ребята из тех поддержки, с каменным лицом, тролят умоляющих пользователей. Почитайте. В этом весь Quik...
http://www.itinvest.ru/software/smartcom/ — nuffsaid
http://smart-lab.ru/company/stocksharp/blog/105916.php — сравнение скорости выставление заявок SmartCom, Quikи Plaza II
forum.moex.com/viewtopic.asp?t=25629 — тоже, что и сверху, интересны комментарии разработчиков. Видимо на SmartCom 3 возлагались большие надежды в области безопасности соединения. Не вышло...
 

Я еще пробовал AD Api. Тоже довольно своеобразная штука.
В результате, остановился на MT5. Предельно простая, красивая штука. Все очень четко, точно, быстро и надежно.
Конечно, есть свои необычности, но сделать можно все что угодно. Если нужно соединить с внешним ПО, то к услугам DLL
(32 и 64 bit), можно через MemoryMappedFiles, можно через Named Pipes. Все очень быстро и классно. Но по факту, от внешних приблуд отказался и все стал писать на MQL, т.к. язык простой и, самое главное, объектно-ориентированный.

Минусы:
— нет акций. Только фьючи
— для очень скоростных роботов не подойдет, т.к. есть жестко прописанный лимит на 10(или 15, не помню) одновременно обрабатываемых транзакций.

В остальном сплошные плюсы. Очень надежен(сам терминал).Тем кто создал эту программу — большой респект
avatar

Redline

не в первый раз вижу как прогеры пользуют футурамную тему, откуда такая любовь?
avatar

Mr. Bean

Квик конечно не фонтан. Но смартком это

1. привязка к брокеру. К которому лично мне не хотелось бы привязываться. Т е если Вы перейдете из айти Вам придется все переписывать.

2. из Вашего поста понял что смартком глючное гуано.

Что же касается претензий к квику то:

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

«пытаются безрезультатно добиться добавления Трэйлинг стопа в терминал»

Биржа нативно не поддерживает такие заявки. Имхо они правы по обоим пунктам.

А че не ТВС по DDE и парсить, некоторые к экспорту графиков цепляются даже?
avatar

quant_trader

quant_trader,
К Quik, лично у меня, самая главная претензия в том, что его создатели не заботятся о конечных пользователях, трейдерах и алготрейдерах. Тут даже не в Трейлинг стопе дело, хотя этот частный случай сам по себе вопиющ до крови из глаз.
Они же заставляют подключаться к Quik через задний проход. «DDE + TRANS2QUIK.dll + Qple + over9000Table» или «ТВС по DDE и парсить», одинаково плохо. Как программисту мне и тебе, очевидно, что имея доступ к внутренностям Quik можно написать человеко-ориентированную библиотеку (нормальное Api) за 2 — 4 месяцев. При этом нужны два программиста, 200-500 гр. кофе и немного мотивации. Они же этого не делают уже больше 10 лет!!!
Ядро биржи вообще, как я понимаю (и это может быть не так, т.к. я с ним не знаком лично), поддерживает, только два вида заявок, КУПИТЬ и ПРОДАТЬ. Что же теперь, во всех терминалах, только это и оставить? )) Надо же о людях немного думать, а не только о брокерах.
Алексей Ван, нормальное API есть, не для всех, погуглите quikapi.dll

Что же касается ордеров то на западе брокер зачастую может сам исполнять/роутить ордера и потому на стороне брокера можно много чего сделать. В РФ же DMA. Скажем обработка трейлинг стопа который сработал в момент закрытия торгов нетривиальная задача.

Клиенты которые будут жаловаться что их рыночный стоп нарисовал многодневный лоу и исполнился хз по какой цене тоже.
TRANSAQ Connector неплохо сделан
avatar

G_20

Несколько лет написал робота на C# для квик и с тех пор горя не знаю. Надежность — главное. Работает неделями, даже не смотрю на него. А смартком с такими глюками не вариант вообще.
avatar

ivan_petrov

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

Если вы их занимаете на несколько секунд, может вам лучше не писать биржевых роботов? :)
avatar

jest_trader

jest_trader, без обид, но вы не совсем понимаете о чём идёт речь.
Алексей Ван, без обид, но в общем случае понимание тут вполне однозначное, и потоки маркетных данных блокировать мягко говоря не рекоммендуется :)
jest_trader,
Кем не рекомендуется? :) Где описано как работает и от чего падает передача потоков из SmartCom во внешние приложения? Я отвечу: Ни кем и Ни где. Ну, если только теперь в этом топике. В описании библиотеки этого нет.
В Quik, например потоки с данными идут из Quik спокойно и стоят в очереди если надо и прорисовывают график и считают производные третьего порядка и отправляют заявки синхронно. Всё работает прекрасно. Кто решил, что в SmartCom приложение должно упасть, если человек не извернулся ужом и не создал интуитивно десяток генераторов потоков-передастов? Это наверняка БАГ, который затем посчитали фичей, и я его описал, как и десяток других, чтобы люди, которые собираются к SmartCom делать свой привод, знали об этом.

Не надо делать глубоких выводов из ничего.
Алексей Ван, ну падать конечно по хорошему СмартКом не должен, но если вы подписались на данные, и потом занимаете поток их плучающий непонятно чем, то соответственно эти данные будут кешироваться или на сервере или на клиенте, и рано или поздно может произойти переполнение. Представьте себе, если сервер будет для всех криво написанных клиентов кешировать данные, а клиентов тысячи, и что тогда? По ссекрету скажу, что при сертификации той же Плазы 2 в предварительных вопросах выясняют как построено ваше приложение, не делает ли оно фигни вроде каких-то своих расчетов и отсылки приказов из потока получения маркетных данных и т.п.
jest_trader,
Про кэширование данных не знаю. Догадки. Опять же нигде это не описано.
Со всем остальным согласен. Поэтому и была написана эта статья. Для того чтобы люди не совершали ошибок.
Алексей Ван, «Поэтому и была написана эта статья. Для того чтобы люди не совершали ошибок.»

Статья скорее вредная. Опытному не нужна — для новичка не понятная и содержащая советы, которым лучше не следовать.
1) генерировать потоки на каждое отправляемое сообщение — плохой подход. Нужно либо создавать один поток с очередью, который занимается отправкой сообщений, либо при старте программы создавать пул потоков.
2) смартком 3 поддердивает асинхронный режим. Т.е. потоки для отправки сообщений можно не использовать. Тем более что C# вроде как имеет неплохие возможности для работы с асинхронной моделью.
professor facepalm,
По 1) У меня сначала один поток и занимался отправкой запросов. Да только он имеет свойство исчезать на стороне сервера и выдавать исключения при запросе. Поэтому надо чтобы этот один поток генерировал потоки смертники для запросов к SmartCom. Про пул не очень понял. При отмирании одного из потоков что предлагается делать? Весь пул убивать и создавать новый? Это вызывает множество новых вопросов.
По 2) Асинхронная модель это хорошо. Безопаснее и намного быстрее. Вот только запросы всё равно надо делать. Теми же самыми потоками.
upd: Убрал грубость.
Алексей Ван,

«Да только он имеет свойство исчезать на стороне сервера и выдавать исключения при запросе»

Исключения можно обрабатывать.

«Это на кого рассчитано? Я поржал»

Что так рассмешило?
professor facepalm,
Обрабатывать всё равно приходиться. Можно во время перехвата даже вернутся в тот же метод, чтобы начать всё заново, но это точно плохой способ. А можно просто убить поток и направить новый в проблемный метод. А можно заходить в опасные места новыми потоками и при перехвате исключения просто сворачивать стек и закрывать поток. Можно создать пул потоков и стек и очереди и вообще что угодно. Сколько пишу, всё время поражаюсь, сколько разных способов создания одного и того же существует. И сколько раз смеялся, когда один программист другому доказывает, что его способ лучше. И всё равно сам попадаюсь на это. )) Т.ч. не буду с тобой спорить. Думай, как хочешь.
И ещё плюсов тебе поставлю за интересное мнение. И в профиль даже.
Алексей Ван, я не думал, что ты потоки создаешь только потому, что стандартными средствами обрабатывать исключения не хочешь. Знал бы, про пул потоков ничего бы не написал.
Алексей Ван, вам кстати спасибо за исследование. Я со СмартКОМом 3-им не работал, но много работал с версиями с 1-й по 2.2 включительно. Так вот баги там конечно были, но в настоязщее время в версии 2.2 меня не устраивают периодические дисконнекты, которые чаще случаются при высокой торговой активности, а также порой падает сам сервис SmartCOM, что уже гораздо критичнее чем потеря связи. Других проблем у меня нет.
jest_trader, Существует проверенный механизм перезапуска упавшего второго смарткома. :-)
SergeyEgorov, ну могу предположить, что надо ловить эксепшен вроде «The RPC server is unavailable» и тогда программно перестартовать сервис СмартКОМа, так?
jest_trader, Программный рестарт сервиса смарткома не поможет ибо в роботе так и останется ссылка на дохлый COM объект. На самом деле сервис сам перезапустится, хотя нет, вру, не перезапуститься. В общем надо сначала программно отписаться от всех данных, отвязаться от всех событий, затем избавиться от ссылки на дохлого смарткома в роботе, только затем перезапустить программно сервис смарткома, и уж потом заново выполнить инициализацию экземпляра объекта StServerClass, заново связать все обработчики, подключиться и подписаться на все события… :-)
SergeyEgorov, спасибо. При дисконнекте я от всего отписываюсь и на все переподписываюсь, а вот от ссылки на дохлый смартком пока не избавляюсь, соответственно в случае падения самого сервиса у меня фатально все останавлиявается пока не перезапущу руками.
jest_trader, там еще есть тонкость в программном перезапуске дохлого сервиса смарткома. У робота должны быть права на перезапуск сервисов. У меня где-то даже есть pdf-ка с описанием как такие права давать. Ну и архитектурно получается очень интересное решение, ссылка на stServerClass ведь используется много где в роботе, получается всем, кто ее использует надо эту ссылку новую выдать после рестарта. У меня в адаптере это было реализовано через связку шаблонов Singleton и Observer. Все нормально работало кстати. Код можно посмотреть, если снять с git репозитория исходники и откатиться до момента перед коммитом, который поименован как «Replaced smartcom2 with smartcom3».
jest_trader, а вообще я считал что вторым смарткомом уже никто не торгует…
SergeyEgorov, да я просто года полтора ничего не менял — все работает, зачем что-то менять? :)
Вот сейчас может буду переделывать и тогда буду использовать третий.
Вместо DDE можно использовать простенький скрипт на Lua + библиотеку LuaFFI и на их базе организовать Named Pipe сервер, который например будет передавать стакан или свечку с графика. Вот и весь Api, который как выше писали, братья из Arqa Technologies не могут выдать уже 10 лет. Lua — это ключ и это прорыв. Спасибо им за это.
В случае named pipe не надо будет, например при экспирации фьючерса всё перенастраивать, т.к. сервер может принимать код фьючерса от клиента. DDE в этом плане плох, т.к. он делает только однонаправленный обмен.
Но это конечно если вы пишете на чём-то более серьёзном чем Excel
avatar

ПBМ

Павел Bosco М, во-во… автор топика отстал от жизни, ДДЕ — это прошлое, LUA — будущее. Все правильные пацики давно уже с ДДЕ свалили.
stocksharp.com/forum/yaf_postst5138_Novyi-konniektor-k-Quik.aspx
Смартком 3.0 пользую уже почти полтора года. Никаких каждодневных разрывов связи не наблюдаю. Они бывают, но крайне редко — отнюдь не каждый день — и почти всегда сопровождаются сообщением в терминале, при этом можно переключиться на резервный сервер. Вероятно, у автора топика проблемы с провайдером.
Потерянные заявки были осенью прошлого года, но это быстро починили. Большинство заявок улетают в рынок за 7-20мс.
На найденные баги саппорт реагирует быстро, баги действительно были на момент выпуска смартком3 в паблик, но сейчас их не осталось. Хотя, когда разработчики реализуют некоторые пожелания, то смартком3 станет еще удобнее.
Мое личное мнение — отличное, бесплатное и очень быстрое апи без ограничений по количеству транзакций.
Плата 600 рублей списывается в начале месяца, но потом возвращается за счет комиссий, то есть при оплате комиссий на сумму 600 рублей смартком3 становится бесплатен.
avatar

ignat

Мне нравится Смартком. И второй нравился, и третий нравится. В сравнении с окостыливанием (DDE, trans2quik) вкруговую Квика для организации автоматической торговли, Смартком само совершенство и предел мечтаний. На мой взгляд автор статьи посетовал лишь на то, что промышленный продукт, на звание которого претендует Смартком, должен был бы иметь промышленное же качество во всем. С другой стороны возникает сравнительный вопрос к тем, кто эксплуатировал какие-нибудь западные API, ну например Interactive Brokers. Как оно у них работает? Идеально?
avatar

SergeyEgorov

SergeyEgorov, да забудте все про ДДЕ и trans2quik. Так никто уже не робит. Квик по надежности и стабильности на голову выше Смарткома.
www.qscalp.ru/quik6
stocksharp.com/forum/yaf_postst4801_Novyi-konniektor-k-Kviku-na-LUA.aspx
Slepoy, Ну таки и что лучше работает? QScalp-овый коннектор или AmiSharp? Если я правильно понимаю и в первом и во втором случае у нас возникает скриптовая прослойка, исполняющаяся на Quik?
SergeyEgorov, Я не сравнивал эти коннекторы QScalp и AmiSharp. Но сравнивал коннектор ЛУА и ДДЕ. И вывод тут однозначный: ЛУА быстрее и удобней и менее глючней встроенного в Квик ДДЕ + API. Среда исполнения ЛУА встроенна в Квик, также как и медленный Кьюпайл. Вот топик — как писать роботов прямо в квике smart-lab.ru/blog/199387.php
Slepoy, как быстро квик забрасывает заявки в рынок? За какое количество мс приходит номер ордера и статус ордера от биржи?
avatar

ignat

ignat, медленей Смарткома — это факт. Причем в разы (((. По скорости Квик полностью обсирается )))
vimeo.com/61039475
SergeyEgorov, Я юзал апи от интерактива пару лет назад — показалось каменным веком )
Возможность использовать его сразу на с# вообще не была на тот момент документирована, как сейчас — не знаю. В интернете было немало самописных костылей для использования апи интерактива через с#, однако, как оказалось, эта связка работает и без левых костылей. Документация неполная, некоторые вещи пришлось искать методом тыка и случайных догадок — например, что пробелов в спецификации опционов должно быть не один, а два )))
Да и вообще, на мой взгляд, несмотря на более развитый мир трейдинга у буржуев, сложилось впечатление, что для частного трейдера там все гораздо хуже, чем на нашем рынке — апи примитивнейшие и далеко не у каждого брокера. Несомненно, объемы и количество инструментов на забугорье гораздо выше, чем у нас. Однако комиссии, масса правил по марже, которые отличаются у всех брокеров, не всегда прозрачное направление заявок со стороны брокера создают впечатление хаоса.
Идеального брокера с расположением в сша, удобным апи с возможностью отправки ордеров на 3-4 ноги одним ордером, с разумной комиссией и с правильными требованиями по марже пока я не нашел.
avatar

ignat

ignat, Сейчас у интерактива по меньшей мере в документации www.interactivebrokers.com/en/software/api/api.htm все красиво. Си шарп, Джава, Си плюс плюс, тьюториалы какие-то. Насколько там все адекватно объясняется не знаю, не читал сильно. Ну и насколько сам API органичен вот что хотелось бы в первом приближении понять. Десять томов документацию в наше время кто угодно может наваять, а вот чтобы ее еще можно было читать и применять не засыпая каждые три минуты, тут вот уже талант нужен.
ignat, Ну и главный вопрос про интерактив. Их API соединяется напрямую с их серверами, или опять же связка а-ля Квик, коннектимся к терминалу, и через него имеем удовольствие торговать?
SergeyEgorov, через их терминал или шлюз. В доку добавили сишарп, а на главной так и не указали )
Сам апи прост, попробуйте и сразу поймете.
avatar

ignat


Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.

Залогиниться

Зарегистрироваться
....все тэги
Регистрация
UP