Что вы используете для написания роботов?
Quik API (свой DDE сервер, Transaq2Quik)
другое (Alor COM, TS Lab, Micex Gate, ...)
Всего проголосовало: 326
Подниму вопрос, который многим интересен - какое API вы используете для написания роботов?
В комментариях просьба написать почему и планируете ли менять API в дальнейшем. Если планируете - что мешает вам поменять прямо сейчас.
P.S. Вариант StockSharp - использование S# для любого реализованного в нём API (Quik api, smartcom, alfa direct, alor, transaq, plaza2).
Насколько сложно сделать там получение и архивацию сделок по всем торгуемым инструментам? Т е не настраиваемый список получаемых а все что торгуется аналогично файлам на фтп ртс.
Можно ли накапливать бидаски т е снепшоты к примеру таблицы котировок?
Про стаканы в документации написано, а вот что касается накопления таблицы котировок как? Поясню вот есть например опционная борда, хотелось бы иметь секундную историю бидасков. Теоретически из квика можно вытащить историю изменений но это уже совсем нереально круто, пусть хотя бы снепшоты.
Хочу добавить возвращаясь к дискуссии на пауке про датафид признаю Вашу правоту по необходимости работать с ТВС.
Бидаски конечно хорошо бы лить через стаканы но Квик не потянет мне кажется открытые стаканы по всем инструментам.
Спасибо за ответ.
Stock#
Wealth-Lab :)
transaq нравится больше но это все субъективно они оба хороши но Transaq лучше :)
см. профиль
Я собственно почему предложил видео-презентации сделать, потому что это будет более наглядно.
С учетом того, что C# разрабатывает команда из 40 человек, а Qpile поддерживают (даже не разрабатывают, а только лишь поддерживают) 0.5 сотрудника Арки, с вашим утверждением сложно согласиться. Тем более, что Квик сам по себе не является надежной платформой для роботов, о чем сами же создатели заявляли не раз. У вас видимо Квик не падал в течении торговой сессии ни разу.
почему не StockSharp? потому как код закрытый, ну и реализация на делфи для меня попроще, чем на C#
Если интересно, конечно. :)
исходников не будет?:)
да, чисто из любопытства — как интерпретатор реализован?
Правда его пришлось напильником дорабатывать. :)
По исходникам. Вопрос есть ли смысл?
Если совместную разработку делать, то можно и открыть исходники.
потому как совсем не програмёр и рынок ПОКА не основной доход, основная моя проблема — вера в робота и невмешательство в его работу…
О СтокШарпе знаю. Но проблематично перескочить со своих разработок на чьи-то.
Хотя, конечно, в СтокШарпе привлекает то, что библиотека поддерживается многими пользователями/разработчиками…
О том же Сток-Шарпе, например, я узнал ещё года 2 назад. Когда была только версия под Квик.
планирую использовать StockSharp
2008 — Eva
2009 — Dettier
2010 — robot_Panda
2011 — robot_PRADA
Т.к. СмартКОМ безбожно тормозил в те годы.
Использую c# и API к торговой платформе OEC Trader (брокер Open E Cry). Вот здесь лежит дока к этому АПИ:
openecry.ru/index.php/forum/5-torgovyj-terminal-openecry/117-dokumentatsiya-na-api-dostupa-k-funktsiya-terminala-oec-trader
Можем голосом пообщаться?
Я просто не понял сути понятия «поток» в данном контексте, который упоминал Spekyl.
Можно и с одним потоком событийную модель построить.
Я так понял, что Велс и Квик останавливают исполнение алгоритма робота на время, например, отправки заявки в шлюз?
riDepth.Changed += () =>
{
// логика реагирования на изменение стакана
// срабатывает точь в точь, когда он меняется,
// а не когда заканчивается интервал
};
Событийная модель делает это читабельнее:
this
.When(Depth.BestBidMore(upLimit))
.Do(/* обрабатываем конкретное правило повышения бида */);
Т.е. типа использование анонимных методов? Кажется это так называется.
Не буду больше мучать. :)))
потоки это зло если пользовать их неумеючи
если даже либа квика подразумевает мультипоточные коллбаки — я бы все равно все сводил в один тред — и никакой синхронизации и гемора — 50к небольших событий можно в секунду обрабатывать в одном треде — думаю столько ртс не снилось
правда не знаю спецификации взаимодействия сторонних с c#
но для того чтобы сказать что тредовая модель в стокшарпе убогая мне инфы достаточно
Хотя я в своём SAT тоже отказался от идеи использования потоков. Но там проблема другая — старые VCL-контролы не поддерживают одновременных обращений из разных потоков.
Поэтому, кстати, меня тоже заинтересовал S#. Хотя для позиционных роботов по фигу, что в одном потоке обработка идёт, что в разных. :)
LMAX — London MultilAteral Exchange. У них свой API, я использую .NET.
К трёхмерной графике отношения не имеет :)
если уж так хотите использовать пул потоков тогда должна быть четко документированная модель а не просто синхронайз везде — это хорошая база для дедлоков
хорошая практика в таких программах привязывать тред не к типу событий а привязывать инструмент к потоку — те вся маркет дата и все ордера для конкретного инструмента проходят в одном потоке
в доках нет правил копирования доменных объектов — надо все определять эмпирически — что копируется что модифицируется и синхронизованно и доступно между различными потоками неясно
вот например класс Security это по сути своей доменный объект но в нем присутствуют методы доступа к стакану которые в данной тредовой модели не могут не быть синхронизованны — те по сути это типа сервиса получается — но сервиса однобокого в плане что событий об изменения книги нет в этом сервисе — только получение стакана а события надо получать из другого источника, и вообще зачем тогда классу паблик конструктор если он должен быть гдето правильно инициализированн
такую багу даже недавно видел на форуме что номер транзакции не был инициализированн в событии трейда — если логика робота основывается на этом он просто его пропустит — это типичный кросскондишн
короче если покопаться то наверное еще куча всего найдется — нет ни времени не желания
в любом случае удачи — дело все равно полезное