SHA256
AidarKC
8a0275d962
Что сделано: вычистили неиспользуемый user-settings sync/DM sync хвост, сохранили сборку, обновили bundle.sh так, чтобы gradle-wrapper.jar всегда попадал в архив. Проверено: compileJava и deploy на t2 (server + UI). Не проверяли: полные интеграционные сценарии, ручные UI-флоу и продовый деплой.
107 lines
4.2 KiB
Markdown
107 lines
4.2 KiB
Markdown
# Межсерверное соединение и `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 и signed deletes |
|
||
| `NORMAL` | прочие межсерверные запросы |
|
||
| `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;
|
||
- размеры очередей по приоритетам;
|
||
- успешные, ошибочные и просроченные запросы;
|
||
- последнюю ошибку.
|
||
|
||
Агрегированное состояние периодически записывается в серверный лог. Отдельная
|
||
публичная операция метрик на этом этапе не добавляется.
|