aboutsummaryrefslogtreecommitdiffstats
path: root/docs/research/093-connectionless-link.md
Commit message (Collapse)AuthorAgeFilesLines
* Put the links and the crypto they use in link/, a part of their owneunhhu2026-09-291-1/+1
| | | | | libpure-link.a holds them; pure-serve and the M5 harness link it instead of naming its source files.
* Link two nodes without a connection over UDP (093, design 011's first stage)eunhhu2026-09-281-0/+84
pure-serve --send OUTPUT=pure://host:port/INPUT sends an output's saved sends to another node's --link-port with no handshake: the first packet carries records. Keys come from the two nodes' keys (X25519, HKDF-SHA256, AES-128-GCM), with a random run in each packet's header so no nonce repeats across restarts; nothing is stored for them. What lasts is the apps' own: the sender's outbox and the receiver's heard numbers (pure_app_heard, new). The sender detects losses as RFC 9002 says, with NewReno, and trims a send once the receiver says it stored it; the receiver hands the owner whole records in order, which it applies from the one after the source's last heard number, stopping at a gap, and answers how far it stored with every acknowledgment. Stored bytes are the bytes on the wire: an output and an input of one shape need no JSON. server_links_udp kills the receiver, the sender, then both (-9) while four clients buy: every saved order is applied once, with no handshake (five runs, 10k-11k orders each). server_links_udp_lossy does it again in a namespace of its own with the link's packets delayed, lost (3 %) and reordered (10 %) by netem (three runs, 11k-12k orders).