diff options
Diffstat (limited to 'docs/design')
| -rw-r--r-- | docs/design/011-pure-transport.md | 5 |
1 files changed, 5 insertions, 0 deletions
diff --git a/docs/design/011-pure-transport.md b/docs/design/011-pure-transport.md index d3a327a..6ad02ea 100644 --- a/docs/design/011-pure-transport.md +++ b/docs/design/011-pure-transport.md @@ -37,6 +37,11 @@ M6는 [097](../research/097-lossy-paths.md)에 있다. 처음에는 패킷 순� 상태와 재시작은 에폭 전과 같다. 값은 대량으로 처음 만난 뒤 약 40초의 지연(p50 +0.7 ms)과, 메모를 잃은 재시작의 7.7초 따라잡기다. 이것을 재다가 M6와 보안 검사가 기기마다 패킷을 하나씩 더 보내던 것(+10k, +38k)을 찾아 없앴다. +M3(저장소 옮기기, H3)는 [100](../research/100-moved-receiver.md)에 있다. 링크는 탐침 세 번이 답을 받지 못하거나 시스템이 길이 +없다고 하면 받는 쪽의 이름을 다시 풀고 새 소켓으로 보낸다. 기기 1만 개가 초당 2,000건을 보내는 중에 받는 쪽의 저장소, 키, 메모를 +다른 주소로 옮겨도 저장이 멈춘 칸이 없고, 옮긴 노드의 X25519는 0이며, 잃거나 겹친 기록이 없다. 그 검사를 만들다 받는 쪽이 패킷이 +온 주소가 아닌 곳에서 답하던 결함도 찾아 고쳤다. 이제 H1–H4를 모두 쟀고, 남은 것은 5단계(채택과 명세)다. + 2026-09-29에 링크를 `link/`로 뗐다([009](009-layout.md)). 프로토콜은 이제 소켓, 스레드, 시계가 없는 상태이고 (`link/link-protocol.h`), UDP와 스레드는 그 위의 층이다. 그래서 한 스레드가 링크 여럿을 들 수 있다. M2를 이 보내는 쪽으로 다시 돌렸더니 결과가 같았다. 다만 재시작 뒤 가장 늦은 저장이 1초였다. 받았다고 했지만 저장 소식이 없는 기록을 1초 기다리기 |