12 changed files with 85 additions and 23 deletions
@ -0,0 +1,79 @@
|
||||
## Текущая задача: отладка 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` (доступа нет) |
||||
Loading…
Reference in new issue