80 lines
4.6 KiB
Plaintext
80 lines
4.6 KiB
Plaintext
## Текущая задача: отладка merkle sync в chatgui
|
||
|
||
### Контекст
|
||
|
||
Две инстанции chatgui обмениваются мемберами (участниками) каналов через merkle sync.
|
||
Одна на Linux (node `41eab6811e3ff67b`), вторая на Windows (node `32a3a1ee5625ceb9`).
|
||
|
||
### Что уже исправлено (vetka topo_upd)
|
||
|
||
1. **`conn_mgr.c:276`** — убрано требование `links_up` при поиске существующего коннекта.
|
||
Раньше второй `conn_mgr_connect_node` (для второй группы/канала) не находил первый коннект
|
||
потому что тот был в handshake (links_up=0) и создавал дублирующий линк → два init-таймера
|
||
→ два потока INIT-пакетов → бесконечный цикл реинициализации ETCP.
|
||
|
||
2. **`etcp_connections.c:insert_link_queue`** — детект коллизии адреса: если адрес уже занят
|
||
ДРУГИМ коннектом → жирная ошибка + return -1 (вместо молчаливой замены).
|
||
|
||
3. **`etcp.c:etcp_conn_set_peer_node_id`** — детект коллизии peer_id: если key уже занят
|
||
другим коннектом → жирная ошибка + return (не переиндексировать).
|
||
|
||
4. **`merkle_sync.c`** — исправлен формат сообщений:
|
||
- Отправитель клал type ПЕРЕД ch_len+ns: `[svc][TYPE][ch_len][ns]...`
|
||
- Получатель (`_recv_cb`) ожидал `[svc][ch_len][ns][TYPE]...` (как у chat_sync)
|
||
- Переставлены байты в `_send_hashes`, `_send_batch`, MSG_REQUEST builder
|
||
- Результат: handle_hashes/handle_request/handle_batch начали реально получать сообщения
|
||
|
||
5. **`merkle_sync.c`** — `_handle_batch` теперь вызывает `_session_done(s, MT_OK)` после
|
||
обработки всех терминальных бакетов. До этого сессия никогда не завершалась,
|
||
таймер истекал → retry → к тому моменту соединение уже отваливалось.
|
||
|
||
### Текущее состояние
|
||
|
||
Merkle sync обменивается сообщениями и завершает сессии (`session SYNCED` в логах).
|
||
Но данные мемберов не совпадают: Linux имеет 3 мембера в канале, Windows — 2.
|
||
|
||
### Найденная проблема (исследуется)
|
||
|
||
В логах `handle_batch` показывает `len=7` для обоих каналов с обеих сторон.
|
||
Это означает что в BATCH-сообщении данные мемберов = всего 2 байта (count=0).
|
||
|
||
При этом `merkle_tree_hash` показывает НЕнулевой bitmap (00008000) → `update_bucket_hash`
|
||
находит мемберов в бакете. Но `get_items` для того же бакета возвращает 0 записей.
|
||
|
||
**Гипотеза:** `update_bucket_hash` и `get_items` используют разную логику фильтрации
|
||
для одного и того же level/prefix → SQL запрос в `get_items` не находит мемберов.
|
||
|
||
Файлы: `tools/chatgui/transport/member_sync.c` функции `_member_update_bucket_hash` и `_member_get_items`.
|
||
|
||
### Данные из БД (Linux)
|
||
|
||
Канал 17611191138590969914: 3 мембера
|
||
- 4749809422690154107 (0x41eab6811e3ff67b — Linux self)
|
||
- 3648938168119840441 (0x32a3a1ee5625ceb9 — Windows peer)
|
||
- 5749221071098079620 (0x4fc9561a7dfde984 — третий узел)
|
||
|
||
Канал 10175004475814804132: 2 мембера
|
||
- 3648938168119840441 (0x32a3a1ee5625ceb9)
|
||
- 4749809422690154107 (0x41eab6811e3ff67b)
|
||
|
||
Merkle tree для канала 176111...:
|
||
```
|
||
level=1 prefix=0x4000000000000000 member_count=1 hash=F612B771...
|
||
level=2 prefix=0x41E0000000000000 member_count=1 hash=F612B771...
|
||
level=3 prefix=0x41EA000000000000 member_count=1 hash=F612B771...
|
||
level=4 prefix=0x41EAB00000000000 member_count=1 hash=F612B771...
|
||
level=5 prefix=0x41EAB68000000000 member_count=1 hash=F612B771...
|
||
```
|
||
|
||
### Логи
|
||
|
||
Linux: `/home/vnc1/proj/utun3/tools/chatgui/build/chatgui.log`
|
||
Windows: `/home/vnc1/proj/utun3/tools/chatgui/build/chatgui2.log`
|
||
|
||
Конфиг: `db_sync=debug` включён.
|
||
|
||
### БД
|
||
|
||
Linux: `/home/vnc1/proj/utun3/tools/chatgui/build/chat_data/chats.db`
|
||
Windows: `C:/ARM/_uTun/utun2/tools/chatgui/build/chat_data/chats.db` (доступа нет)
|