Изменения касательно серверных сессий и пр. правки

KLDR RESERVED KEYS.md

@@ -39,6 +39,10 @@
 	- _Значение:_ `0x08`
 	- _Тип:_ `Power`
 	- Права доступа к конкретному объекту.
+- ServerSession
+	- _Значение:_ `0x09`
+	- _Тип:_ `uint32_t`
+	- Идентификатор серверной сессии. В случае с аутентифицированным соединением, его присутствие обязательно.
 
 
 

OVERVIEW.md

@@ -11,7 +11,7 @@ Stadium это протокол для безопасной коммуникац
 - Совместимость со всеми мажорными оверлейными сетями (Tor, I2P и yggdrasil);
 - Расширяемость.
 
-В сей спецификации вы иногда сможете встретить примеры кода и упоминание типов данных языка C++, так как без них обойтись моментами сложно.
+В сей спецификации вы можете встретить примеры кода и упоминание типов данных языка C++.
 
 
 
@@ -48,11 +48,11 @@ Stadium это протокол для безопасной коммуникац
 
 Все категории вместе являются типом события. Значение типа - это шестнадцатеричное число, которое указывается в начале пакета.
 
-Пакеты с событиями всех категорий, кроме явно оговорённых или принадлежащих к надкатегории Server2Client, содержат идентификатор серверной сессии, являющийся четырёхбайтным числом без знака (`uint32_t`).
-
 Пакеты с событиями всех категорий, кроме явно оговорённых, содержат хэш полезной нагрузки, зашифрованный с помощью закрытого ключа подписи отправляющего. Этот подписанный хэш гарантирует достоверность полезной нагрузки на уровне прямого подключения ("клиент-сервер" или "сервер-сервер").
 
-Данные (AKA "полезная нагрузка") могут быть представлены в формате фиксированной схемы или в формате KLDR ("Key-Length-Data-Repeat"), которые являются расположенными последовательно парами "ключ-значение" и могут быть расположены в произвольном порядке относительно друг-друга. Сервер и клиент могут перемешивать ячейки перед отправкой намеренно. Применяемый формат зависит от типа события, но чаще всего это KLDR. Все неизвестные ключи при его парсинге игнорируются. Одна пара (AKA "ячейка") имеет следующий вид:
+Идентификатор события является двухбайтным числом без знака (`uint16_t`) и служит для определения отношения запросов к ответам, при использовании асинхронной схемы передачи данных.
+
+Данные (AKA "полезная нагрузка") могут быть представлены в формате фиксированной схемы или в формате KLDR ("Key-Length-Data-Repeat"), которые являются расположенными последовательно парами "ключ-значение" в неопределённом порядке относительно друг-друга. Сервер и клиент могут перемешивать ячейки перед отправкой намеренно. Применяемый формат зависит от типа события, но чаще всего это KLDR. Все неизвестные ключи при его парсинге игнорируются. Одна пара (AKA "ячейка") имеет следующий вид:
 
 `[key][data length][data]`
 
@@ -60,13 +60,15 @@ Stadium это протокол для безопасной коммуникац
 
 `[cell_1][cell_2][cell_3]...[cell_n]`
 
-Ключ и длинна данных являются шестнадцатеричными числами, размерность которых фиксирована и составляет 8 и 16 бит соответственно. <!--задаётся на этапе хэндшейка.--> Полезная нагрузка не может отсутствовать полностью (кроме особо-оговорённых случаев), а ключ не может являться нулём. Если значение конкретной пары пусто, то длинна данных должна быть нулём.
+Ключ и длинна данных являются шестнадцатеричными числами, размерность которых фиксирована и составляет 8 и 16 бит соответственно. Полезная нагрузка не может отсутствовать полностью, а ключ не может являться нулём. Если значение конкретной пары пусто, то длинна данных должна быть нулём.
 
 Исходя из всего вышеописанного, итоговая примерная структура пакета выглядит следующим образом:
 
-`[category][subcategory][server session: 4B][payload hash: ~B][payload: >0B]`
+`[category][subcategory][event id: 2B][payload hash: ~B][payload: >0B]`
 
-Размер пакета не нормирован и ответственность за его менеджмент остаётся на транспортном уровне. (Эталонная реализация Stadium будет использовать общий универсальный интерфейс, который, в свою очередь, заворачивать все данные в релевантный протокол транспортного уровня)
+Размер пакета не нормирован и ответственность за его менеджмент остаётся на транспортном уровне.
+
+P.S.: _эталонная реализация Stadium будет использовать общий универсальный интерфейс, который, в свою очередь, заворачивать все данные в релевантный протокол транспортного уровня._
 
 ### Зарезервированные события
 

SESSIONS.md

@@ -10,7 +10,7 @@
 
 До выполнения аутентификации, сервер может, но не обязан, подписывать каждый свой пакет. Клиент не должен подписывать свои пакеты и должен устанавливать хэш полезной нагрузки в нулевое значение.
 
-Сервер не должен проверять подпись пакетов клиента. Клиент может проверять подпись только в случае наличия у него открытого ключа сервера.
+Сервер не должен проверять подпись пакетов клиента. Клиент должен проверять подпись только в случае наличия у него открытого ключа сервера.
 
 ### Регистрация