WebSocket API
Торговая система АЛОР Брокер поддерживает взаимодействие по протоколу WebSocket через интерфейс WebSocket API.
Данный канал связи предназначен для высокоскоростного асинхронного обмена данными в рамках одной сессии.
Особенности интерфейса
В основе WebSocket API лежит модель двустороннего взаимодействия с сохранением состояния (stateful). После установки соединения канал остаётся открытым, чт о позволяет серверу инициативно отправлять данные клиенту без предварительного запроса.
Такая модель взаимодействия имеет свои преимущества и недостатки при практическом использовании интерфейса.
| Преимущество | Недостаток |
|---|---|
| Постоянное соединение минимизирует задержки (latency) за счёт отсутствия необходимости повторных рукопожатий (handshakes) | Любой сетевой сбой приводит к потере всех активных подписок и требует процедуры их полного восстановления |
| Асинхронный и двусторонний обмен данными позволяет серверу мгновенно транслировать рыночные изменения | Наличие единого потока сообщений требует реализации механизмов парсинга и распределения данных на стороне клиента |
| Доставка обновлений в реальном времени исключает необходимость постоянного опроса системы (polling) | Риск переполнения буфера при высокой интенсивности входящих сообщений, что может привести к принудительному закрытию сессии |
| Минимальный объём заголовков в кадрах снижает нагрузку на сеть в сравнении с классической HTTP-моделью | Специфические требования к сетевым экранам и прокси-серверам для поддержания длительных TCP-сессий |
Помимо перечисленных особенностей для данного интерфейса действуют следующие ограничения:
- не более 10 одновременных соединений;
- не более 5000 подписок на одну сессию;
- не более 5000 необработанных сообщений в серверном буфере.
Сценарии использования
Выбор WebSocket API оправдан в задачах, требующих высокой скорости реакции и актуальности данных. Ниже представлен ряд сценариев, при которых использование данного протокола является целесообразным:
| Допустимо | Недопустимо |
|---|---|
| Оперативное получение котировок, обновлений биржевого стакана и ленты сделок | Загрузка тяжёлых статических справочников и полных списков инструментов |
| Мониторинг статусов собственных заявок и изменений портфеля в реальном времени | Получение исторических данных за длительные периоды времени |
| Торговля с высокой интенсивностью операций и строгими требованиями к задержкам | Разовые проверки состояния счёта в сценариях с низкой активностью |
| Поддержание событийной модели работы торгового алгоритма | Регулярное получение данных, не требующих мгновенной реакции |
Для первичной загрузки справочников и исторических данных используйте HTTP API.
Высокочастотные рыночные данные рекомендуется отделять от критических системных уведомлений, распределяя их по разным соединениям.
Рекомендации
Для обеспечения стабильности взаимодействия и снижения риска блокировки доступа придерживайтесь следующих правил:
- Используйте локальный буфер. Реализуйте модель «принять — сохранить — обработать», чтобы избежать переполнения серверного буфера (лимит — 5000 сообщений).
- Контролируйте жизненный цикл подписок. Присваивайте уникальные
guidкаждой подписке для их идентификации и своевременно отписывайтесь от неактуальных потоков. - Применяйте стратегии переподключения. При разрыве соединения используйте механизмы
backoffиjitter, чтобы избежать взрывной нагрузки на систему при восстановлении сессий. - Соблюдайте количественные лимиты. Принудительно ограничивайте на стороне клиента число открытых соединений (не более 10) и активных подписок (не более 5000 на соединение) согласно правилам системы.
Комбинируйте все доступные интерфейсы системы для максимально эффективного решения стоящих перед вами задач.
Игнорирование рекомендаций и/или использование WebSocket API не по назначению приведёт к блокировке доступа к системе. Подробнее об этом читайте в статье "Ограничения и рекомендации".