English
中文
Español
Deutsch
Português
日本語
Народ, кто-нибудь уже проходил сертификацию робота на РТСе? Поделитесь опытом
Алгоритмический трейдинг для .NET и Python✦
86+ коннекторов · биржи · брокеры · крипто✦
S#.Designer · бэктест · оптимизация · live✦
Сообщество 31,451+ трейдеров и разработчиков✦
Алгоритмический трейдинг для .NET и Python✦
86+ коннекторов · биржи · брокеры · крипто✦
S#.Designer · бэктест · оптимизация · live✦
Сообщество 31,451+ трейдеров и разработчиков✦
Комментарии (162)
Вход или Создать аккаунт, Войдите или зарегистрируйтесь, чтобы оставить комментарий
Вот здесь представители РТС сами все объясняют: http://forum.rts.ru/viewtopic.asp?p=87217 Т.е. а) пройти сертификацию большого труда не составит б) секретные алгоритмы раскрывать не обязательно
Мы все пытаемся PlazaTrader засертифицировать. Все разработки на S# тогда не потребуют сертификации. Но в связи с тем, что эта сертификация не дает никакого практического преимущества, руки до этого доходят уже третий месяц.
Господа разработчики, помогите пройти сертификацию, не могу ответить на несколько вопросов (для SimpleGUI, ничего нового я не написал):
2.1 Какие потоки репликации получает система. Какие таблицы обрабатываются в каждом потоке? 2.2 Обрабатываются ли все потоки в одном объекте P2Connection или в нескольких ?. Если в нескольких, то каково деление потоков репликации по соединениям и работают ли циклы выборки сообщений для соединений в разных нитях управления (threads) операционной системы? 2.3 В каких режимах открываются потоки - COMBINED_SNAPSHOT, COMBINED_DYNAMIC, REMOTE_SNAPSHOT и т.п? При открытии потоков в режиме SNAPSHOT делается это однократно или повторяется с периодичностью и с какой? 2.4 Используется базовый или безбазовый вариант клиента репликации? В случае безбазового клиента, какова политика обработки ошибок в потоке данных - используется ли накопленная информация для запроса данных ? В случае базового клиента - какая нижележащая БД планируется к использованию?
3.1 Какие типы сообщений может отправлять система ? 3.2 Используется синхронная или асинхронная отправка ? 3.3 Используются ли дополнительные соединения (P2Connection) для отправки сообщений ?
Вы решили помочь ПлазаТрейдер засертифицировать?
Да, именно так. Так как тестовый контур для тестирования стратегий не годится, решил выйти на реальный рынок, потребовалась сертификация. Проблема в том, что я не знаю многих деталей реализации, потому обратился к вам.
Так PlazaTrader открыт для всех. Давайте его лучше вначале отрефакторим хорошенько, зайдите в соседнюю тему.
Одно другому не мешает. Сертификация - это нудный и долгий процессе переписывания по почте. Сначала я этим занимался, затем аспирант. Влад, на чем все закончилось?
Мне на вопрос как засертифицировать программу ответили:
Я так понимаю, чтобы получить сертификацию, нужно, чтобы наш коннектор прожил на полигоне более суток. И коннектор нужен "не просто живой, а чтобы бегал", т.е. выполнял весь свой функционал.
Я списывался с техподдержкой только насчет восстановления после обрыва связи, после чего занимался этим вопросом.
Читая обсуждения на форуме, я думаю, что нужно:
Меня это больше всего удивляет. Получается, что заявки можно регистрировать только одним потоком? Сейчас отправка транзакция как сделана? Есть ли какая-то синхронизация?
Транзакции делал не я, поэтому и написал, что нужно проверить, потому что не разбирался, как они сделаны.
Насчет регистрации заявок, все методы COM-объектов плазы, связанные с отправкой/получением заявок, должны вызываться внутри потока (thread), который крутит ProcessMessage для Connection'а SS_1 (подключение для отправки транзакций), т.е. получается одним потоком. Соответственно, чтобы это изменить, нужно думать о создании дополнительных Connection'ов.
Соседняя это какая?=) Про бэта тестинг?
Эта
Возвращаясь к теме сертификации (кстати, эта тема еще актуальна или все на нее подзабили?). Насколько я помню, ее дают только при условии, если робот проработает весь день (сутки). У нас с этим есть кое какие проблемы, так как isin id на вечерке изменяется, а мы на это насколько я знаю не реагируем. Поэтому, это последнее, что нужно сделать на мой взгляд для работы с Плазой в формате 24x7 и для получения сертификата.
Нет там на самом деле вроде 2 проблемы:
Первое как сказал Александр без доступа к BusinessEntities не сделать... А второе я чет так и не смог дождаться когда придет id_ord1 измененный))
Может вначале понять что сделать нужно?
Возможно))) Я не правильно понял да?(
Я пока не знаю, что и как делать. Эту задачу можно сделать совместно.
Мне вот предлагали поторговать всего часа 4-5, причем обязательно перейти через дневной клиринг (14.45-15.30 вроде), отослал логи, предложили сделать что-нибудь с очередями сообщений, больше замечаний не было.
Вот такой вопрос: Допустим я подключился к PLAZe и начал торговать каким-то своим ПО (не сертифицированным), ведь технически это возможно, что мне помешает, и во что это выльется?
Сертификация, я так понимаю, нужна сейчас тем, кого брокера не хочет подключать. Я лично не сертифицировал свой софт по причине того, что 1) не понимаю зачем оно нужно 2) жалко терять время.
)) Вывод : да нафик оно не нужно))
РТС не нужно напрягать. Лучше сделать.
Что с isin? Узнавали, когда он меняется?
Да. При смене торговой сессии...
Можно подробнее? Для каких инструментов меняется? Именно в вечерний клиринг приходит информация о новых инструментах, или она приходит посреди активной сессии?
Собственно нам нужен не сам isin а то что при смене сессии параметры инструментов меняются... Их как то надо то же заменять...
А заявки при смене isin будете подавать по старому номеру?
Александр) Ну мне казалось вы в этом вопросе более сведущ чем я даже) Не могу сказать пока что... Постараюсь разобраться...
Я думал вы на биржу позвонили да узнали. Я-то этим вопросом давно не занимался.
Как мне сказали : isin и isin id не меняются... Сейчас составлю письмо с запросом полного списка изменяемых параметров...
Так, теперь я совсем запутался. Чем отличается isin от isin_id? Если не меняется - то что происходит с инструментами РТС Стандарт в вечерний клиринг - у них ведь дата дюрации каждый день меняется, но GAZP как был газпромом, так и остаётся.
Ну пока что я только написал ответ специалиста тех. поддержки) Жду теперь письменного подтверждения...
В документации они вроде бы как разделены... По логике значит они должны быть различны))))
Ответ который мне прислали: "Вы можете сами обратить внимание, на то, по какому приницпу изменяются данные в fut_sess_contents.
Для фьючей и опционов все, кроме short_isin, isin, name, code_vcb, lot_volume, step_price, d_exp.
Для стандарта всё тоже самое, за исключением того, что инструменты станадрта могут жить всего 5 дней. При появлении нового инструмента ему присваивается новый isin_id. При изменении торговой сессии в инструментах Стандарта "сдвгиаются" isin_id, по принципу, обрисованому на скриншоте. "
Получается, что isin_id то как раз меняется. И это для всех инструментов справедливо, так?
Скриншота не увидел. можете переслать письмо на AMukhanchikov <собака> stocksharp.com?
Отправил...
Как я понял из кода инструмент обновляется по его short_isin:
А он не зависит от сессии. Так почему же параметры инструмента не обновляются при смене сессии?
Я думал как раз вы нам это и расскажите :) Ни я, ни Михаил этим вопросом не занимаемся сейчас.
НУ по письменному ответу да) По устному нет))) Ну я больше доверяю письменному...
Итого, что нам нужно сделать тогда? Еще раз чтобы было понятно. Только в вечерний клиринг isin_id обновляется? Обновляется по всем ФОРТС инструментам?
А разве в дневной клиринг сессия меняется? :|
Нууу))) Не уверен)) Но могу сказать что после дневного клиринга приходиться перезагружать прогу т.к. данные по инструменту изменяются...
А в чём есть уверенность? А то вы пишите догадки, на основе которых хотите что-то править.
Как я себе представляю:
В вечерний клиринг сессия1 становится неактивной, сессия2 - активной.
P.S. Протестил сегодня специально на дневном клиринге - всё в порядке, перегружать ничего не приходится.
Александр я конечно не знаю что именно вы имели ввиду под фразой "всё в порядке", но я так же сегодня провел тест и по крайней мере минимально возможная цена фьючерса(в моем случае RIZ1) после клиринга не обновилась! В итого при попытке выставить заявку по рынку биржа отвергла ее.
Она всегда равна 5.
Речь о нижнем лимите я так понял
Странно... Может конечно что то было изменено в библиотеке со временем, но у меня совершенно точно данные не обновлялись после дневного клиринга... Я признаться был абсолютно уверен что в этом направлении ничего не изменяли... Т.е у вас Александр после дневного клиринга информация по инструменту нормально обновляется?
Если речь идет про ласты, то да, они обновляются.
Займётесь тогда? Для этого доступа кроме как к плазе не нужно
Ну я называю это так как это в Quik называется... Тут даже не важно что именно изменяется, а сам факт наличия изменений на которые плаза не реагирует пока что ни как))
Просто я не знаю плазу как вы... До этого вы писали:
Но я готов попробовать) Мне это оч нужно)
В клиринг isin_id не меняется. Так что фикс апдейта и фикс с isin_id - это 2 разных фикса.
У аа.... Жесть. Александр. Понял. Вроде. Может задачи то же тогда подправите по Плазе...Ну так сказать для порядку))
Так. Причину почему не обновляется инструмент нашел. Попытаюсь исправить...
Какая? Хочу понять совпадает ли она с моей причиной или нет :)
В методе OnSessionContentsDerivativeStreamInserted есть условие if (_isinIds.Add(isinId)). Оно выдает false в клиринг, т.к. приходят инструменты с isinId старым, но информацией уже новой...
В связи с этим хотел бы поинтересоваться о методе BaseTrader.GetSecurity. Анонимному методу changeSecurety передается новый инструмент, если инструмента с таким id еще нет? Тогда что передается в createSecurety ? Я просто не могу посмотреть логику этого метода...
Предлагаю вообще не использовать методы BaseTrader для этого. Не заточен он под это. Может сделать свой маппинг для Плазы?
Михаил, а что вы имели ввиду?
А понял... Т.е в createSecurety передается Id, а в changeSecurety Security созданный в createSecurety. Так зачем же тогда тут нужно if (_isinIds.Add(isinId))?!?))
Добавлял я. Для уникальности инструмента. Так как isinId - не уникален. Уникальная связка - ininId + sessionId. Только вот сейчас я думаю что неправильное такое решение.
Ну тогда надо проверять isinId + sessionId как вы и написали. Причем брать только те инструменты которые соответ текущему sessionId сессии...
А что будет при смене SessionId, но сохранении isinId?
Как мне сказали в службе поддержки isinId так же меняется. Т.е если меняется SessionId инструмента , то и isinId у него меняется. Причем новая инф по инструментам как в основной так и в промежуточный клиринг приходит либо во время клиринга либо после, но не раньше точно...
Тогда я не понял высказывания
Тогда я не понял высказывания
Ну я решаю проблему с неосновным клирингом, а там isinId - не меняется, из за чего if (_isinIds.Add(isinId)) - не "пропускает" новую инф. по инструментам.
Я говорю в неосновной клиринг все просто, там надо ток _isinIds.Add(isinId) убрать и все данные обновятся. А вот как их обновить в основной клиринг ...
Т.е. в принципе в промежуточный клиринг надо только обновить инф по инструменту, а в основной надо найти старый инструмент(по какому параметру пока не знаю) и обновить у него все в том числе и isinId...
Александр на этот раз я уверен в этом))
Короче я решу данную проблему думаю)) Вот только про "маппинг" Михаил расскажет еще)
Mapping - это отображение. В случае с Плазой - взаимо однозначное.
Нет. Это я понимаю. Как это исп для плазы))
С маппингом все понял... А вот скажите : Метод GetSecurity разве не по Id (CreateSecurityId(secCode, "RTS")) находит инструмент?
да, по CreateSecurityId(secCode, "RTS") но есть такое понятие как id_торговой_системы это как раз то, что используется в качестве id инструмента в торговой системе.
в случае плазы - это isin_id.
Ну да. Я понимаю. Я это виду к тому что в основной клиринг когда у инструмента смениться isin_id он так же будет обновлен, т.к. поиск инструмента для обновления идет по CreateSecurityId(secCode, "RTS"). Вот...
isin_id не будет обновлён. более того - уже говорилось, что isin_id может остаться прежним, а session_id смениться.
http://stocksharp.com/posts/m/14734/
Т.е как я понимаю в данный момент isin_id в методе GetSecurity не используется вообще... Все понял...
Конечно нет. Это чисто плазовская вещь. Сейчас isin-id маппится на nativeId, что передается в GetSecurity. Но nativeId есть не всех коннекторов (у Квика например нет), и nativeId предполагает константность, а в плазе он меняется. Следовательно или переделывать BaseSecurity или вообще не использовать параметр nativeId и сделать маппинг прямо внутри PlazaTrader. Если появится еще какой-то коннектор, который будет так же менять значения своих идентификаторов в течении торгов, то тогда имеет смысл его занести в BaseTrader. А пока пускай он будет там, где он нужен только сейчас.
Все понятно... Ну вот как раз _isinIds переделать в SynchronizedDictionary какой нить.. НУ как вы и предлагали собственно...
Еще раз говорю "как мне последний раз сказали в поддержке")) например ShortIsin не меняется, можно его в качестве ключа использовать...
А это поле есть в стаканах, в сделках, заявках? Ключ должен быть не только уникальным и неизменным, но еще и присутствовать везде.
Нет просто вопрос касался инструментов только) Проблема же с ними)
Нет проблем. Есть задачи. Задача - чтобы обновлялись данные по инструменту. Как стаканные, так и ласты. Все данные, вообщем.
Хммм... Нет Михаил просто до этого мы разговаривали об инструментах только... Разве все остальное обновляется с ошибкой? Я прост не в курсе был...
Все остальное просто перестает обновляться. Это ошибка?
Ну... Да) Ошибка))) Нет ну в принципе понятно, вы смотрите на плазу так сказать всеобъемлющем взглядом...
мы смотрим на плазу взглядом чтобы работало. а не "сделать что-то не знаем что, но всё равно чтоб не работало"
Александр это в мой огород камень? Я вот например понятия не имею что и как у вас там в BaseTrader. И тем более почему стаканы, заявки и т.д. ставятся в соответствие с инструментом по isin_id. Просто ссылкой на объект Security это сделать нельзя было?
Не в ваш. Цель того чтоб это починить - не чтобы закрыть таск. А чтоб действительно работало как нужно.
На биржу вы что передаёте? Security? Везде - в стаканах, сделках, заявках используется isin_id. Именно поэтому и нужен маппинг в PlazaTrader. Биржа о Stock# и Security знать не знает. Ей важен лишь номер инструмента, что вы передали. Именно по нему идёт сделка на бирже.
Я окончательно запутан...
Так. Давайте в очередной раз попробую объяснить.
Внутри S# мы работаем с понятием Security - оно используется при регистрации заявки (RegisterOrder), оно используется в стакане (MarketDepth). Везде где вы в S# работаете с инструментом - вы работаете с Security.
Биржа о Security ничего не знает, она знает лишь о isin_id и sess_id. Именно поэтому для того чтобы подавать заявки на биржу, идентифицировать инструменты в заявках, пришедших с биржи, строить стаканы по инструменту, прешедшему с биржи, нам надо взаимно однозначно сопоставлять isin_id и sess_id с Security.
Для этого и должен быть сделан простейший маппинг.
Ну да. Это я понимаю. Ну т.к. у нас в Stock# есть Security - класс общий для всех торговых систем, на него и надо ссылаться. А при отправки запросов бирже использовать те поля этого класса которые нужны биржи. В случае плазы можно наследоваться от BaseSecurity и расширить этот класс isin_id и еще если тем что нужно. А можно сделать маппинг и исп в качестве колюча объект Security а в качестве значения тот же isin_id ... Но в любом случае ссылаться везде на Security.
Это мой взгляд на устройства такой системы. Если вы его считаете неверным, то просто ваше видение расскажите... Это нормальная практика проектирования: сначала обсудить и подумать, а лишь потом кодить...
Мы вроде это обсуждаем и мусолим уже 2 месяца.
У нас есть класс Security, при работе со стаканами и т.д. и т.п. мы на него и ссылаемся. Что такое BaseSecurity я не знаю, в Security добавлять новое поле смысла нет, т.к. его никто кроме плазы использовать не будет.
Поэтому и предлагается сделать маппинг внутри PlazaTrader.
P.S. Михаил как раз об этом вчера и писал
BaseSecurity - это базовый класс всех инструментов. О нем Михаил упоминал ранее. От него можно наследоваться и создать например PlazaSecurity. Просто маппинг как то не очень похож на решение из ООП... А если необходимо будет добавить еще какое нибудь поле которого нет в BaseSecurity? Еще одно соответствие лепить?((
Базовый класс - Security, другого класса инструментов нет (ну кроме BasketSecurity).
Например, какое поле вам может ещё потребоваться для реализации шлюза Плаза2? Лепить для каждого шлюза свой инструмент - как раз не самый лучший вариант, ибо надо будет везде приводить, проверять на тип. А это скорость.
Зачем такое городить, если решение с маппингом - вполне очевидное и быстро работающее? К тому же реализация занимает малое время.
Например поле ShortIsin. Т.к. оно не меняется при смене сессий. Именно по нему можно обновлять инструмент. Т.е. получаеться у нас есть уже 2 поля которые есть только у плазы isin_id и ShortIsin
ShortIsin используется где-то при подаче заявок и т.д. и т.п.? Это просто secCode, который мы проставляем в Security.Code
Ещё попытка? :)