Починить межсерверную репликацию личных сообщений

Репликация личных сообщений между серверами теперь работает корректно.
2026-08-25 19:31:38 +04:00
parent 7d929e626e
commit 3a5851939e
21 changed files with 267 additions and 513 deletions
@@ -32,6 +32,7 @@
 | `CloseActiveSession` | `03_Session_Management_API.md` | закрытие активной сессии |
 | `AddBlock` | `04_Add_Block_to_Blockchain_API.md` | добавление блока в блокчейн |
 | `GetBlockchainBlock` | `04_Add_Block_to_Blockchain_API.md` | чтение одного блока блокчейна |
+| `ServerHello` | `16_Server_Connection_Pool_API.md` | объявление server-to-server соединения и возможностей peer без криптографической проверки |
 | `Ping` | `05_Technical_Requests_API.md` | keep-alive |
 | `GetServerInfo` | `05_Technical_Requests_API.md` | публичная информация о сервере |
 | `ListBlockchainHeads` | `05_Technical_Requests_API.md` | список heads всех локальных блокчейнов |
@@ -79,6 +80,7 @@

 - `ReceiveOutcomingMessage` зарегистрирован как алиас того же handler/request-класса, что и `SendMessagePair`, и сохраняет прежний межсерверный payload.
 - Межсерверные DM-операции пока доверяют `sourceServerLogin`; отдельная межсерверная авторизация запланирована позднее.
+- `ServerHello` пока принимает заявленный `serverLogin` на доверии и не является криптографической аутентификацией.
 - Отдельных HTTP endpoints для DM-файлов сейчас нет.
 - Классы `Net_MarkChannelMessagesSeen_*` существуют в коде, но операция `MarkChannelMessagesSeen` не зарегистрирована в `JsonHandlerRegistry`, поэтому в публичный список API не входит.
 - HTTP debug endpoints из `src/main/java/server/debug/` не входят в этот индекс WebSocket `op`; они описаны отдельно в `13_HTTP_Debug_API.md`.
@@ -83,7 +83,10 @@

 ## 5. Синхронизация

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

 - локальная запись создаётся с `synced=false`, если её ещё не подтвердил второй сервер;
 - если запись пришла с другого сервера, она сохраняется сразу как `synced=true`;
@@ -183,16 +183,20 @@ Full resync запускается только тогда, когда:

 Настройка влияет именно на этап подготовки отсутствующей локальной цепочки во время periodic sync.

-## 5. Возможное развитие server-to-server транспорта
+## 5. Реализованный постоянный server-to-server транспорт

-Этот раздел не описывает текущую DM-доставку. DM уже использует короткие one-shot WebSocket-вызовы, indexed outbox и ACK. Ниже остаётся возможное развитие постоянного транспорта и server-auth.
+Этот раздел не меняет текущую семантику DM, settings и blockchain. Он описывает
+единый постоянный WSS-транспорт, через который выполняются уже существующие операции.

 ### 5.1 Межсерверное соединение

- Серверы устанавливают постоянное WebSocket-соединение друг с другом.
+- Серверы устанавливают постоянное исходящее WebSocket-соединение друг с другом.
 - Адрес партнёра определяется по `server_address` из его Solana PDA.
- Аутентификация: подпись Ed25519 корневым ключом сервера (`root_key` из PDA).
- При разрыве — переподключение с экспоненциальным backoff.
+- После подключения отправляется `ServerHello` с `serverLogin`, версией протокола и capabilities.
+- На текущем этапе `serverLogin` принимается на доверии; подпись Ed25519 корневым ключом сервера отложена.
+- При разрыве выполняется переподключение с jitter/backoff до 60 секунд.
+- После 120 секунд отсутствия полезного трафика отправляется WebSocket ping; pong ожидается 15 секунд.
+- Один физический канал переиспользуют DM, настройки и blockchain.

 ### 5.2 Доставка новых данных (push)

@@ -246,19 +250,21 @@ Full resync запускается только тогда, когда:
 | Плановый blockchain sync при старте + каждые 12 часов | ✅ Реализовано |
 | Обход Solana RPC через `sync.importUserProfileFromPartner.enabled` | ✅ Реализовано |
 | Обычный `AddBlock` через `tmp_bch`/`write_check`/`write_pending` | ✅ Реализовано |
-| Межсерверный постоянный WebSocket-канал | Нужна реализация |
+| Межсерверный постоянный WebSocket-канал | ✅ Реализован общий `ServerConnectionPool` |
 | Асинхронная доставка DM на access-серверы получателя | ✅ Реализовано |
 | Retry DM до 1 часа + UI-state | ✅ Реализовано |
 | Репликация DM на второй access-сервер по `synced` | ✅ Реализовано |
 | Read-only `GetDmDeliveryStatus` | ✅ Реализовано |
-| Push блоков блокчейна партнёрам | ✅ Реализована базовая one-shot версия |
+| Push блоков блокчейна партнёрам | ✅ Выполняется через постоянный WSS-пул |
 | Periodic backfill отсутствующего хвоста | ✅ Реализовано |
 | Разрешение рассинхрона / divergence | ✅ Реализована базовая full-resync схема во время periodic sync |
 | Startup recovery по `*.resync_pending` marker-file | ✅ Реализовано |
 | Маршрутизация DM через один/два `access_servers` | ✅ Реализовано |
 | Криптографическая server-to-server авторизация DM | Нужна реализация |

-Текущая версия сервера умеет синхронизацию блокчейнов и DM. Постоянные server-to-server соединения не требуются для текущей one-shot WS-реализации; отдельной будущей задачей остаётся криптографическая авторизация DM-вызовов.
+Текущая версия сервера использует постоянный WSS-пул для существующих
+server-to-server JSON-операций. Отдельной будущей задачей остаётся
+криптографическая авторизация server-to-server вызовов.

 Следующие отдельные шаги после текущего этапа:
 - отдельно проверить full-resync и startup-recovery на реальном тестовом прогоне после ручного удаления БД/файлов.