Browse Source
- fix HTTP_STATE_RELAY == SOCKS_STATE_CONNECTING enum collision (relay data dropped) - fix wrong waiter cancel (etcp_router_waiter_cancel -> etcp_router_cancel_send_ready) - add backpressure retry timer, restore lost queue_resume_callback, defer FIN on pending tx_buf - async_dns: /etc/hosts fast-path + hosts loading (avoid 4s DNS timeout for localhost)v2
evgeny
4 weeks ago
7 changed files with 298 additions and 528 deletions
@ -1,115 +0,0 @@ |
|||||||
# Задача: продолжить исправление TCP-proxy (крупные файлы через транзит) |
|
||||||
|
|
||||||
Продолжение незавершённой работы. Читай целиком, прежде чем что-то менять. |
|
||||||
|
|
||||||
## 1. Что уже сделано (НЕ переделывать) |
|
||||||
|
|
||||||
Унифицирован формат доставки сервисных кодограмм роутером. Раньше сервисы определяли |
|
||||||
источник через `conn->peer_node_id`, что ломало транзит (при промежуточном узле это был |
|
||||||
id промежуточного, а не реального клиента). |
|
||||||
|
|
||||||
Теперь роутер доставляет сервисам единый формат: |
|
||||||
|
|
||||||
``` |
|
||||||
[svc_id(1)][src_node_id(8)][dst_node_id(8)][payload...] |
|
||||||
``` |
|
||||||
|
|
||||||
где src/dst — реальные end-to-end узлы из SVC_ROUTE заголовка. |
|
||||||
|
|
||||||
Ключевые константы в `src/routing_layer/etcp_router.h`: |
|
||||||
`ROUTER_SVC_SRC_OFF=1`, `ROUTER_SVC_DST_OFF=9`, `ROUTER_SVC_PAYLOAD_OFF=17`, `ROUTER_SVC_HDR_SIZE=17`. |
|
||||||
|
|
||||||
Изменённые файлы (все в некоммиченном состоянии, `git status`): |
|
||||||
- `src/routing_layer/etcp_router.{h,c}` — `router_deliver` + `router_deliver_loopback` + CLOSE/RESTART |
|
||||||
- `src/proxy/tcp_proxy_server.{h,c}` — recv +8→+16 сдвиг, `src_node_id` из `dgram[1..8]` |
|
||||||
- `src/proxy/tcp_proxy_client.{h,c}` — recv сдвиг + счётчики `bytes_to_exit/from_exit/bp_count` |
|
||||||
- `src/proxy/udp_proxy.{h,c}`, `src/proxy/icmp_proxy.{h,c}` — сдвиг + убран встроенный node_id |
|
||||||
- `src/nat_transport.c` — убран встроенный node_id |
|
||||||
- `src/routing_layer/routing.c`, `conn_mgr_core.c` — сдвиг |
|
||||||
- `src/media_delivery/media_delivery.c` — сдвиг + `from_node` из `dgram[1..8]` |
|
||||||
- `tools/chatgui/transport/utun_node.cpp` — сдвиг |
|
||||||
- тесты `tests/test_etcp_router*.c`, `test_udp_proxy.c`, `test_icmp_proxy.c`, `test_nat_transport.c` |
|
||||||
- `tests/tcp_proxy_full/` — добавлен `intermediate.conf` (3-узловая топология), обновлены `client.conf`/`exit.conf`/`run_test.sh` |
|
||||||
|
|
||||||
**Статус проверки: `./check.sh` = 73 passed, 0 failed, 1 skipped.** Форматная часть ВЕРНА. |
|
||||||
|
|
||||||
## 2. Что осталось (собственно задача) |
|
||||||
|
|
||||||
Интеграционный тест прокси `tests/tcp_proxy_full/run_test.sh` (нужен sudo) — крупные |
|
||||||
передачи НЕ проходят. Проверено: проблема **НЕ в формате и НЕ в транзите** — прямой |
|
||||||
2-узловой прогон падает идентично. Это предсуществующая проблема прокси/lwIP. |
|
||||||
|
|
||||||
Результат `sudo ./tests/tcp_proxy_full/run_test.sh`: |
|
||||||
- `idle` (32 КБ) — PASS |
|
||||||
- `half_close` (64 КБ) — 64280/65536 (почти, теряется хвост) |
|
||||||
- `basic_1mb` (1 МБ), `concurrent_*`, `stress` — FAIL (timeout) |
|
||||||
|
|
||||||
## 3. Диагноз (уже установлен по логам) |
|
||||||
|
|
||||||
Пропускная способность ~24 КБ/с (1 пакет 1460 байт за ~60 мс). Для 1 МБ это ~43 с → таймаут 10 с. |
|
||||||
|
|
||||||
Цепочка (видна в добавленных логах `PROXY BP *` и `SEND_Q_ACKED`): |
|
||||||
1. Клиент быстро шлёт 320 пакетов (initial burst ~33 МБ/с). |
|
||||||
2. Роутерный `send_q` переполняется (`router_send_q: FULL count=64`) → `etcp_route_send` возвращает -1. |
|
||||||
3. Прокси в `tcp_proxy_client_recv_cb` ставит одиночный `tx_buf` и **сбрасывает** дальнейшие данные |
|
||||||
(`if (pc->tx_buf) { pbuf_free(p); return; }`) — лог `PROXY BP drop`, без `tcp_recved` → окно lwIP схлопывается. |
|
||||||
4. Клиент вырождается в режим «1 пакет за ~60 мс». |
|
||||||
5. ~60 мс = таймер lwIP: `ctx->tmr_interval_ms = TCP_TMR_INTERVAL / 4` = 62.5 мс (`src/lwip_tcp/lwip_tcp.c:106`). |
|
||||||
В режиме «пакет-за-пакетом» lwIP не шлёт ACK сразу (порог `TCP_WND_UPDATE_THRESHOLD = TCP_WND/4 = 2920` |
|
||||||
не набирается за 1 пакет), и отложенный ACK уходит только по `tcp_fasttmr` раз в 62.5 мс. |
|
||||||
|
|
||||||
Триггер — сброс данных при backpressure в прокси (`tcp_proxy_client.c`), НЕ lwIP. |
|
||||||
|
|
||||||
## 4. Ограничения (ВАЖНО) |
|
||||||
|
|
||||||
- **В `src/lwip_tcp/` ничего НЕ править без явного согласования пользователя. Разрешён только debug-лог.** |
|
||||||
- Правки исходников только через Edit tool (никакого sed для массовых замен). |
|
||||||
- Ошибки/нештатные ветки — обязательно `DEBUG_ERROR/DEBUG_WARN`. |
|
||||||
- Логи информативные, без спама. Debug-категории: `proxy`, `etcp_route`. |
|
||||||
- Перед сборкой `make clean`. |
|
||||||
|
|
||||||
## 5. План продолжения |
|
||||||
|
|
||||||
Шаг 1 (диагностика, закрыть пробел — по желанию, уже почти доказано): |
|
||||||
- Добавить в lwIP только DEBUG-лог (разрешено): в `tcp_fasttmr` — счётчик отложенных ACK; в `tcp_recved` — `rcv_wnd`. |
|
||||||
- В прокси (`tcp_proxy_client.c`, НЕ lwIP) в момент `BP drop` лог `pcb->rcv_wnd`. |
|
||||||
- Подтвердить, что 62.5 мс — это отложенный ACK. |
|
||||||
|
|
||||||
Шаг 2 (фикс, требуется согласование — предложи пользователю): |
|
||||||
- **Вариант A (предпочтительно, НЕ lwIP):** в прокси заменить одиночный `tx_buf` + сброс на очередь с backpressure |
|
||||||
(буферизовать все пакеты во время backpressure, не сбрасывать; `tcp_recved` вызывать по мере отправки). |
|
||||||
Тогда окно закрывается плавно, OS TCP не сваливается в congestion avoidance, деградации нет. |
|
||||||
Смотри `struct tcp_proxy_client_conn` в `tcp_proxy_client.h` (сейчас: `tx_buf`/`tx_len`/`tx_waiter`). |
|
||||||
Для образца очереди с backpressure смотри `src/proxy/tcp_proxy_server.c` (там `read_queue` + `pause_waiter`). |
|
||||||
- **Вариант B (lwIP, только по согласованию):** уменьшить `tmr_interval_ms` (`TCP_TMR_INTERVAL/4` → чаще), |
|
||||||
либо повысить `TCP_WND_UPDATE_THRESHOLD`/`TCP_WND`, чтобы ACK слался сразу. |
|
||||||
|
|
||||||
Шаг 3 (почистить тестовую обвязку): |
|
||||||
- В `tests/tcp_proxy_full/*.conf` сейчас включены отладочные уровни (`etcp_route=trace`, `proxy=trace`) — |
|
||||||
перед коммитом вернуть к разумным (`etcp_route=debug`/`proxy=debug` или `error`). |
|
||||||
- Решить: оставить добавленные в `tcp_proxy_client.c` счётчики/BP-логи или вычистить. |
|
||||||
- В `run_test.sh` тайминги `elapsed` через `date +%s%3N` дают мусор в этой среде — поправить (например `date +%s` |
|
||||||
без миллисекунд, или `SECONDS`). Stress-таймаут `60s` можно уменьшить до ~15-20s. |
|
||||||
|
|
||||||
## 6. Сборка и тест |
|
||||||
|
|
||||||
```bash |
|
||||||
./build.sh --full -j4 # или make -j4 (после make clean) |
|
||||||
./check.sh # unit-тесты: должны остаться 73 passed |
|
||||||
cp src/utun utun # обновить корневой бинарник для run_test.sh! |
|
||||||
sudo ./tests/tcp_proxy_full/run_test.sh # интеграционный (нужен root/TUN/iptables) |
|
||||||
``` |
|
||||||
|
|
||||||
Важно: `run_test.sh` использует `UTUN_BIN="$SCRIPT_DIR/../../utun"` (корневой `utun`), а `make` собирает |
|
||||||
`src/utun`. После каждой пересборки делать `cp src/utun utun`. |
|
||||||
|
|
||||||
## 7. Как быстро убедиться, что фикс помог |
|
||||||
|
|
||||||
Прогнать `basic_1mb` и смотреть лог клиента `tests/tcp_proxy_full/log/client_utun.log`: |
|
||||||
- ДО фикса: `PROXY BP drop` + `SEND_Q_ACKED` с интервалом ~60 мс. |
|
||||||
- ПОСЛЕ фикса: нет `BP drop`, интервал ACK ~10 мс, `basic_1mb` PASS. |
|
||||||
|
|
||||||
Полезные grep-и по логу клиента: |
|
||||||
``` |
|
||||||
grep -E "PROXY BP|SEND_Q_ACKED|PROXY FIN" client_utun.log |
|
||||||
``` |
|
||||||
@ -1,35 +0,0 @@ |
|||||||
План доработок |
|
||||||
[ ] продумать архитектуру репликации таблицы узлов группы |
|
||||||
[ ] добавить узлы хелперы (для проксирования трафика) |
|
||||||
|
|
||||||
|
|
||||||
Категории узлов: |
|
||||||
- узлы без нат [] |
|
||||||
- узлы с nat [restricted] |
|
||||||
|
|
||||||
Узлы за nat сами подключаются к прямым |
|
||||||
|
|
||||||
Узлы за eim nat сами подключаются и сообщают обновление адреса. |
|
||||||
|
|
||||||
Прямые узлы должны сами должны объединиться в сеть следующим образом: |
|
||||||
|
|
||||||
Инит: база содержит RTT по узлам. |
|
||||||
выбираем n=16 узлов с минимальным rtt. запускаем подключение к ним. |
|
||||||
синхронизируем роутинг таблицу с ними (обмен маршрутами должен инициироваться сразу после подключения). |
|
||||||
при потере связи узлы через nat должны найти альтернативы. |
|
||||||
|
|
||||||
в таблице обновляется |
|
||||||
|
|
||||||
как обмен завершен |
|
||||||
|
|
||||||
Нужно собирать и обновлять информацию о том |
|
||||||
- к каким публичным нодам подключены nat узлы. |
|
||||||
|
|
||||||
- метрика доступности узла - как давно не менялся ip:port - собираем с клиентов. вместе с рейтигном (каждый клиент по узлу фолрмирует свой рейтинг кандидата в суперузлы и отправляет подписанный рейтинг узлу) |
|
||||||
рейтинг включает: |
|
||||||
- число разных часов фигурирует в замерах |
|
||||||
- число разных дат фигурирует в замерах |
|
||||||
- гистограмма rtt: 0-2ms, 2-4ms, 4-6ms, 6-10ms, 10-13ms, 14-18ms, 18-25ms, 25-35ms, 35-50ms, 50-75ms, 75-100ms, 100-130ms, 130-160ms, 160+ms |
|
||||||
- гистограмма потерь: 0-1% 1-2% 2-4% 4-8% >8% (обновляется каждый час) |
|
||||||
|
|
||||||
Сделать подключение к группе |
|
||||||
@ -1,292 +0,0 @@ |
|||||||
# DB Sync Protocol v2 — Техническое задание |
|
||||||
|
|
||||||
## 1. Проблема |
|
||||||
|
|
||||||
chain_hash = SHA256(prev_chain_hash || id || ts || datahash) — хеш-цепочка, где хеш каждой записи зависит от предыдущей. |
|
||||||
|
|
||||||
`db_record_insert` (db_sync.c:341-463) при вставке записи в середину сортированного порядка делает каскадный пересчёт chain_hash всех последующих записей — O(N). При двустороннем обмене PUSH'ами получается O(N²). |
|
||||||
|
|
||||||
## 2. Решение |
|
||||||
|
|
||||||
**Разделить два концерна:** |
|
||||||
- **Сравнение при синхронизации** — перейти на `datahash` (первые 8 байт SHA256(data), позиционно-независимый). Не требует каскада. |
|
||||||
- **Целостность цепочки** — `chain_hash` остаётся в схеме БД, но используется только для однократной стартап-проверки и диагностики. |
|
||||||
|
|
||||||
**Синхронизация:** per-peer позиционная (`synced_pos`). При PUSH каскад не делается. При SEND_DATA батч-вставка + один каскад после батча. |
|
||||||
|
|
||||||
## 3. Модель данных |
|
||||||
|
|
||||||
### 3.1. SI_PEER |
|
||||||
|
|
||||||
```c |
|
||||||
struct SI_PEER { |
|
||||||
uint64_t node_id; |
|
||||||
uint32_t synced_pos; // последняя подтверждённо общая позиция (0-based index) |
|
||||||
uint8_t sync_state; // 0=not_synced, 1=syncing, 2=synced |
|
||||||
}; |
|
||||||
``` |
|
||||||
|
|
||||||
- `synced_pos` = индекс последней записи в глобальном порядке `ORDER BY timestamp, datahash`, для которой chain_hash (а после v2 — datahash) подтверждённо совпадает у обоих пиров. |
|
||||||
- При PUSH-вставке записи на позицию P, для всех peer'ов у которых `synced_pos >= P`: `synced_pos = P - 1`. |
|
||||||
- При SEND_DATA: `synced_pos = from + received_count - 1`. |
|
||||||
|
|
||||||
### 3.2. Схема БД (без изменений) |
|
||||||
|
|
||||||
```sql |
|
||||||
CREATE TABLE "db_sync_<name>_<id>" ( |
|
||||||
timestamp INTEGER NOT NULL, |
|
||||||
datahash INTEGER NOT NULL, |
|
||||||
id INTEGER NOT NULL, |
|
||||||
chain_hash BLOB NOT NULL, |
|
||||||
author INTEGER NOT NULL, |
|
||||||
flags INTEGER NOT NULL DEFAULT 0, |
|
||||||
data BLOB, |
|
||||||
author_signature BLOB, |
|
||||||
delivered_peers INTEGER NOT NULL DEFAULT 0, |
|
||||||
delivery_chain TEXT NOT NULL DEFAULT '', |
|
||||||
PRIMARY KEY (timestamp, datahash) |
|
||||||
); |
|
||||||
``` |
|
||||||
|
|
||||||
## 4. Wire-формат |
|
||||||
|
|
||||||
### 4.1. Сообщения, которые меняются |
|
||||||
|
|
||||||
#### INIT_SYNC |
|
||||||
|
|
||||||
``` |
|
||||||
Было: [type:1][count:4][last_chain_hash:32] = 37 байт |
|
||||||
Стало: [type:1][count:4] = 5 байт |
|
||||||
``` |
|
||||||
|
|
||||||
#### INIT_RESP |
|
||||||
|
|
||||||
``` |
|
||||||
Было: [type:1][tp:4][chain_at_tp:32][sc:1][(pos:4,chain_hash:32)*sc] |
|
||||||
Стало: [type:1][tp:4][dh_at_tp:8] [sc:1][(pos:4,dh:8)*sc] |
|
||||||
|
|
||||||
dh_at_tp — datahash на позиции tp (8 байт вместо 32) |
|
||||||
sparse — datahash вместо chain_hash (8 байт на элемент вместо 32) |
|
||||||
|
|
||||||
При sc=0 (exact match): длина 1+4+8+1 = 14 байт (было 37) |
|
||||||
При sc=16 sparse: длина 14 + 16*12 = 206 байт (было 37 + 16*36 = 613) |
|
||||||
``` |
|
||||||
|
|
||||||
#### SYNC_DONE |
|
||||||
|
|
||||||
``` |
|
||||||
Было: [type:1][count:4][last_chain_hash:32] = 37 байт |
|
||||||
Стало: [type:1][count:4][last_dh:8] = 13 байт |
|
||||||
``` |
|
||||||
|
|
||||||
### 4.2. Сообщения, которые НЕ меняются |
|
||||||
|
|
||||||
- **PUSH**: `[type:1][id:8][ts:8][dh:8][dlen:4][data][sig_len:1][sig]` — без изменений. `prev_ch` НЕ добавляется. |
|
||||||
- **ACK_PUSH**: `[type:1][dh:8][ts:8]` — без изменений. |
|
||||||
- **REFINE**: `[type:1][from:4][to:4][hc:1][(pos:4,dh:8)*hc]` — уже использует datahash, без изменений. |
|
||||||
- **SEND_DATA**: `[type:1][from:4][count:2][(id:8,ts:8,dh:8,dlen:4,data,sig_len:1,sig)*count]` — без изменений. |
|
||||||
- **ERROR**: `[type:1][code:1]` — без изменений. |
|
||||||
|
|
||||||
## 5. Новые/изменённые функции |
|
||||||
|
|
||||||
### 5.1. `db_cascade_from` |
|
||||||
|
|
||||||
```c |
|
||||||
static void db_cascade_from(struct DB_SYNC_INSTANCE* si, uint32_t from_pos); |
|
||||||
``` |
|
||||||
|
|
||||||
Выполняет каскадный пересчёт `chain_hash` для записей с позиции `from_pos` до конца таблицы. |
|
||||||
|
|
||||||
Алгоритм: |
|
||||||
1. BEGIN IMMEDIATE |
|
||||||
2. SELECT chain_hash записи на позиции `from_pos - 1` (или zero если from_pos = 0) как prev_ch |
|
||||||
3. SELECT id, timestamp, datahash от позиции from_pos до конца |
|
||||||
4. Для каждой: chain_hash = SHA256(prev_ch || id || ts || dh), UPDATE в БД, prev_ch = новый chain_hash |
|
||||||
5. COMMIT |
|
||||||
|
|
||||||
Выделяется из текущего кода `db_record_insert` (строки 412-451) в отдельную функцию. |
|
||||||
|
|
||||||
### 5.2. `db_record_insert` — новый параметр |
|
||||||
|
|
||||||
```c |
|
||||||
static int db_record_insert(struct DB_SYNC_INSTANCE* si, |
|
||||||
uint64_t id, uint64_t ts, uint64_t dh, |
|
||||||
const char* json, size_t jlen, |
|
||||||
const uint8_t* sig, size_t sig_len, |
|
||||||
int do_cascade); |
|
||||||
``` |
|
||||||
|
|
||||||
- `do_cascade=1` — после INSERT выполняется cascade (строки 412-451). Используется для локальных вставок. |
|
||||||
- `do_cascade=0` — без cascade. Используется для PUSH и SEND_DATA (каскад делается отдельно). |
|
||||||
|
|
||||||
### 5.3. `db_verify_chain` (стартап-проверка) |
|
||||||
|
|
||||||
```c |
|
||||||
static void db_verify_chain(struct DB_SYNC_INSTANCE* si); |
|
||||||
``` |
|
||||||
|
|
||||||
Вызывается один раз после `db_sync_instance_add` (перед инициацией sync с пирами). |
|
||||||
|
|
||||||
Алгоритм: |
|
||||||
1. Проход записей 0..N-1 в порядке `ORDER BY timestamp, datahash` |
|
||||||
2. Для каждой: chain_hash = SHA256(prev_ch || id || ts || dh) |
|
||||||
3. Сравнить с хранимым в БД |
|
||||||
4. При первом расхождении на позиции P: пересчитать цепочку от P до конца через `db_cascade_from(si, P)`. Завершить. |
|
||||||
|
|
||||||
Сложность: O(N) SHA256, однократно при старте. |
|
||||||
|
|
||||||
### 5.4. `si_find_pos` (новая) |
|
||||||
|
|
||||||
```c |
|
||||||
static uint32_t si_find_pos(struct DB_SYNC_INSTANCE* si, |
|
||||||
uint64_t ts, uint64_t dh); |
|
||||||
``` |
|
||||||
|
|
||||||
Возвращает позицию (0-based index) записи с ключом `(ts, dh)` в глобальном порядке. Используется после вставки PUSH для корректировки `synced_pos`. |
|
||||||
|
|
||||||
### 5.5. `db_datahash_at` — уже существует (стр. 295) |
|
||||||
|
|
||||||
Возвращает `datahash` на заданной позиции. Используется для сравнения в INIT_SYNC/INIT_RESP/SYNC_DONE. |
|
||||||
|
|
||||||
## 6. Обработчики сообщений |
|
||||||
|
|
||||||
### 6.1. PUSH (`db_handle_push`) |
|
||||||
|
|
||||||
``` |
|
||||||
Было: db_record_insert(si, ..., /* cascade встроен */) |
|
||||||
Стало: db_record_insert(si, ..., /* do_cascade= */ 0) |
|
||||||
uint32_t pos = si_find_pos(si, ts, dh); |
|
||||||
for each peer: if peer->synced_pos >= pos: peer->synced_pos = pos - 1; |
|
||||||
``` |
|
||||||
|
|
||||||
### 6.2. INIT_SYNC (`db_handle_init_sync`) |
|
||||||
|
|
||||||
``` |
|
||||||
Изменения: |
|
||||||
- Принимает [count:4] вместо [count:4][chain_hash:32] (проверка len >= 5 вместо 36) |
|
||||||
- Сравнение: datahash вместо chain_hash (8 байт вместо 32) |
|
||||||
- sparse: datahash вместо chain_hash (8 байт на элемент вместо 32) |
|
||||||
- Размер sparse-элемента: 4(pos) + 8(dh) = 12 байт (было 4+32=36) |
|
||||||
- resp буфер: 4096 → достаточно (14 + 16*12 = 206 байт при max sparse) |
|
||||||
``` |
|
||||||
|
|
||||||
### 6.3. INIT_RESP (`db_handle_init_resp`) |
|
||||||
|
|
||||||
``` |
|
||||||
Изменения: |
|
||||||
- Принимает [tp:4][dh:8][sc:1][...] вместо [tp:4][ch:32][sc:1][...] |
|
||||||
- Проверка len >= 13 вместо 37 |
|
||||||
- Сравнение: datahash вместо chain_hash |
|
||||||
- Пустая БД пира: zero-хеш 8 байт вместо 32 |
|
||||||
- Sparse элементы: 12 байт вместо 36 |
|
||||||
- При совпадении: synced_pos = tp (в дополнение к sync_state = 2) |
|
||||||
``` |
|
||||||
|
|
||||||
### 6.4. SEND_DATA (`db_handle_send_data`) |
|
||||||
|
|
||||||
``` |
|
||||||
Стало: |
|
||||||
struct SI_PEER* sp = si_peer_find(si, src); |
|
||||||
uint32_t fix_from = sp ? sp->synced_pos : 0; |
|
||||||
|
|
||||||
for each record: |
|
||||||
db_record_insert(si, ..., /* do_cascade= */ 0); |
|
||||||
|
|
||||||
db_cascade_from(si, fix_from); |
|
||||||
|
|
||||||
sp->synced_pos = from + received_count - 1; |
|
||||||
sp->sync_state = 2; |
|
||||||
``` |
|
||||||
|
|
||||||
Каскад от `fix_from` (позиция, которая была synced ДО этого батча) гарантирует, что все chain_hash после этой точки пересчитаны — независимо от того, какие PUSH'и испортили их между синхронизациями. |
|
||||||
|
|
||||||
### 6.5. SYNC_DONE (`db_handle_sync_done`) |
|
||||||
|
|
||||||
``` |
|
||||||
Изменения: |
|
||||||
- Принимает [count:4][last_dh:8] вместо [count:4][last_chain_hash:32] (len >= 13 вместо 36) |
|
||||||
- Сравнение последнего datahash вместо chain_hash |
|
||||||
``` |
|
||||||
|
|
||||||
## 7. Механика многопировой синхронизации |
|
||||||
|
|
||||||
При наличии нескольких пиров с одинаковым `sync_state` (например, syncing=1) выбирается пир с минимальным `synced_pos` — у него самый старый общий префикс. После завершения его синхронизации выбор повторяется. |
|
||||||
|
|
||||||
Это гарантирует: двигаемся от самого старого несинхронизированного участка, не прыгая. Новые записи (в хвосте) синхронизируются последними. |
|
||||||
|
|
||||||
## 8. Полный сценарий: три участника A, B, C |
|
||||||
|
|
||||||
``` |
|
||||||
Начальное состояние: все пусты. |
|
||||||
|
|
||||||
=== Шаг 1. A создаёт R1 (ts=1000) === |
|
||||||
A: PUSH R1 → B, C. Все вставляют в конец, cascade 0. |
|
||||||
synced_pos = 0 у всех. |
|
||||||
|
|
||||||
=== Шаг 2. B создаёт R2 (ts=2000), C создаёт R3 (ts=1500) === |
|
||||||
B: [R1(1000), R2(2000)], PUSH R2 → A, C. |
|
||||||
A: R2 в конец. C: R2 в конец. |
|
||||||
C: [R1(1000), R2(2000)]? Нет — C создал R3(1500). |
|
||||||
C: [R1(1000), R3(1500)] локально, потом PUSH R2 → R2.ts=2000 → в конец. |
|
||||||
C: [R1(1000), R3(1500), R2(2000)] |
|
||||||
C: PUSH R3 → A, B. |
|
||||||
A: [R1(1000), R2(2000)] + R3(1500) → между R1 и R2: |
|
||||||
A: [R1, R3, R2] ← R3 в середину, cascade ПРОПУЩЕН |
|
||||||
B: [R1, R3, R2] ← аналогично |
|
||||||
|
|
||||||
synced_pos после PUSH R3 на A относительно B: |
|
||||||
A вставил R3 на поз.1 → synced_pos_B: было 1 → стало 0 |
|
||||||
(A считает, что совпадает с B только на позиции 0) |
|
||||||
|
|
||||||
=== Шаг 3. A инициирует sync с B (чемпион: min synced_pos) === |
|
||||||
A→B: INIT_SYNC [count=3] |
|
||||||
B→A: INIT_RESP [tp=min(3,3)-1=2, dh_at_tp=H2, sc=2, sparse:{(1,H3),(0,H1)}] |
|
||||||
A проверяет: A@2=R2→dh=H2✓, A@1=R3→dh=H3✓, A@0=R1→dh=H1✓ |
|
||||||
→ sync complete, synced_pos_B=2, sync_state=2 |
|
||||||
|
|
||||||
=== Шаг 4. Рестарт A === |
|
||||||
db_verify_chain: |
|
||||||
pos 0: R1.ch = SHA256(0||R1) ✓ |
|
||||||
pos 1: R3.ch = SHA256(R1.ch||R3) ✓ (посчитан при PUSH без cascade — корректен) |
|
||||||
pos 2: R2.ch = SHA256(R3.ch||R2) ✗ (STALE: был посчитан как SHA256(R1.ch||R2) до PUSH R3) |
|
||||||
→ расхождение на pos=2 → db_cascade_from(2): пересчёт R2.ch = SHA256(R3.ch||R2) ✓ |
|
||||||
|
|
||||||
=== Шаг 5. A, B, C активно обмениваются === |
|
||||||
Каждый PUSH: вставка без cascade. |
|
||||||
Периодические sync (по min synced_pos): SEND_DATA + один cascade от synced_pos. |
|
||||||
synced_pos растёт. |
|
||||||
``` |
|
||||||
|
|
||||||
## 9. Что НЕ трогать |
|
||||||
|
|
||||||
- `db_sync_insert_signed` — локальная вставка. ts всегда монотонный, запись в конец, `do_cascade=1`, каскад всегда 0 строк. |
|
||||||
- TTL cleanup (`db_sync_instance_ttl_cb`) — удаление старых записей. Нужен cascade после удаления (уже существующая логика, не меняется). |
|
||||||
- ACK_PUSH, ERROR, REFINE — без изменений. |
|
||||||
- Схема БД — без изменений. |
|
||||||
- `etcp_bind`/эпилог — без изменений. |
|
||||||
|
|
||||||
## 10. Сложность операций (итого) |
|
||||||
|
|
||||||
| Операция | Каскад | Сложность | |
|
||||||
|----------|--------|-----------| |
|
||||||
| Локальная вставка | 0 строк (конец) | O(1) | |
|
||||||
| PUSH (приём) | нет | O(1) | |
|
||||||
| SEND_DATA (батч N записей) | 1 каскад после батча | O(N + tail) | |
|
||||||
| Стартап-проверка | 1 раз | O(total) | |
|
||||||
| Sync-протокол (INIT_SYNC/INIT_RESP/REFINE) | нет cascade | O(log N) сообщений | |
|
||||||
|
|
||||||
## 11. Порядок реализации |
|
||||||
|
|
||||||
1. **Выделить `db_cascade_from(si, from_pos)`** из тела `db_record_insert`. |
|
||||||
2. **Добавить параметр `do_cascade`** в `db_record_insert`. При `0` — только INSERT, cascade вызывается отдельно. |
|
||||||
3. **Добавить `synced_pos`** в `struct SI_PEER`. Инициализировать в 0. |
|
||||||
4. **Добавить `si_find_pos(si, ts, dh)`** — поиск позиции записи в глобальном порядке. |
|
||||||
5. **Изменить wire-формат** INIT_SYNC, INIT_RESP, SYNC_DONE (chain_hash → datahash, 32→8 байт). |
|
||||||
6. **Изменить обработчики**: |
|
||||||
- `db_handle_init_sync`: новые размеры, datahash вместо chain_hash |
|
||||||
- `db_handle_init_resp`: новые размеры, datahash вместо chain_hash, обновлять synced_pos |
|
||||||
- `db_handle_send_data`: `do_cascade=0`, `db_cascade_from(fix_from)`, обновить synced_pos |
|
||||||
- `db_handle_push`: `do_cascade=0`, скорректировать все synced_pos |
|
||||||
- `db_handle_sync_done`: обновить synced_pos |
|
||||||
7. **Добавить `db_verify_chain(si)`** — вызвать при старте после `db_sync_instance_add`. |
|
||||||
8. **Многопировая синхронизация**: в `db_sync_peer_check_cb` выбирать пира с min synced_pos вместо первого попавшегося. |
|
||||||
@ -1,10 +0,0 @@ |
|||||||
В конфиге явно прописываются сокеты с ip и портом. |
|
||||||
Через эти сокеты идёт весь трафик, случайные порты клиент не использует - только эти сокеты. |
|
||||||
Соответственно, возможен только один линк между двумя пирами по одному каналу. |
|
||||||
|
|
||||||
виртуальные сокеты - плохо т.к. используются ip/port для поиск подключения |
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
./configure --with-openssl - openssl |
|
||||||
./configure --without-openssl - tinycrypt |
|
||||||
Loading…
Reference in new issue