Русский
中文
Español
Deutsch
Português
日本語
Народ, кто-нибудь уже проходил сертификацию робота на РТСе? Поделитесь опытом
Algorithmic trading for .NET and Python✦
86+ connectors · exchanges · brokers · crypto✦
S#.Designer · backtest · optimize · go live✦
A community of 31,455+ traders & developers✦
Algorithmic trading for .NET and Python✦
86+ connectors · exchanges · brokers · crypto✦
S#.Designer · backtest · optimize · go live✦
A community of 31,455+ traders & developers✦
Comments (162)
Login or Create account, Log in or register to leave a comment
Вот здесь представители РТС сами все объясняют: 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
Ещё попытка? :)
Блин... Ну я вот не понимаю почему решение с маппингоп проще просто)) Но ваше с Михаилом мнение для меня авторитетно))) Так что...
Предлагаю перечитать это сообщение и все предыдущие. Сесть и спокойно обдумать в тихой обстановке. Взять паузу, прежде чем писать новый ответ на форуме. :)
Зачем сопоставлять sin_id и sess_id если можно исп ShortIsin. Он однозначно указывает на инструмент...
Да потому что на бирже используется не ShortIsin в пришедшей информации. А именно isin_id!
Вам пришли сделки, там isin_id есть, ShortIsin - нет. Как вы будете понимать кому принадлежат эти сделки, какому инструменту?
Я по isin_id найду инструмент. А когда смениться сессия я для поиска инструмента буду исп ShortIsin ))) Всего 2 параметра.
Ещё раз всё перечитайте и обдумайте. Не сможете вы найти по ShortIsin инструмент, т.к. в приходящей информации его нет.
Александр мне кажется мы не понимаем друг друга. Вы вот так восприняли мое сообщение:
Уже говорили, что isin_id в инструменте не хранится. в BaseTrader и Security вносить изменения не будем, т.к. это сейчас будет использоваться только в PlazaTrader
Ну это уже другой вопрос как хранить isin_id и ShortIsin. Мы уже это обсудили. Маппинг так маппинг...
Мне это сделать? Или вы сами?
Вы вроде уже взялись за это, так что доделывайте. Там по идее работы не много, на пару дней с тестами...
Зря что ли мы размусоливали как, что, где и почему делать? :)
Ну да. Согласен. Немного...
У меня вопрос. Но он связан с тем что я не могу посмотреть код GetSecurity... Если в GetSecurity передать новый isinId, то он замениться внутри BaseTrader. По идее если он будет меняться то вообще ничего делать не надо...))
Нет.
Жаль)
Тогда мне нужен доступ к BaseTrader.
Зачем? Маппинг делается внутри PlazaTrader, мы сегодня это всё утро с вами тут обсуждали.
Нет isinId в любом случае надо менять в BaseTrader, т.к. по нему внутри BaseTrader инструмент находиться... Там даже никаких маппингов не надо если обновлять isinId внутри BaseTrader))
Вот только проблема есть одна. Нет в BaseTrader isin.
Ну вот сами время тяните... Дали бы доступ я б сегодня вечером уже тестил...
"Сейчас isin-id маппится на nativeId" - значит его можно изменить...
Включаете робота вечером, вам приходят сделки за дневную сессию по инструменту A, который имеет isin_id1, и за вечернюю сессию по инструменту A, который имеет isin_id2. Как матчить будете если на nativeId уже смэппен isin_id2?
Стоп. А как же сейчас? При таком варианте который вы описали и сейчас одновременно сделки за дневную и вечернюю сессию нельзя принимать, т.к. необходимо иметь как 2 инструмента по факту с разными isin_id, но по сути одинаковых...
Бинго! Теперь вы поняли, почему это актуальная проблема и её надо исправлять. Вы думали мы это для красоты хотим? :)
Ну вообще то в задаче вы указали слово : "Отфильтровать" , т.е в вечернюю сессию нам не нужны сделки за дневную сессию...
Обновление isin_id как раз создаст такой фильтр))
Тому посту 2 месяца. Мы неоднократно писали в чём конкретно проблема и что дело совсем не в фильтрации.
Александр. Ну могу сказать что я был уверен в том что вечером сделки норм приходят, а проблема только при смене сессий... Тогда думать надо... Необходимо что бы инструмент был по прежнему один... но isin_id было 2 у него... Может маппинг?)))
Так... Ладненько... Простого пути не будет... Делаю...
А не могли бы вы все таки скинуть код метода GetSecurity мне в сообщении... Ну что бы я спокоен был)))
Спокойны относительно чего? Что мы вас не обманываем по поводу структуры GetSecurity и не хотим вынудить вас делать то, что никому нафиг не нужно?
Ну Александр!)) Конечно нет. Просто хочу сам увидеть структуру... Ну что там супер секретная разработка что ли?
Да сделал я уже все)) Ладно понял...
Кидайте в shelve, мы посмотрим
)) Не тестил еще... Хотя если вы затестите будет хорошо... А то у меня нет возможности седня(
У меня ник frontman_cp
Лучше протестируйте вначале
Ок. Тогда не торопите пока что) Я сделаю)
Форум вымер похоже, праздники пагубно повлияли=)
У меня вроде получилось сильно сократить очереди сообщений (Нужно для сертификации). Позже скину в шелв изменения.
Замечание от ртс:
Т.е. надо сделать проверку, если в данном соединении уже открыт поток репликации с какой-то таблицей, второй раз его открывать для другой таблицы не надо. И собственно спрашивают, зачем мы два раза поток репликации открываем?
У нас соединение одно. Если мы действительно два раза открываем что-то - это ошибка, надо открывать один раз.
Еще на ртс возникли вопросы на счет обработки lifeNum, переспросил что конкретно не нравится, завтра напишут. У нас точно все правильно написано? Из документации:
Еще на ртс возникли вопросы на счет обработки lifeNum, переспросил что конкретно не нравится, завтра напишут. У нас точно все правильно написано? Из документации:
Т.к. конкретной проблемы нет, то ответить всё ли у нас правильно невозможно. Событие OnStreamLifeNumChanged у нас обрабатывается
А остальные проблемы решены сейчас?
Я в своей версии программы разбил получение данных на три потока, и это помогло, очереди значительно снизились, этот вопрос у ртс отпал. Также вроде через клиринг прохожу нормально. Но у меня при работе робота стала вылетать иногда ошибка "не могу отменить заявку с номером таким-то", и не ясно, это косяк моего торгового алгоритма, или тех изменений, что я вносил чтобы через клиринг проходить. Короче, там явно придется еще повозиться, чтобы все аккуратно написать и все ошибки выловить
Ошибка говорит что заявка уже снята или исполнена. Тоесть, снять ее уже не получится. Обычно бывает из-за того, что или алгоритм неправильно работает, или данные не успевают прийти. Второе - это нормальная ситуация. Нужно разруливать подобное.
Всем привет! Написал робота скальпера для плазы и использованием библиотеки Stock#. Соответственно на демо-счете адекватно потестить не получается, пришлось проходить сертификацию. Отправил им логи после работы программы, вот что они написали:
Т.к. я пользуюсь библиотекой, как она есть, прошу специалистов помочь в решении поставленных вопросов. Буду очень вам благодарен.
Что за библиотека? Ссылкой поделитесь?😀
Какая помощь нужна? По первому вопросу - проблема известна, давно писали уже об этом. Как решать - тоже понятно. FiNick вроде сделал, но можете ему помочь в этом. Его изменения пока у него локально хранятся.
По второму - вроде всё расписано как надо делать. Как обрабатываем - смотрите OnStreamLifeNumChanged.
С номером жизни вроде нормально все. Сказали сделать сохранение ревизий, чтобы данные постоянно не подгружать, и тогда сертификат выдадут.
Проблема в том, что то что у нас было написано для этого (Save/LoadRevision) у меня вот не работает: делается LoadRevision и у меня только два инструмента в списке, и только по этим инструментам сделки подгружаются, как ремонтировать не знаю
Все правильно, ревизии в примере сохраняются для всех потоков. И при запуске подгружаются для всех же. В том числе и для потока инструментов. Поэтому, инструменты появляются только те, который имеют ревизию больше, чем максимально сохраненный. А это произойдет только после клиринга.
Мне кажется, РТС нужно убедить, что это бесполезное занятие. Для безбазовых клиентов нужны ВСЕ данные. Если же вам нужно иметь быстрый старт, то делать это нужно через сохранение инструментов локально. Я так и делаю, использую EntityFactory переопределенный (устанавливается через PlazaTrader.EntityFactory). Проблемы с очередями и параллельностью потоков вообще не стоит, потому что нет как таковой и прокачки данных.
FiNick, предлагаю сертификацию пройти совместно. Я уже отвечал на многие вопросы ранее. Засертифицируем вашу программу, засертифицируем и библиотеку.
Не совсем так, дело в том, что сама платформа StockSharp это достаточно широкий инструмент, её будет сложнее засертифицировать, чем мой вариант программы. У РТСа есть ряд требований к программе, те же очереди например, а у программиста, использующего StockSharp есть возможность разбить получение потоков репликации на несколько коннекшнов, и в зависимости от того как он это сделает, у него будут либо гигантские очереди, либо маленькие. Т.е. похоже придется внутрь PlazaTrader'a зашить правильное разбиение потоков по соединениям, что не комильфо...
Я могу рассказать, какие конкретно требования были у РТС, и как правиьно отвечать, но похоже чтобы засертифицировать саму платформу придется с ними повоевать)
Воевать не нужно. Нужно потратить время... Окей, давайте тогда получите своей сертификат, а я уже отпишусь далее, сославшись на вашу сертификацию. Типичный юзер, который может порушить систему РТС, не сможет понять, как менять кол-во потоков. Плюс количество потоков вряд ли на что-то влияет вообще. У вас какой канал до биржи?
Мне дали сертификат! Спросил, почему бы тогда не засертифицировать StockSharp:
Вопросы какие поднимаются на сертификации:
Так и смысл как раз в том, что S# будет использовать всё тоже. Разбиение по тредам и соединениям должно быть в S#, а не в отдельном приложении. 3-4) сейчас делается и так
У нас безбазовый клиент, а не базовый. Поэтому у нас БД не используется. По 3 - ини файлы у нас тоже создаются :)
не подскажите на каком этапе сертификация? и последние новости! Спасибо!
вам сертификация для чего? пробовали сертифицировать своего робота через PlazaTrader?
новости - в разделе новости на главной странице.
не все брокеры готовы предоставить доступ к Plaza без сертификации.
Нет сертификацию не проходил, через кого работаю без сертификации дает доступ!
А примерные сроки по сертификации платформы Stock# можете озвучить? Спасибо!
Сроков нет. Вам никто не мешает проходить сертификацию ваших роботов с использованием PlazaTrader самостоятельно. Более того, исходный код шлюза плазы открыт и вы можете его исправлять и дописывать как душе угодно.