Исправить определение клиентского DM-вызова

2026-08-25 19:30:44 +04:00
parent d8e0c77951
commit 7d929e626e
9 changed files with 996 additions and 6 deletions
@@ -152,7 +152,7 @@
 }
 ```

-`sourceServerLogin` необязателен для совместимости. Пока межсерверная авторизация отложена, это поле считается доверенным. Пользовательская подпись signed-блока проверяется всегда.
+`sourceServerLogin` необязателен для совместимости. Пока межсерверная авторизация отложена, это поле считается доверенным. Пользовательская подпись signed-блока проверяется всегда. Пустой `sourceServerLogin` трактуется как клиентский вызов, непустой - как peer-вызов.

 Успешный ответ содержит существующие `messageKey`, `baseKey` и счётчики realtime-доставки. Повтор уже сохранённой той же ревизии обрабатывается идемпотентно.

@@ -356,7 +356,11 @@ Pull-синхронизация событий владельца с `synced=fal

 Ответ содержит `messageKey`, `known` и `delivered`. `delivered=true` означает доставку хотя бы одному серверу получателя.

-Периодический процесс использует одно WS-соединение с peer: сначала синхронизирует настройки, затем вызывает `DmSyncBatch` до завершения страниц и ACK. Существующий `MarkAllUserSettingsUnsynced` также сбрасывает DM-флаги и возвращает `dmUpdated`; отдельной операции `MarkAllDmUnsynced` нет.
+Периодический процесс использует один логический последовательный сеанс поверх
+постоянного WSS-пула: сначала синхронизирует настройки, затем вызывает
+`DmSyncBatch` до завершения страниц и ACK. Существующий
+`MarkAllUserSettingsUnsynced` также сбрасывает DM-флаги и возвращает
+`dmUpdated`; отдельной операции `MarkAllDmUnsynced` нет.

 Основные ошибки межсерверных операций:

@@ -0,0 +1,105 @@
+# Межсерверное соединение и `ServerHello`
+
+Документ описывает транспортный слой постоянных WSS-соединений между серверами SHiNE.
+Он не меняет форматы DM, блоков, настроек, ACK или расписания повторных попыток.
+
+## 1. `ServerHello`
+
+После установления исходящего WSS-соединения сервер первым запросом отправляет:
+
+```json
+{
+  "op": "ServerHello",
+  "requestId": "server-hello-001",
+  "payload": {
+    "serverLogin": "shineupme",
+    "protocolVersion": 1,
+    "capabilities": [
+      "dm-sync",
+      "settings-sync",
+      "block-sync",
+      "connection-pool"
+    ]
+  }
+}
+```
+
+Успешный ответ:
+
+```json
+{
+  "op": "ServerHello",
+  "requestId": "server-hello-001",
+  "status": 200,
+  "payload": {
+    "accepted": true,
+    "serverLogin": "server2",
+    "protocolVersion": 1,
+    "capabilities": [
+      "dm-sync",
+      "settings-sync",
+      "block-sync",
+      "connection-pool"
+    ]
+  }
+}
+```
+
+На текущем этапе `serverLogin` принимается на доверии. Подпись, challenge и
+проверка корневого ключа сервера намеренно отложены. Поэтому `ServerHello`
+фиксирует тип соединения и возможности peer, но пока не является
+криптографической аутентификацией.
+
+## 2. Пул соединений
+
+- физическое соединение создаётся одно на `serverLogin`;
+- логические операции DM, settings и blockchain используют один WSS;
+- завершение `RemoteSyncSession` не закрывает физический сокет;
+- известные peer берутся из `sync_servers` и `user_access_servers_current`;
+- список перечитывается каждые 30 секунд;
+- при изменении URL соединение пересоздаётся;
+- новые запросы не повторяются транспортом автоматически: действующие
+  domain-воркеры сохраняют прежние правила retry и идемпотентности.
+
+## 3. Приоритеты
+
+| Приоритет | Операции |
+| --- | --- |
+| `REALTIME` | доставка DM, deletes, `GetDmDeliveryStatus` |
+| `NORMAL` | настройки, `DmSyncBatch` и access-data sync |
+| `BULK` | blockchain heads, blocks, `AddBlock` backfill |
+
+На одном peer одновременно исполняется один запрос. Приоритет применяется к
+ожидающей очереди и не прерывает уже начатую операцию.
+
+## 4. Ping, reconnect и таймауты
+
+Значения по умолчанию:
+
+| Параметр | Значение |
+| --- | ---: |
+| `server.pool.pingIdleSeconds` | `120` |
+| `server.pool.pongTimeoutSeconds` | `15` |
+| `server.pool.requestTimeoutSeconds` | `12` |
+| `server.pool.connectTimeoutSeconds` | `15` |
+| `server.pool.callerTimeoutSeconds` | `35` |
+| `server.pool.maxQueuePerPeer` | `2000` |
+
+Ping отправляется WebSocket control-frame только после периода отсутствия
+полезного трафика. При потере соединения применяется reconnect с jitter и
+ступенями до 60 секунд.
+
+## 5. Диагностика
+
+Внутренний snapshot пула хранит для каждого peer:
+
+- состояние соединения;
+- URL;
+- времена connect/activity/ping/pong;
+- число reconnect;
+- размеры очередей по приоритетам;
+- успешные, ошибочные и просроченные запросы;
+- последнюю ошибку.
+
+Агрегированное состояние периодически записывается в серверный лог. Отдельная
+публичная операция метрик на этом этапе не добавляется.
@@ -103,6 +103,8 @@ DM считается доставленным, когда signed-входящу

 При обрыве соединения неподтверждённый элемент остаётся `synced=false` и безопасно приходит повторно. Элемент, полученный от peer, локально сразу считается синхронизированным, чтобы не образовалась петля.

