# Межсерверное соединение и `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;
- размеры очередей по приоритетам;
- успешные, ошибочные и просроченные запросы;
- последнюю ошибку.

Агрегированное состояние периодически записывается в серверный лог. Отдельная
публичная операция метрик на этом этапе не добавляется.