Протокол SHOCK

Бинарный протокол для распределённых вычислений

Введение

SHOCK (Streaming High-speed Optimized Computing Kernel) – это протокол уровня приложения, разработанный специально для инфраструктуры Solenopsys. Название происходит от первоначальной идеи назвать кластеры "Shock Waves", которая позже была изменена на "Detonation" из-за вопросов с торговыми марками.

Основная цель протокола – обеспечить асинхронную коммуникацию в реальном времени между пользовательским интерфейсом, микросервисами, вычислительными ядрами и устройствами. В отличие от традиционных механизмов очередей сообщений, таких как RabbitMQ, SHOCK не поддерживает транзакционную передачу сообщений, концентрируясь на высокоскоростных потоковых возможностях.

Мотивация создания протокола

В современном промышленном производстве существует критическая потребность в сверхбыстрых протоколах передачи данных с высокой пропускной способностью. Промышленное оборудование функционирует в режиме реального времени, где каждая миллисекунда задержки может иметь значительные последствия для производственного процесса. Традиционные протоколы с использованием брокеров сообщений создают дополнительные задержки и не способны обеспечить требуемый уровень производительности.

Основная идея протокола SHOCK заключается в создании системы без выделенного брокера сообщений в качестве отдельного процесса. Подобно ZMQ, SHOCK реализует прямую коммуникацию между компонентами системы через разделяемую память. Однако SHOCK идет дальше – он способен обходить стандартное сетевое стека Linux с использованием XDP и AF_XDP, что позволяет достичь беспрецедентной производительности.

Такой подход особенно важен для:

• Систем управления промышленным оборудованием, где требуется минимальная задержка отклика
• Высокочастотных систем сбора данных с датчиков
• Распределенных систем управления производством
• Систем машинного зрения и контроля качества в реальном времени
• Систем распределенных вычислений для обработки больших объемов данных (трассировка, слайсинг и тд)

Оптимизация производительности

Ключевое преимущество SHOCK – компактный размер пакетов и возможность быстрого анализа пакетов. В отличие от протоколов, требующих полного парсинга данных перед обработкой, SHOCK позволяет мгновенно направлять сообщения соответствующим обработчикам.

Промышленное применение

Протокол специально разработан для промышленных сценариев использования:

• Управление промышленным оборудованием
• Распределённые вычисления
• Высокоскоростной обмен данными
• Системы мониторинга и управления в реальном времени
• Реализации цифровых фабрик

Сравнение с альтернативными протоколами

Протоколы AMQP, STOMP, и RSocket требуют отдельного процесса для работы месседж-брокера или серверного компонента, который потребляет знательные ресурсы и требует администрирования.

SHOCK

• Оптимален для промышленных систем реального времени
• Эффективен для высокопроизводительных вычислений и взаимодействия с железом
• Лучший выбор для систем с минимальной задержкой

AMQP

• Схожая функциональность, но более сложная реализация
• Отсутствие поддержки потоков
• Типичная реализация: RabbitMQ

STOMP

• Текстовый протокол
• Ориентация на платформу Java
• Тяжеловесность для корпоративного использования

RSocket

• Более подходящий по сравнению со STOMP
• Реализация ориентирована на Java
• Фокус на корпоративные системы

Архитектура

Философия

SHOCK отличается простотой и высокой производительностью, имея некоторые архитектурные сходства с протоколом ZMQ. Основные принципы дизайна включают:

• Минималистичный формат пакетов
• Высокоскоростную передачу данных
• Возможности обработки в реальном времени
• Гибкую маршрутизацию через uBFP маршрутизаторы
• Поддержку миллионов сообщений в секунду за счет использования XDP, AF_XDP и Shared Memory
• Сверхнизкую задержку (сотни наносекунд при межпроцессном взаимодействии)

Варианты транспортного уровня

Протокол поддерживает несколько транспортных механизмов:

• WebSocket (для связи кластера с пользовательским интерфейсом)
• UDP (для внутрикластерного взаимодействия)
• Разделяемая память (для обмена внутри хоста)
• TCP соединения Поддержка любых других видов транспорта может быть добавлена

Компоненты для поддержки протокола во фреймворках Detonation и Converged

Протокол SHOCK реализуется через несколько ключевых компонентов:

1. Модуль маршрутизатора на основе uBPF: Отвечает за маршрутизацию сообщений внутри кластера
2. Библиотека для фронтенда: Предоставляет интерфейс для взаимодействия с протоколом SHOCK
3. Библиотеки для бэкенда: Предлагают реализации для различных языков программирования

Особенности реализации протокола

Идентификация объектов

Протокол реализует гибкую систему идентификации объектов:

• Для операций с оборудованием: Указывает на конкретные микроконтроллеры на платах
• Для операций с кластером: Определяет конкретные контейнеры-получатели

Встроенная поддержка сессий, процессов и контекстов

• Древовидная структура контекстов процессов
• Авторизация и контроль доступа на основе сессий
• Обеспечивает расширяемость и обратную совместимость через флаги версий

Расширяемость

Каждый последний бит метазаголовка указывает, существует ли следующий байт метазаголовка. Если следующий байт присутствует, это означает, что используется следующая версия протокола.

• 1 версия - 1 бай метазаголовка
• 2 версия - 2 байта метазаголовка - текущая
• и тд.

Дизайн протокола включает механизмы для будущего развития:

• Флаги версий в метазаголовках
• Поддержка обратной совместимости
• Обработка ошибок для неподдерживаемых версий
• Гибкие возможности расширения

Структура протокола

Компоненты пакета

1. Метазаголовок (1-2 байта)
2. Заголовок (1-28 байт)
3. Тело сообщения

Стандартный размер сообщения около 1.5 КБ (соответвует размеру сетевого фрейма), хотя сообщения могут достигать размера до 64 КБ.

Структура метазаголовка

Первый байт (8 бит)

1. Флаг размера сообщения (1 бит) - Определяет хранение длины в 1 или 2 байтах
2. Флаг следующего сегмента (1 бит) - Указывает на наличие дополнительного сегмента
3. Длина идентификатора сообщения (2 бита) - От 0 до 3 байт
4. Длина поля объекта назначения (2 бита) - От 0 до 3 байт
5. Длина поля метода назначения (1 бит) - Указывает на длину поля в 1 байт
6. Флаг наличия второго байта (1 бит)

Второй байт (8 бит)

1. Длина поля сессии (2 бита) - От 0 до 3 байт
2. Длина поля процесса (5 бит) - От 0 до 16 байт
3. Резервный бит (1 бит) - Для будущих расширений

Основные сущности протокола

1. Процесс: Вычислительный процесс с кешированным состоянием
2. Объект: Адрес назначения (микросервис, ядро или устройство)
3. Метод: Способ вызова объекта (функция, событие или свойство)
4. Сессия: Идентификатор авторизации для потока сообщений