Files
utun2/task.txt
T
evgeny 38c9f229bc stcp: ed25519 pubkey exchange in handshake, fix instance destroy segfault, fix chat_tcp_test
- u_async.c: process immediate_queue BEFORE epoll_wait in uasync_poll
- stcp_link.c: defensive NULL etcp_conn/etcp_link in stcp_link_close
- utun_instance.c: move stcp_server_list_destroy_all to Phase J (before ETCP),
  add deferred drain in both Phase J and L
- stcp.h/c: STCP_HS_ENC_CLIENT 6→38, STCP_HS_ENC_SERVER 7→39,
  exchange ed25519_pubkey in both handshake directions
- etcp_connections.c: copy peer_ed25519 from STCP to ETCP_CONN in
  etcp_link_enter_ready_tcp; guard link->etcp in tcp_link_close_cb
- chat_sync.c: fix lk->conn NULL dereference for TCP links
- test_stcp.c: update stcp_server_create/stcp_client_connect callsites
- tools/chat_tcp_test: change transport udp→tcp
2026-08-07 00:48:27 +03:00

80 lines
4.6 KiB
Plaintext
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
## Текущая задача: отладка 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` (доступа нет)