|
|
markhСтаж: 6 лет 7 месяцевСообщений: 122 | | | | Здравствуйте,
Я решил не плодить темы. Вопросы для новичка будут появляться и будет разумно все иметь в одной ветке.
Вопрос про tcp replay:
Открываю сокет, формирую логон, посылаю, в ответ приходит 0 байтов. Делаю вторую итерацию и получаю логаут с причиной
логон "8=FIXT.1.1\x19=61\x135=A\x149=TEST\x156=MOEX\x11128=9\x134=1\x152=20141105-22:43:15\x11137=9\x110=021\x1"
логаут "template_id=2102 5 FIXT.1.1 MOEX 2 20141105222844000 Limit of connections for this IP exceeded "
в общем вопросы такие:
1. почему после открытия сокета и отправки логона я ничего не вижу во входящих?
2. почему при второй попытке приходит отбой?
Спасибо.
| | | | | | | Последний раз редактировалось автором 06.11.2014 01:50, всего редактировалось 1 раз |
|
markhСтаж: 6 лет 7 месяцевСообщений: 122 | | | | 1 победил
2 теперь вижу вот такие результаты
логон "8=FIXT.1.1\x19=61\x135=A\x149=TEST\x156=MOEX\x11128=9\x134=1\x152=20141107-16:49:08\x11137=9\x110=034\x1"
логаут "45 template_id=2102 5 FIXT.1.1 MOEX TEST 2 20141107165133000 Invalid username or password. "
какой логин использовать?
| | |
|
Александр СтриковскийСтаж: 4 года 2 месяцаСообщений: 26 | | | | Здравствуйте, markh,
В тэгах 553 554 должна быть одна из пар user0 \ pass0 ; user1 \ pass1 ; user2 \ pass2
Это для всех сервисов, тестовых\боевых, фондовых\валютных - неважно
Немного информационной поддержки в вашей войне с TCP replay, в основном уже не актуально конечно, но друг да пригодится кому
Процедура восстановления пропущенных сообщений через TCP следующая:
1. Установить TCP соединение с сервером Market Data Multicast.
2. Отправить серверу сообщение LOGON(35=A). В ответ, при успешном выполнении должно придти FAST сообщение Logon(35=A).
3. Отправить сообщение Market Data Request (35=V) с установленными тэгами
А. APpplID(1180) – идентификатор канала (значения можно посмотреть в конфигурационном файле OLR, OBR, TLR, or MSR)
Б. Диапазон сообщений – ApplBegSeqNum(1182) и ApplEndSeqNum(1183)
Если запрос выполнен корректно, сервер пришлет закодированные в FAST сообщения из запрошенного диапазона, в противном случае сервер пришлет FAST Logout(35=5) с указанием причины отказа.
Разное:
Соединение закроется после ответа сервера. Сервер обрабатывает только первый запрос пользователя, остальные будут проигнорированы. Процедура восстановления позволяет восстанавливать до 500 сообщений. Необходимо учитывать, что сервис предназначен для запросов единичных или не слишком больших диапазонов сообщений. Если обращений к серверу будет слишком много попытки подключения будут отклонены.
Адрес и порт TCP канала можно смотреть в конфигурационном файле, например ниже приведен тэг для фондового рынка
<connection id="H">
<type feed-type="Historical Replay">H</type>
<protocol>TCP/IP</protocol>
<ip>1.1.1.30</ip>
<port>10000</port>
</connection>
Поподробней о параметрах сообщения Logon(35=A):
MsgSeqNum(34) – всегда 1
SenderCompID(49) - произвольная строка
TargetCompID(56) - MOEX
Username(553) и Password(554) – используется комбинация из user0 / pass0 … user2 / pass2
В принципе, по таким вопросам можно смело обращаться в техподдержку, они помогут.
| | |
|
markhСтаж: 6 лет 7 месяцевСообщений: 122 | | | | Спасибо. Логин прошел.
Однако, 2 вопроса.
1. зачем 3 пары?
2. ваша сторона сбрасывает коннект при Market Data Request (V) без сообщения об ошибке.
Было бы здорово, если бы вы смогли привести в пример правильное сообщение.
в качестве примера мое, которое не проходит
8=FIXT.1.1 9=87 35=V 49=TEST 56=MOEX 1128=9 34=2 52=20141111-13:01:26 1180=OLR 1182=216342 1183=216342 10=079
Это бы сильно сэкономило время разработки.
Спасибо.
| | | | | | | Последний раз редактировалось автором 11.11.2014 20:48, всего редактировалось 1 раз |
|
Александр СтриковскийСтаж: 4 года 2 месяцаСообщений: 26 | | | | 1. Вкратце - по историческим причинам. Это подходящее количество логинов с которым серверу удобно работать.
2. Мой пример 8=FIXT.1.1.9=85.35=V.1128=9.49=SimpleClient.56=MOEX.34=2.52=20141113-10:04:49.1180=OLR.1182=1.1183=7.10=054.
С вашим проблема в порядке тэгов
1128 AppVerID О String (1) ‘9’ (FIX50SP2) Определяет версию протокола для application messages.
Всегда содержит незашифрованные данные, должно быть
первым полем в сообщении.
35 MsgType О String (10) Определяет тип сообщения. Всегда содержит незашифрованные
данные, должно быть третьим полем в сообщении.
Это из документации стр. 27 ftp://ftp.moex.com/pub/FAST/ASTS/docs/RUS%20Market%20Data%20Multicast%20User%20Guide%20Ver%203.3.pdf
| | |
|
markhСтаж: 6 лет 7 месяцевСообщений: 122 | | | | Спасибо, Александр.
Правда дело было не только в последовательности.
| | |
|
markhСтаж: 6 лет 7 месяцевСообщений: 122 | | | | такой вопрос:
после определенного времени, перестают генерироваться снепшоты, то есть snap.LastMsgSeqNumProcessed замирает и не увеличивается относительно потока инктрементов.
то есть реальна ситуация, когда осуществляется поздний вход и первое сообщение инкремента намного больше чем snap.LastMsgSeqNumProcessed, что по логике восстановления фатально
нормально ли это, если клиент подключается, например, ночью, когда нет торгов, и следовательно этой логике, снепшоты вне реальности?
| | | | | | | Последний раз редактировалось автором 20.11.2014 01:21, всего редактировалось 2 раза |
|
Александр СтриковскийСтаж: 4 года 2 месяцаСообщений: 26 | | | | markh,
Не совсем понял, пришлите пожалуйста пример. Логика должна сохраняться на всем интервале работы сервиса. Вы подключаетесь, получаете LastMsgSeqNumProcessed, дорабатываете соответствующие 35=X 34=LastMsgSeqNumProcessed и начинаете работу.
| | |
|
markhСтаж: 6 лет 7 месяцевСообщений: 122 | | | | на тестовом полигоне я:
1. открываю OLS, OLR одновременно
2. получаю все снепшоты от 1 до Последнего.
3. параллельно собираю инкременты с самого открытия OLR
4. когда все снепшоты получены я вижу, что LastMsgSeqNumProcessed из OLS меньше первого полученного инкремента из OLR
если дальше продолжать слушать снепшоты, то они также транслируются с неизмененным LastMsgSeqNumProcessed
это наблюдается после торгов, например ночью.
но логика должна сохраняться вне зависимости от времени подключения к системе.
| | | | | | | Последний раз редактировалось автором 21.11.2014 18:19, всего редактировалось 4 раза |
|
westtrdСтаж: 7 лет 5 месяцевОткуда: BelarusСообщений: 1034 | | | | на мамбовском фасте это надо смотреть в разрезе инструментов
то есть, LastMsgSeqNumProcessed может не соответствовать всем инструментам, но будет соответствовать отдельным инструментам.
| | |
|
markhСтаж: 6 лет 7 месяцевСообщений: 122 | | | | westtrd,
пускай по инструменту, но это не решает проблемы.
пример:
последний LastMsgSeqNumProcessed по всем инструментам = 100
первый инкремент = 603
декодируем сообщение, видим, что repseq по инструменту не следующий по отношение к снепшоту, значит нужно восстановление.
заказываем реплей с сообщение со 101 по 602, получаем отбой т.к. запрос на >500 сообщений.
восстановление из снепшота тоже невозможно, см выше.
что делать?
| | |
|
westtrdСтаж: 7 лет 5 месяцевОткуда: BelarusСообщений: 1034 | | | | Еще раз.
LastMsgSeqNumProcessed нужно процессить в разрезе инструментов.
| | |
|
westtrdСтаж: 7 лет 5 месяцевОткуда: BelarusСообщений: 1034 | | | | markh писал(а):westtrd,
последний LastMsgSeqNumProcessed по всем инструментам = 100
первый инкремент = 603
что делать?
Если Вы, как и положено, включаете сначала накопление инкрементов, такая ситуация невозможна в принципе.
Рекомендую начинать с 1 номера снапшота
| | |
|
markhСтаж: 6 лет 7 месяцевСообщений: 122 | | | | к сожалению, возможна на тестовом полигоне.
на боевом пока не пробовал до выяснения, но попробую и ожидаю, что там такого нет.
что касается в разрезе инструментов, то повторюсь, что это не причина. когда это возникает, то снепшоты крутятся с 1 по N-ый с одими и теми же LastMsgSeqNumProcessed по инструменту.
похоже, что все это особенность тестовго полигона.. но хотелось бы подтверждения от хозяев.
из логов по тесту. суббота.
[WARN] 2014-11-22 01:30:12.697920 snashot < increment ticker=GAZP snap_LastMsgSeqNumProcessed=308758 buf.content[0]=316509
| | | | | | | Последний раз редактировалось автором 25.11.2014 11:25, всего редактировалось 3 раза |
|
westtrdСтаж: 7 лет 5 месяцевОткуда: BelarusСообщений: 1034 | | | | Тестовым полигоном фаста никогда не пользовался, ибо сертификация там не требуется.
Если есть доступ к реальному фиду, делать так:
1. запускать инкремент
2. запускать снепшот
3. начиная с sequence = 1 и до sequence = 1 принять снепшот, сформировав мап инструмент -> LastMsgSeqNumProcessed
3.1 слияние делать или до исчерпания инкрементов, или запомнить секвенси на момент окончания приема снепшотов
4. декодировать снепшот и поместить его в хранилище
5. по каждому инструменту отбросить все инкременты, меньшие или равные LastMsgSeqNumProcessed для данного инструмента
После выполнения - фид в онлайне
| | |
|
|
Поиск
Правила
Пользователи
Профиль
Регистрация
Вход
