English
Русский
Español
Deutsch
Português
日本語
Всем добрый день!
Время от времени на форуме появляются вопросы о поддержке библиотекой разных площадок (например, ММВБ через mtesrl), либо вопросы связанные с работой коннекторов, которые сейчас никто не поддерживает (Транзак и Алор), так же часто возникают темы о различных проблемах с наиболее используемыми коннекторами (Quik, SmartCOM). Получается так, что "мыши плакали, кололись, но продолжали грызть кактус"😀
Михаил уже предлагал заказать новые фишки у сторонних разработчиков, но та тема перешла в разработку коннектора для зарубежных площадок, и в результате, коннектор для OEC был написан. В связи с чем хочется провести небольшой опрос пользователей библиотеки:
- интересует ли вас дальнейшее развитие следующих коннекторов: Транзак, Алор, ММВБ через mtesrl, Плаза для УБ или каких-либо других?
- готовы ли вы принять финансовое участие в разработке данных коннекторов?
评论 (51)
登录 或 创建账户, 登录或注册以发表评论
Может сначала дождаться 5 апреля?
А что будет 5-го апреля?
тоже заинтригован 😀
Я так понял речь о форуме ММВБ-РТС, на котором расскажут о подробностях будущего плазы, майсекс бридж, плазы под линукс и т.д. и т.п.
В общем услышим всё на форуме :) Но к теме это имеет мало отношения.
http://forum2012.rts.micex.ru/s416
Показетельный резонанс на тему за последние 9 дней :)
я хотел увидеть хотя бы 1-2 ответа на поставленные вопросы - кому развитие каких коннекторов интересно и кому интересно продолжение практики покупки новых коннекторов у фрилансеров.
по поводу гавно коннекторов - надеюсь, это камень не в наш огород был.
коннектор к Алору интересен, но, учитывая, что у Алора есть квик, вместо потратить деньги на разработку коннектора к Алору, проще использовать квик и заплатить за поддержку на форуме, например.
На первый взгляд выглядит вполне логичное заключение. Но:
Так что не все так однозначно.
Квик у Алора стоит 200р в месяц - далеко не значительная сумма. Михаил, а есть ли способ до того, как объявлять сбор средств на коннектор к Алору, оценить какой из терминалов более глючен - Квик или Алортрейд? Например, в Алортрейде невозможно получать в робота котировки только по выбранным инструментам - возможность фильтрации отсутствует и поэтому во входящие события заходят котировки всех инструментов, приходится из них выбирать нужные. Это не повлияет на скорость работы коннектора?
Давайте сразу определимся. Тему создал Эспер. Поэтому все вопросы технические к нему.
По своему опыту могу сказать, что терминал Квика самый стабильный. Он может не такой удобный и функциональный, но то, что он умеет, он делает четко. Его минус, вернее минус компании-разработчика, это полное нежелание идти в сторону алго трейдинга.
Или удобный терминал, или надежный доступ для робота. Пока нет такого ПО, который бы совмещал и то и другое.
На мой взгляд, Алортрейд гораздо удобнее и понятнее квика. Если же коннектор к Алортрейду обеспечит быструю и безглючную работу, да еще и цена его будет сопоставима с месячной поддержкой на форуме, то запишите меня в число этих 20 заказчиков.
У Алора есть новая технология. Атенсис. Она не к терминалу подключается, а сразу к серверу. Это интереснее для робота.
Соглашение с Алором не предполагает разглашение о данной технологии на текущий момент ) Но эта библиотека очень похожа на API Алортрейд и переделать готовый коннектор от Алортрейда под новую технологию когда ее выпустят для всех, думаю, будут несложно. Кроме того, при использовании Алортрейда он сам коннектиться к слоту и уже к нему можно подключить сколько угодно скриптов. А при использовании новой технологии робот сам непосредственно цепляется на слот и подключение второго робота невозможно, поэтому необходимо будет либо делать упрощенный аналог терминала к которому и цепляться, либо использовать только одного робота. Либо продолжать использовать Алортрейд. Так что коннектор для Алортрейда интересен в любом случае.
Может тогда возьмётесь доделать его?
Могу попробовать, если объясните конкретику. Но я не считаю себя специалистом в программировании на сишарпе.
на stocksharp.codeplex.com в сорсах папке dev есть папка Alor там как раз текущий коннектор. Необходимо скачать, исправить чтоб компилировался, допилить те функции, которые не реализованы и протестировать.
Не знаю ничего про алор атенсис, помимо факта его существования, но про алор трейд могу сказать следующие вещи.
Он работает хорошо(относительно быстро и стабильно), как датафид. Но вот в плане отправки заявок он просто ужасен. В нем нет возможности отправить две заявки асинхронно, два вызова местного RegisterOrder даже из разных потоков будут осуществляться последовательно, причем вторая транзакция будет отправлена только после того как от биржи будет получен ответ на первую. Помню, как мне на их форуме рассказывали, что это наоборот круто, что так проще программировать и вообще это такая классная фича 😀 Короче для оперативной торговли Алорт трейд вообще не вариант, жалко что об этом узнал только на практике, когда уже написал на 95% его поддержку 🤬
Но правда как альтернативный датафид для сбора стаканов работает и по сей день..
Если коротко, то я не рекомендую его вообще кому-то использовать, и не вижу смысла в создании коннектора для него :)
Могу сказать в защиту Алор-трейда несколько слов. Да, асинхронной отправки заявок нет, но отклик от сервера о принятии (или не принятии) на отправленную заявку приходит достаточно быстро для того, чтобы в одну секунду можно было отправить несколько заявок - ограничением служит лишь пинг до сервера. Для обычного неплазменного коннекта это хороший результат, сравнивая с некоторыми другими брокерами. Плюс к этому, на одном счете фъючерсы и опционы цепляются на разные слоты и имеют по два сервера - основной и резервный, соответственно, можно одномоментно отправить четыре асинхронных заявки по две на фъючерсы и опционы. Одновременное подключение четырех слотов в терминале, как и их обработка в роботе, никаких проблем не вызывает. И, не сочтите за рекламу, но качество работы техподдержки и брокера очень даже устраивает и, на мой субъективный взгляд, я рекомендую его использовать. Поэтому, учитывая вышеописанные заморочки с Квиком, коннектор к Алор-трейду точно нужен и я готов участвовать в его коллективной оплате.
Из всех (скажем так - слегка кривоватых) коннекторов самый прямой - это коннектор к плазе. Почему бы его не доработать, снабдив галочками -отправлять все заявки через Квик. -отправлять заявки на ММВБ через Квик а на Фортс через плазу.
Минусы - платность, но небольшая. 1000р/мес за просмотровый логин плазы через сервер брокера. (до января 2013 за трансляцию ММВБ денег обещали не брать). Главный плюс - нет кошмара DDE, настройки таблиц и т.п. И не не надо тянуть в Квик ТВС - основной тормоз. Quik - для многих привычный терминал. Во время работы автомата его можно использовать для контроля. Привычные графики и таблицы. Своих городить не надо. В любой момент снял соответствующую галочку в Квике и счет на ручном управлении. Доплачиваешь еще тыщу за основной логин и плавный переход на прямой доступ к FORTS.
PS. Пост чисто теоретический, поскольку сам интересуюсь только forts и лишней тыщи за основной логин принципиально не жалко.
Неожиданный поворот в предложении.😀
Ничего неожиданного. 95% российских трейдеров уже и так отправляют заявки через Квик. Т.е. хуже не будет. API у Квика вполне вменяемое. Поэтому если получится опять кривоватый коннектор, пенять можно будет только на себя. 😀. Разумеется, это компромиссное решение, но вполне универсальное. Кроме того, четкое разделение адаптера на датафид и брокерскую часть м.б. очень полезно в других случаях.
Так я как раз об этом. Надо совершенствовать популярный и востребованный коннектор, а не почивать на лаврах и не плодить коннекторы к маргинальным API. Можно и по другому сформулировать - заменить в коннекторе Квик неуклюжий DDE на датафид от плазы.
Не совсем понял по первому пункту в чей огород камень - кто почивает на лаврах и плодит коннекторы к маргинальным API.
По второму - заменив DDE на датафид от плазы мы получим PlazaTrader.
Еще раз:
Если вся полемика сводится к тому, чтобы данные получать через Плазу, а отправлять заявки через Квик, то это и так возможно сейчас. Не востребовано, потому что это сущее извращение. Разделение датафида и транзакционного интерфейса сделано вовсе не потому, что так надо, а потому, что по другому в некоторых случаях нельзя. Так что не путайте причину и следствия.
А может наоборот - не востребовано, потому что сейчас - это сущее извращение?
PS. Прочитал веточку на пауке про адаптер Quik-OQ от SGN. Вот где извращение-то (с DDE).
Нет, именно разделение датафида от транзакций - это извращение. Сделали буржуи, потому что у них бизнес разделен. Технологически - это самый что ни на есть обычный косяк в архитектуре. Практически сразу же добавляется геморрой с синхронизацией состояния заявок, получения своих позиций, сделок... Вообще сущий ад с рас синхронизацией данных, и меток времени. И которые решаются уплатой лишних пару тысяч в месяц, чтобы доапгрейдить readonly логин до нормального. Из-за пары то тысяч себе такие приключение? Увольте.
Если кратко:
Рассинхронизация возникает тогда, когда руководствуясь благими намерениями пытаются синхронизировать анонимные и неанонимные данные. Если не получается - просто не надо этого делать.
И еще раз - апгрейд readonly до основного за пару тысяч не дает ничего (совсем ничего) человеку торгующему акциями на ММВБ. А отдельное прямое подключение к ММВБ - это еще сверху, и не пара тысяч.
Смысла нет сейчас переделывать или делать новый коннектор для поддержания ММВБ секции, так как обработка ММВБ заявок через Плазу - это вопрос лишь времени. Быстрее биржа сделает со своей стороны решение, чем появится первая стабильная версия подобного коннектора.
И в свете этой дискуссии коннектор к Алор кажется очень даже действующим, так как все описанные выше проблемы он УЖЕ решает.😀
У Алора я так понял минус - это скорость. Скорость была оценена относительно COM коннектора. Новое решение, насколько я знаю, это чисто .NET и подключение напрямую к серверу, а не к терминалу. Так что возможно все описанное выше про него теперь уже не актуально. Я послал ссылку на дискуссию тех диру Алора. Попрощу, чтобы они прояснили ситуацию.
Ignat, неправильно. Там ограничение не пинг до сервера, а пинг до сервера + ответ от биржи. А при большой загруженности биржи это может быть до секунды. Насколько я помню было так. А использовать кучу слотов и какие-то танцы с бубном(если честно мне казалось, что с одного логина нельзя открыть несколько слотов, да и не факт, что они тогда отправятся асинхронно, я уже плохо помню) - это редкое извращение. И вообще зачем нужен Алор? Тарифы не лучшие, а терминал тормозной по части работы с заявками.
Mikhail Sukhov, 😂
Justtrader, при большой загруженности биржи на форуме биржи и на плазу грешат секундными роундтрипами. А при обычной торговле Алор-трейд пошустрее терминалов некоторых брокеров - сугубо из личного опыта и замеров мс. Но замерял не со всеми брокерами, поэтому не претендую на объективность. Да и извращения нет никакого - апи простое, закинуть заявки в разных потоках асинхронно на разные слоты - не самый продвинутый уровень программирования.
Простой пример. Есть разница когда отправляешь две заявки подряд и они обе исполняются через секунду (вариант с плазой и перегруженностью биржи) и когда отправляешь одну заявку ждешь секунду и отправляешь вторую(вариант с алором и перегруженностью биржи). В итоге одна исполняется через секунду, вторая через две 😀
Ладно, мне все равно по большому счету, не буду больше ничего писать на эту тему.
Не дождавшись комментариев, нарушу тишину в ветке. Специально последние дни мониторил скорость отклика серверов Алора. Пинг у меня до сервера 58мс, отклик от сервера (который размораживает поток и позволяет ставить следующую заявку) после отправки заявки в большинстве случаев приходит через в среднем 100мс. Изредка бывает в диапазоне 150-300мс. Крайне редко бывает выше 300мс.
Вау, крутые результаты. Лучше чем квик, лучше чем смарт. Мы как раз заканчиваем допиливать шлюз к Alor, будем тестить.
Справедливости ради - это время отклика сервера для продолжения работы потока в аргументацию отсутствия асинхронности, однако из таблицы ордеров заявка приходит событием несколько позднее - через 400-800мс. Но время ожидания появления заявки в таблице ордеров уже ни коем образом не влияет на работоспособность потока. Я бы поучаствовал в тестах шлюза к Алору.
Подключаться к серверу на прямую по любому быстрее, чем через QUIK, а самое главное - надёжнее. В основе Алора, на сколько мне известно, одна из старых версий NetInvestor Я сам использую NetInvestor и очень доволен. А для проекта S# ещё важно, что NetInvestor поддерживают больше сорока брокеров, среди которых несколько крупных и известных (кроме того, есть даже несколько брокеров в Казахстане) Еслиб был коннектор S# к NetInvestor, было бы очень хорошо.
Сколько Вы готовы заплатить за коннектор для NetInvestor (можно в личку)?
Спасибо за информацию.
А чем это лучше Плазы или Квика. Первое поддерживают независимо от брокера, главное чтобы он был профучастником. Второе имеет внедрения куда больше и шире.
Чем на ваш взгляд коннектор для НетИнвестора будет полезен для S#? Какие даст преимущества, которые сейчас отсутствуют?
Я тоже посмотрел список - у кого есть NetInvestor присутствует и Quik.
Для брокеров с уникальным API коннекторов понашлёпали, понятно, что это не плохие брокеры, но всёж... А более распространённая система осталась без внимания.
Ну и пусть Квик присутствует... Главная мысль, что напрямую к серверу надёжнее и быстрее, чем когда посередине ещё терминал болтается. И если брокеры готовы у себя держать две системы, то это не просто так, значит не всех Квик устраивает.
Если взять ТОП 10 брокеров, то у них есть НетИнвестор?
Почему сразу заплатить?.. Я рассчитываю на то, что владельцы проекта сами увидят свой интерес и реализуют такой коннектор.
P.S.: Ветка называется "Разработка и поддержка новых коннекторов" и нас спрашивают о том, какие вообще коннекторы нужны пользователям библиотеки.
В кратце преимущества:
с технической точки зрения
с коммерческой точки зрения
МФД специализируется на банковском софте, поэтому в их списке много банков.
По моим ощущениям NetInvestor по распространённости второй после QUIK терминал в России. Честно говоря, думал, что работы по внедрению NIAPI в S# уже давно ведутся.
Даже нет в планах.