Нужно научиться получать данные по FAST протоколу. Для начала решил попробовать какую-нибудь готовую тестовую программу на тестовом доступе, т.к. полный чайник в этом вопросе. Затем самому написать клиент и обработчик потока.
Помогите разобраться, что дальше делать.
1. Работаю пока на Debian Linux 7.7 в консоли. Что нарыл со статичным адресом, то и имею, переустановить и проапгрейдить нельзя. 2. Получил тестовый доступ к MOEX - собщил свой внешний статический IP, получил IP VPN сервера и ссылки на ftp, где лежат xml Интернет - ftp://ftp.moex.com/pub/FAST/Spectra/test_templates/internet_test/ Торговая сеть, коллокация и универсальная схема - ftp://ftp.moex.com/pub/FAST/Spectra/test_templates/leased_line_test/ ”
Видимо, мне нужен вариант - "Интернет", если я через интернет работаю?
3. Насторил VPN соединение. Правильно или нет не знаю /etc/ppp/chap-secrets * * PPTP *
/etc/ppp/peers/moex pty "pptp 91.208.232.208 --nolaunchpppd" lock noauth nobsdcomp nodeflate name test remotename PPTP
RX трафик меняется со вренменем, но заметно меньше ожидаемого (ожидалось накопление около 1500 байт в секунду) TX трафик не меняется
4. Что со всем этим теперь делать, не знаю. Нашел на ftp такую программу fast_sensor, скопировал, добавил к ней xml из выше указанных источников, конфигурацию и шаблоны. Ничего в них не менял.
получаю бесконечный лог в таком виде: ./dump/2016-10-05T13_30_41.365865/FUT-BOOK-1_F_1/Incremental_A_239.192.70.1_40001 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/FUT-BOOK-1_F_1/Incremental_B_239.192.175.1_41001 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/FUT-BOOK-1_F_1/Snapshot_A_239.192.70.2_40002 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/FUT-BOOK-1_F_1/Snapshot_B_239.192.175.2_41002 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/FUT-BOOK-5_F_5/Incremental_A_239.192.70.3_40003 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/FUT-BOOK-5_F_5/Incremental_B_239.192.175.3_41003 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/FUT-BOOK-5_F_5/Snapshot_A_239.192.70.4_40004 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/FUT-BOOK-5_F_5/Snapshot_B_239.192.175.4_41004 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/FUT-BOOK-20_F_20/Incremental_A_239.192.70.5_40005 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/FUT-BOOK-20_F_20/Incremental_B_239.192.175.5_41005 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/FUT-BOOK-20_F_20/Snapshot_A_239.192.70.6_40006 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/FUT-BOOK-20_F_20/Snapshot_B_239.192.175.6_41006 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/FUT-BOOK-50_F_50/Incremental_A_239.192.70.7_40007 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/FUT-BOOK-50_F_50/Incremental_B_239.192.175.7_41007 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/FUT-BOOK-50_F_50/Snapshot_A_239.192.70.8_40008 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/FUT-BOOK-50_F_50/Snapshot_B_239.192.175.8_41008 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/FUT-TRADES_F/Incremental_A_239.192.70.9_40009 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/FUT-TRADES_F/Incremental_B_239.192.175.9_41009 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/FUT-TRADES_F/Snapshot_A_239.192.70.10_40010 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/FUT-TRADES_F/Snapshot_B_239.192.175.10_41010 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/FUT-INFO_F/Instrument Replay_A_239.192.70.11_40011 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/FUT-INFO_F/Instrument Replay_B_239.192.175.11_41011 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/FUT-INFO_F/Instrument Incremental_A_239.192.70.12_40012 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/FUT-INFO_F/Instrument Incremental_B_239.192.175.12_41012 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/INDEX_I/Incremental_A_239.192.70.13_40013 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/INDEX_I/Incremental_B_239.192.175.13_41013 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/INDEX_I/Snapshot_A_239.192.70.14_40014 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/INDEX_I/Snapshot_B_239.192.175.14_41014 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/NEWS_N/Incremental_A_239.192.70.15_40015 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/NEWS_N/Incremental_B_239.192.175.15_41015 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/NEWS-SKRIN_N/Incremental_A_239.192.70.16_40016 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/NEWS-SKRIN_N/Incremental_B_239.192.175.16_41016 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/OPT-BOOK-1_O_1/Incremental_A_239.192.70.17_40017 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/OPT-BOOK-1_O_1/Incremental_B_239.192.175.17_41017 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/OPT-BOOK-1_O_1/Snapshot_A_239.192.70.18_40018 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/OPT-BOOK-1_O_1/Snapshot_B_239.192.175.18_41018 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/OPT-BOOK-5_O_5/Incremental_A_239.192.70.19_40019 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/OPT-BOOK-5_O_5/Incremental_B_239.192.175.19_41019 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/OPT-BOOK-5_O_5/Snapshot_A_239.192.70.20_40020 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/OPT-BOOK-5_O_5/Snapshot_B_239.192.175.20_41020 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/OPT-BOOK-20_O_20/Incremental_A_239.192.70.21_40021 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/OPT-BOOK-20_O_20/Incremental_B_239.192.175.21_41021 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/OPT-BOOK-20_O_20/Snapshot_A_239.192.70.22_40022 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/OPT-BOOK-20_O_20/Snapshot_B_239.192.175.22_41022 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/OPT-BOOK-50_O_50/Incremental_A_239.192.70.23_40023 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/OPT-BOOK-50_O_50/Incremental_B_239.192.175.23_41023 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/OPT-BOOK-50_O_50/Snapshot_A_239.192.70.24_40024 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/OPT-BOOK-50_O_50/Snapshot_B_239.192.175.24_41024 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/OPT-TRADES_O/Incremental_A_239.192.70.25_40025 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/OPT-TRADES_O/Incremental_B_239.192.175.25_41025 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/OPT-TRADES_O/Snapshot_A_239.192.70.26_40026 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/OPT-TRADES_O/Snapshot_B_239.192.175.26_41026 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/OPT-INFO_O/Instrument Replay_A_239.192.70.27_40027 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/OPT-INFO_O/Instrument Replay_B_239.192.175.27_41027 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/OPT-INFO_O/Instrument Incremental_A_239.192.70.28_40028 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/OPT-INFO_O/Instrument Incremental_B_239.192.175.28_41028 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/OTC-TRADES_Q/Incremental_A_239.192.70.29_40029 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/OTC-TRADES_Q/Incremental_B_239.192.175.29_41029 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/OTC-TRADES_Q/Snapshot_A_239.192.70.30_40030 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/OTC-TRADES_Q/Snapshot_B_239.192.175.30_41030 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/OTC-ISSUES_Q/Instrument Replay_A_239.192.70.31_40031 muticast source ip 10.50.129.90 ./dump/2016-10-05T13_30_41.365865/OTC-ISSUES_Q/Instrument Replay_B_239.192.175.31_41031 muticast source ip 10.50.129.90 Format: local time: packets count, speed (packets/second), max. burst (packets per 100 ms), avg. net delay (ms), avg. gate delay (ms) 2016-Oct-05 13:30:41.850950: 0, 0, 0, 0.000, 0.000 2016-Oct-05 13:30:42.852035: 0, 0, 0, 0.000, 0.000 2016-Oct-05 13:30:43.853157: 0, 0, 0, 0.000, 0.000 2016-Oct-05 13:30:44.854049: 0, 0, 0, 0.000, 0.000 2016-Oct-05 13:30:45.854943: 0, 0, 0, 0.000, 0.000 2016-Oct-05 13:30:46.855838: 0, 0, 0, 0.000, 0.000 2016-Oct-05 13:30:47.856727: 0, 0, 0, 0.000, 0.000 2016-Oct-05 13:30:48.857626: 0, 0, 0, 0.000, 0.000 2016-Oct-05 13:30:49.858519: 0, 0, 0, 0.000, 0.000 2016-Oct-05 13:30:50.859406: 0, 0, 0, 0.000, 0.000
Понимаю, что ничего не понимаю и подоэреваю, что ничего не получаю.
Как это интерпретировать? Что делать со всем этим дальше?
Я понимаю, что надо матчасть учить, это само-собой, долгими зимними вечерами, она бескрайняя, а для начала хотелось бы что-то вроде пожаговой инструкции, по быстрому старту.
Продолжаем разговор, т.к. в help@moex.com не всегда отвечают.
С VPN подключением справиться наконец удалось. Всё дело было в маршрутизации. По умолчанию PPPD неправильно настраивал дефолтный шлюз. Пришлось исправить, ниже написано как.
Однако есть проблема с тестовой программой fast_sensor, которую я скачал с ftp. При вызове она подключается к серверу и начинает получать ненулевые данные, но через некоторое время приём данных обрывается. Программа продолжает работать, но выводит нулевые данные.
Вот момент прекращения приёма данных - нули после packets count=5999:
Я выяснил, что ,вероятно, это могло быть связано с пропаданием интерфейса, а вместе с ним и роутинга. Причем, причиной пропадания интерфейса является именно fast_sensor, т.к. без неё роутинг и интерфейс не падают.
Я частично решил эту проблему, добавив параметр persist в /etc/ppp/peers/moex,
pty "pptp 91.208.232.208 --nolaunchpppd" lock persist noauth nobsdcomp nodeflate nodefaultroute noreplacedefaultroute name test remotename PPTP
а также добавил в конец файла /etc/ppp/ip-up команды для автоматической настройки маршрутизации
#закомментировал, т.к. именно это портило маршрутизацию #route del default #route add default dev ppp0
#добавил на основании данных из configuration.xml route add -net 1.1.0.0 netmask 255.255.0.0 ppp0 route add -net 10.50.0.0 netmask 255.255.0.0 ppp0 route add -net 239.192.0.0 netmask 255.255.0.0 ppp0
#Это нашел здесь https://ksergey.github.io/2016/04/11/moex-uat/ ,не помогло sysctl net.ipv4.conf.ppp0.rp_filter=0 sysctl net.ipv4.conf.all.rp_filter=0
#Это добавил в борьбе с описанной проблемой, не помогло ip route static adjust-time 10
Теперь интерфейс переподнимается сам и сразу восстанавливает маршрутизацию.
Последовательность событий следующая, сначала в fast_sensor перестает принимать данные и выводит нули, но это не приводит сразу к удалению интерфейса и роутинга, которые продолжают оставаться активными ещё около минуты. Затем интерфейс и роутинг пропадают по какой-то причине, связанной с fast_sensor, затем они переподнимаются самостоятельно, интерфейс получает с сервера тот же самый IP, что был до этого, т.е. всё восстанавливается в точности как было. Fast_sensor всё это время возвращает нулевые данные и НЕ восстанавливается после восстановления интерфейса и роутинга. Если fast_sensor перезапустить после прекращения приема, но до момента переподъема интерфейса, то его работоспособность НЕ восстанавливается. Если же его перезапустить после переподъема интерфейса, то данные снова начинают поступать, но не долго.
Такое ощущение, что на стороне сервера данное соединение через некоторое время(меньше минуты) выбрасывается из multicast группы и связь разрывается.
Описанный выше метод переподъема интерфейса и перезапуска процесса приёма данных не решает проблему, т.к. в этот период пропущенные данные теряются безвозвратно, что является критической проблемой.
Вопросы.
1) С чем связано неожиданное прекращение приёма данных в fast_sensor при полностью настроенном соединении, роутинге и исправной связи? 2) Существует ли описание опций программы fast_sensor для решения данной проблемы? Краткого --help не достаточно для понимания могут ли они быть полезны. 3) Как "сказать" серверу, чтобы он не разрывал соединение?
У кого-нибудь наблюдалось подобное прекращение приёма данных с тестового контура?
Последний раз редактировалось автором 07.10.2016 17:25, всего редактировалось 1 раз
Коллеги, а кто-нибудь настраивал VPN соединение для получения тестовых рыночных данных FAST в CentOS 7? Я пробовал делать с теми же настройками, которые описаны в этой ветке для Ubuntu, но у меня VPN соединение не поднимается. Может быть, кто-нибудь сможет подсказать, как его правильно настроить?
Shurik
Стаж: 14 лет 3 месяца Откуда: Санкт-Петербург Сообщений: 635
В итоге поднять VPN соединение удалось, но рыночные данные FAST с тестового полигона пока так и не вижу. Проблема, как выясняется в том, что подписка идет for any source вместо подписки на группу с указанным source. При этом точно такой же код в Windows на C из биржевой утилиты ssml (с точностью до различных заголовочных файлов, разумеется) выполняет правильную source specific multicast подписку, а в линуксе не работает. Никто случайно не сталкивался с подобными чудесами в CentOS 7?
Последний раз редактировалось автором 04.08.2019 22:44, всего редактировалось 1 раз
В итоге поднять VPN соединение удалось, но рыночные данные FAST с тестового полигона пока так и не вижу. Проблема, как выясняется в том, что подписка идет for any source вместо подписки на группу с указанным source. При этом точно такой же код в Windows на C из биржевой утилиты ssml (с точностью до различных заголовочных файлов, разумеется) выполняет правильную source specific multicast подписку, а в линуксе не работает. Никто случайно не сталкивался с подобными чудесами в CentOS 7?
Поиск
Правила
Пользователи
Профиль
Регистрация
Вход
oint-to-Point Protocol