aidar/SHiNE-server
SHA256
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Удалён AckIncomingMessage и обновлена документация доставки

Browse Source
This commit is contained in:
AidarKC
2026-05-02 17:02:57 +03:00
parent c44d755ce0
commit b05da86197
6 changed files with 19 additions and 54 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Логика_доставки_почты.md
+17
View File
@@ -16,6 +16,23 @@
5. Если пара реально добавилась в БД, сервер запускает realtime-доставку в активные сессии целевых пользователей.
6. Если это дубль, дальнейшая доставка не выполняется (повтор не разгоняется).
## Как сообщение доходит до клиента (WS + WebPush)
1. После успешной записи сервер пытается доставить сообщение во все активные сессии `targetLogin`.
2. Для каждой сессии сервер сначала создаёт/проверяет запись доставки в `signed_message_session_delivery` (pending).
3. Если сессия онлайн, сервер шлёт `SignedMessageArrived` по WebSocket.
4. Если сессия офлайн и тип сообщения входящий текст (`TYPE_INCOMING_TEXT`), сервер пробует WebPush (если у сессии сохранены `endpoint/p256dh/auth`).
5. При следующем логине/переподключении сервер дочитывает pending-сообщения и повторно отправляет их в эту сессию как backlog.
## Подтверждение доставки (ACK)
- Используется метод `AckSessionDelivery`.
- Клиент отправляет ACK после обработки `SignedMessageArrived` с `messageKey`.
- Сервер помечает `(messageKey, sessionId)` как `delivered=1`, и это сообщение перестаёт быть pending для этой сессии.
### Важно про безопасность ACK
- `AckSessionDelivery` требует авторизованную WS-сессию (`ctx.isAuthenticatedUser()`).
- `sessionId` берётся сервером из текущего `ConnectionContext`, а не из payload запроса.
- Поэтому подтвердить доставку «просто зная messageKey/sessionId» без авторизованной сессии нельзя.
## Почему допускаются дубли сети
- В модели с несколькими серверами возможны повторные пересылки одного и того же сообщения.
- Дедупликация делается на уровне БД по ключам записи.