You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
79 lines
4.6 KiB
79 lines
4.6 KiB
## Текущая задача: отладка 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` (доступа нет)
|
|
|