+`sourceServerLogin` является единственным признаком межсерверного вызова для этих операций: если поле пустое, запрос считается клиентским и его запись не должна сразу переводиться в `synced=true`.
+
 Синхронизация настроек и DM проходит последовательно через один WS-сеанс: сначала настройки, затем все страницы DM. Если второй сервер был выключен, после включения он сам догружает пропущенные элементы.

 Существующий `MarkAllUserSettingsUnsynced` также сбрасывает DM-флаги. После сброса история повторно передаётся как синхронизация, но старые сообщения получателю заново не отправляются: delivery-состояние создаётся с учётом их возраста и не открывает завершённую часовую очередь.
@@ -489,7 +489,7 @@ Request:
 }
 ```

-`sourceServerLogin` пока доверяется без отдельной межсерверной подписи. Сервер всё равно проверяет пользовательскую подпись самого `SHiNE_DM`. Успешный ответ сохраняет старые поля `messageKey`, `baseKey` и счётчики realtime-доставки.
+`sourceServerLogin` пока доверяется без отдельной межсерверной подписи. Сервер всё равно проверяет пользовательскую подпись самого `SHiNE_DM`. Для `ReceiveOutcomingMessage` и `SendMessagePair` пустой `sourceServerLogin` означает клиентский вызов, непустой - peer-вызов. Успешный ответ сохраняет старые поля `messageKey`, `baseKey` и счётчики realtime-доставки.

 ### 10.3. `DeleteMessage`

@@ -616,7 +616,10 @@ UI-следствие для клиента:
 - не отправляет realtime/push-уведомления клиентам;
 - не запускает повторный fan-out, чтобы не создавать циклы.

-Синхронизация настроек и DM выполняется одним периодическим процессом и через один последовательный WS-сеанс с peer. Выборка DM использует частичный индекс по `synced=false`.
+Синхронизация настроек и DM выполняется одним периодическим процессом и через
+один логический последовательный сеанс поверх постоянного WSS-пула. Закрытие
+этого логического сеанса не закрывает физическое соединение с peer. Выборка DM
+использует частичный индекс по `synced=false`.

 В текущей реализации межсерверная авторизация DM ещё не включена. Принимающий сервер проверяет, что сам является access-сервером `ownerLogin`, и всегда проверяет пользовательские подписи signed-блоков.