4.6 KiB
События
Категории и типы
Существует три уровня категорий событий:
Надкатегория описывает типы взаимодействующих узлов. Не указывается и зависит от контекста. Варианты: Client2Server (событие сгенерированное клиентом для сервера), Server2Client (событие сгенерированное сервером для клиента), Peer2Peer (событие сгенерированное узлом для другого узла того-же ранга, в том числе это касается серверов в федерации).
Категория описывает события одного класса. Является однобайтовым числом без знака. Всегда больше нуля. Например: Authentication, Object, т.п.
Подкатегория описывает конкретное событие из класса, соответствующего категории. Является однобайтовым числом без знака. Всегда больше нуля. Например: Login, GetContents, т.п.
Все категории вместе - являются типом события. Информацию про зарезервированные типы вы можете найти в Reserved events.md.
Содержание и структура
События всех типов содержат хэш полезной нагрузки размером равно или более 16 байт, зашифрованный с помощью закрытого ключа подписи отправляющего. Этот подписанный хэш гарантирует достоверность полезной нагрузки на уровне прямого подключения между двумя узлами. Используемый алгоритм хэширования определяется на этапе рукопожатия.
Идентификатор серверной сессии является четырёхбайтным целым числом без знака. Подробнее про сессии - в Sessions.md.
Идентификатор события является двухбайтным целым числом без знака и предназначен для определения отношения запросов к ответам при асинхронном обмене событиями.
Данная версия протокола не накладывает ограничений на формат полезной нагрузки, за исключением базовых событий, которые представлены данными в формате LBM. Описание всех предопределённых в базовом протоколе ключей ячеек LBM доступно в Reserved LBM keys.md. Неизвестные ключи при обработке полезной нагрузки игнорируются. Если полезная нагрузка отсутствует, то она заменяется на один нулевой байт.
Исходя из всего вышеописанного, минимальный размер сериализованного в бинарный вид события составляет 25 байт, а его итоговая структура выглядит следующим образом:
[category: 1B][subcategory: 1B][session id: 4B][event async id: 2B][payload hash: >16B][payload: >0B]
Максимальный размер события не нормирован и ответственность за его менеджмент остаётся на транспортном уровне. Максимальный размер полезной нагрузки события определяется на этапе рукопожатия.
Событие в шифрованном соединении
В шифрованном соединении события сериализуются в бинарное представление и зашифровываются с помощью утверждённого симметричного ключа сессии.