50 lines
5.4 KiB
Markdown
50 lines
5.4 KiB
Markdown
# Архитектура NNNet
|
||
|
||
## Слои
|
||
- BLE Transport: сканирование, реклама, соединения, обмен пакетами.
|
||
- Mesh Layer: маршрутизация, TTL, дедупликация, ACK, ретрансляция профильных пакетов.
|
||
- Messaging Layer: список чатов, отдельный экран диалога, статусы доставки, история.
|
||
- Storage Layer: Room для локального хранения сообщений, очереди и профилей.
|
||
- Diagnostics Layer: карта сети и журнал пакетов, построенные на данных `Room`.
|
||
- Delivery Layer: retry queue, ACK timeout, повторные отправки из фонового сервиса.
|
||
- Update Layer: `version.json`, changelog и ручная/автоматическая проверка обновлений клиента.
|
||
- Profile Layer: локальный профиль пользователя, `username` как основной идентификатор, кэш профилей из mesh-сети, разрешение `username <-> peerId`, lease на 14 дней и recovery bundle для переноса идентичности.
|
||
|
||
## Пользовательский сценарий
|
||
- Главный экран показывает список чатов в стиле Telegram.
|
||
- Верхний статусный блок переключает mesh-сеть между состояниями `В сети` и `Не в сети`.
|
||
- Слева в шапке показывается общее количество известных устройств в mesh.
|
||
- В меню `три точки` доступны `Карта сети`, `Пакеты` и `Настройки`, отдельный debug-лог из пользовательского интерфейса убран.
|
||
- Отправка сообщений доступна только из экрана конкретного диалога.
|
||
- В настройках пользователь редактирует свой профиль, ищет другие профили по `username`, имени, фамилии, полному имени и `peerId`, а также может экспортировать или импортировать recovery bundle.
|
||
- В настройках доступны режим карты сети и экран журнала пакетов.
|
||
- Поток обновления: `version.json` -> скачивание APK в `cache/updates` -> остановка mesh -> запуск системной установки через `FileProvider` и `Intent.ACTION_VIEW`.
|
||
|
||
## Топология сети
|
||
- Выделенный сервер или хост для работы mesh не нужен.
|
||
- Все узлы равноправны: каждый телефон может быть источником, получателем и ретранслятором.
|
||
- Сеть не рассчитана на бесконечное число пользователей. Масштаб ограничивается радиусом BLE, количеством соседних соединений, частотой ретрансляции и ограничениями Android по энергии и фону.
|
||
- Профильные данные передаются отдельными mesh-пакетами и кэшируются на устройствах. Это даёт распределённый каталог пользователей без центрального сервера, но актуальность данных зависит от распространения пакетов по сети.
|
||
- Каждый профильный пакет содержит подписанный claim владельца: `username`, имя, описание, `peerId`, `updatedAt`, `leaseExpiresAt`, `publicKey`, `signature`.
|
||
- Захват чужого `username` блокируется проверкой подписи и активного lease. Если владелец не появляется в сети 14 дней, claim считается протухшим и `username` можно занять заново.
|
||
- Перенос на новый телефон делается через recovery bundle с ключами владельца: после импорта тот же пользователь может опубликовать прежний `username` уже с новым `peerId`.
|
||
- Карта сети строится как относительная топология связей, а не как GPS/геометрическая карта здания. Высота этажей пока не моделируется.
|
||
|
||
## Сетевой пакет (черновик)
|
||
```json
|
||
{
|
||
"messageId": "uuid",
|
||
"senderId": "device-or-user-id",
|
||
"targetId": "user-or-group-id",
|
||
"ttl": 6,
|
||
"timestamp": 0,
|
||
"type": "message|ack|presence|profile",
|
||
"payload": "base64-or-json"
|
||
}
|
||
```
|
||
|
||
## Ближайшие шаги
|
||
1. Укрепить transport: фрагментация крупных пакетов и более надёжный reconnect.
|
||
2. Ввести шифрование payload и подпись уже не только профильных, но и message-пакетов.
|
||
3. Добавить инструментальные BLE-тесты на нескольких устройствах и полевой прогон.
|