Verified execution runtime unifying state, persistence, and replication. http://git.yeowoo.org/pure/atom?h=master 2026-10-04T09:06:41Z 2026-10-04T09:06:41Z eunhhu necpition205@gmail.com 2026-10-04T09:06:41Z urn:sha1:578d0ab47f22e0185987ed3f8c091129985cec6e A stream finds its input once, when it is made; an app that starts again with another module may have the input at another number, of another shape, or none. pure_link_receiver_rebind marks the streams to inputs of a prefix stale: each finds its input again by name, with the fields it was laid out with, before its next delivery and at its sender's next packet, keeping what it holds; one none takes is refused as a new one would be. pure_link_listener_rebind asks it of the listener's thread. test-link's rebound case stops its app, starts it with the input at another number, then of another shape taken by name: all 3,000 records come once, in order (without the rebind, none after the stop). 2026-09-30T04:58:38Z eunhhu necpition205@gmail.com 2026-09-30T04:58:38Z urn:sha1:5ce7655d613689223050715ff3f8fe5c456ebf11 A message from another node was taken only in its input's exact shape (the link's STREAM shape, fields and order alike; over HTTP, every field). So a board whose nodes are upgraded one after the other stopped both ways until both were, and an output and its input whose fields differ only in order were refused for good (docs/design/014). An input now takes a message when it has every field the sender sends, by name, of the same type or one that holds its values (a u32 in a number, text in bytes); a field only the input has is 0 or empty. One that sends a field the input lacks is refused: taking it would drop the value, and with its number heard the value would never come again (two boards apart for good). So add fields to receivers first and take them from senders first, and nothing stops or is lost. The link carries a sender's fields in a new frame, FIELDS (0x0d: names, shape, u8 count, each {type, name length, name}): after a REFUSED for another shape the sender puts it in its packets (after OFFER, before the records, so a receiver that knows no FIELDS reads what it read before) until the stream is taken, the first time at once. A receiver seeing another shape waits for the packet's FIELDS before refusing, and asks its host with them (PureLinkHost.input takes them); REFUSED says 4 when the input lacks a field. Deliveries carry the fields and the host lays each record out anew (pure_module_takes, pure_module_recast, pure_module_fields, over pure_send_recast's rule). A stream whose sender starts again in another shape lets go what it held; the sender sends it again laid out anew. A refusal already queued for a stream now says the last reason judged, not the first. Over HTTP a delivery (X-Pure-Source) may lack fields; an unknown member is still refused. test-link named: a stream of another shape naming its fields is taken, 200 stored in 47 ms with every delivery naming them; an input that does not take them refuses (4) and the sender backs off. check.py server_fields: five outputs, three linked and two over HTTP, fields in another order taken, an input with a field more taking messages without it, one lacking a field refusing until it starts again with it, then taking all. server_upgrade's new receiver declares its fields in another order. 012 names the frame and the rules. 2026-09-30T02:32:07Z eunhhu necpition205@gmail.com 2026-09-30T02:32:07Z urn:sha1:d9e0b6870201d9200b3c225903b43b850475600b A link's ring and a wire's queue took every saved send of their output and kept it until delivered: with the receiver down they held the outbox a second time, 178 B and 313 B more a send (104). Each outlet now holds a window, --window bytes (4 MiB) and 65,536 sends past what its receiver has, at least one; the outbox keeps the rest. The owner remembers each outlet's place in the outbox and looks on from there after a save and after its transports deliver. Places move back by the sends that left the outbox since (PureApp.sends_gone), so a trim before a place skips nothing, and sends queued before are not looked at again however many wait. pure_app_sent reads a send by its place (the newest-first visit it replaces is gone); pure_link_held and pure_wire_held say what a transport holds. With the receiver down a node now grows by the outbox alone once the window is full: 219 and 218 B a send over the link and HTTP (399 and 534 B before). check.py server_windows keeps the receivers of a sender's two outputs, one linked and one over HTTP, down through 300 buys with a 2,000-byte window, then starts them: each applies all 300 once. Without the refill after deliveries the link stops at 117. 2026-09-30T02:03:52Z eunhhu necpition205@gmail.com 2026-09-30T02:03:52Z urn:sha1:c9c0edf5a8fc9f79fff42064db09bc297e117a88 A link's delivery the app had no room for was handed over again at the next turn: a receiver over its memory budget would refuse the same records as fast as the owner could apply them. And its sender, seeing records received but not stored for a second, sent the whole window again every second. Now a host says a delivery found it full (PureLinkDone.full). The receiver keeps the records and hands them over again after a pause, 100 ms doubling to 500 ms, and meanwhile its STORED frames carry flag 2: the app is full and what came is kept. A sender hearing it starts its one-second wait for the save again, and sends none of it again. The spec (012) says both sides; the pause is a local choice that must stay under the sender's wait. pure_link_done takes the PureLinkDone itself. test-link's new case keeps the app full for 5 s: 12 hand-overs meanwhile, taken within 0.5 s of having room, and no record sent again (21,640 without the flag). 2026-09-29T15:55:04Z eunhhu necpition205@gmail.com 2026-09-29T15:55:04Z urn:sha1:c494ec7a37ff4863d420b4a9ccbe1df93e88de2d A receiver's memo kept one run's epoch a peer. A node whose outputs send to this one sends in a run each, so after the receiver started again (or let the peer rest) all runs but the last accepted were told LOST and began their epochs again: records under the static keys for a round trip, and an X25519 each. Now a run whose peer's place holds another run still sending keeps its epoch beside, in one of two of 1,024 places its peer and run find (160 KiB at the file's head: the memo is PLM3, and a PLM2 one is begun again). A run's place beside goes once its peer's place has it, so an epoch's secrets stay only until the next one's are. test-link's three outputs of one node, each in epoch 1, go on after the receiver starts again: no LOST, no X25519 (before: two LOSTs, an accept). 012 says so. 2026-09-29T15:42:45Z eunhhu necpition205@gmail.com 2026-09-29T15:42:45Z urn:sha1:a06b652768a8643fe76efdc80a0c6eb729268fc5 A receiver that took no records of a stream (a source the key may not send as, no input of that name, an input of another shape) said nothing: its sender heard them acknowledged, never stored, and sent them all again every second, for ever, and its operator saw nothing. Now the receiver answers REFUSED (0x0c: the names, and why), and the sender sends no records for a second, then a packet of them to learn whether they are taken now, the wait twice as long each time (64 s at most). A refusal ends when that packet is acknowledged with no REFUSED beside, or a record is stored. link.c says it once on stderr, as a wire says a receiver does not take its sends; serve's input says which of the two the app lacks. test-link: each of the three is refused seven times in 90 s with nine packets, and a stream refused until the app has its input goes on then, all 200 records stored. check.py links a node to an input its receiver lacks: said once, two packets in 2.5 s. 2026-09-29T15:41:24Z eunhhu necpition205@gmail.com 2026-09-29T15:41:24Z urn:sha1:3bd9b6c924c801dc5033510391ac251a7309219f A sender took sends up to 64 MiB, but a receiver holds 16 MiB of a stream not yet stored, so a send between the two went again forever. The most a send may be is now PURE_LINK_RECORD_MOST, what a receiver holds; test-link sends one that large whole and is refused one byte more. 2026-09-29T14:59:44Z eunhhu necpition205@gmail.com 2026-09-29T14:59:44Z urn:sha1:d0be140549b67708039f3c69d0b039440eb3a063 A receiver that started again without its memo could open none of its senders' packets (their epochs were gone), said nothing, and each sender waited 2 s and four probes, then offered with no records. Worse, those packets failed to open, so each cost a token (256 a second, the flood guard): ten thousand senders came back 256 a second. M2 without a memo stopped 0.8 s and caught up in 7.7 s. Now the receiver answers a packet of a run it does not know, in an epoch past 0, with LOST: sealed in epoch 0 under the nodes' keys, naming the packet. As QUIC's stateless reset, it is smaller than the packet and comes out of a bucket of its own (4,096 a second). A sender that has that packet out begins again as a run begins: epoch 0 with its records at once, epoch 1 offered. Only the receiver can say LOST, and one of the past names a packet no longer out; silence alone (an attacker's doing, maybe) still gets offers only. Such a packet costs no key token: no keys were made for it, and the secret made is remembered, once a sender. M2 without a memo (ten thousand devices, twice): no 100 ms step stopped, caught up in 0.4-0.5 s, p99 5.8-5.9 ms, the most 48-57 ms (was 4.1 and 7.8 s). test-link: a changed packet may get a LOST smaller than itself and nothing else; half of a flood in epoch 1 got 267 LOSTs, 12 KB for its 6 MB; a record goes under the nodes' keys after an epoch began only after the receiver forgot, until the next epoch. 2026-09-29T14:41:03Z eunhhu necpition205@gmail.com 2026-09-29T14:41:03Z urn:sha1:ccf35df074bcb450ebdc56eb27762a9096252a3f A link that found the path carries 1,452 bytes kept sending them when a route changed and larger packets were dropped with nothing said (a black hole): it lost them one after another and stood still (test-link: 8 of 3,000 records in ten minutes). Now, as RFC 8899 §4.3 has it, it goes back to 1,200 bytes when three larger packets in a row are lost while an acknowledgment covers only smaller ones, or when two probes in a row go unanswered, and tries the larger size again a second on (three tries, then ten minutes). The case completes in 1.2 s of virtual time; the M6 simulator's results are the same to the byte in eight paths of loss, reordering and a bottleneck. 2026-09-29T14:26:30Z eunhhu necpition205@gmail.com 2026-09-29T14:26:30Z urn:sha1:56d6876f906f91db9f48f0f27b7f456ee601efd9 Profiling both sides in one thread, without sockets (61-byte records): the rings of records and flights divided for each place, the record a number names was found three times over, a record in one part was searched for its part, and the receiver walked the line record by record to hand it over and again to let it go. The rings are powers of two long and now masked; a record is found once; a one-part record's part is the first; a line of a batch or less goes whole without a walk, and a delivery applied whole lets its bytes go at once. The protocol alone: 0.171 to 0.162 us a record. M5 (the link and listener threads, sockets too), five rounds against the commit before: 61 B 0.298 to 0.287 us, 1 KiB 2.63-2.90 to 2.48-2.79 us, 16 KiB the same or less; quinn measured 0.31, 3.85 and 60 us in the same rounds. test-link's results are the same to the byte.