Skip to main content

window_for

Function window_for 

Source
pub fn window_for(lines: &[Line], by: Author<'_>, to: &str, now: i64) -> Window
Expand description

The window of by’s tells and asks to to (written as a line writes it) in lines at now.

The sender’s messages to to are replayed by stamp, then id, each id once, so the result does not depend on the order lines arrived in. The window starts at 1. A message is within it when, at its stamp, fewer of the earlier ones are outstanding than the window holds: every earlier one the lines hold, within the window or not (one a writer put past its window is unread at its recipient all the same). One that is acknowledged, by a Seen that lists it or a reply to it (re) from a recipient (acknowledges), whatever the acknowledgement’s stamp, doubles the window up to WINDOW_CAP; one that passes TTL_MS unacknowledged halves it, to 1 at least. An ask is acknowledged as a tell is, so it leaves the window on its answer (or when shown), or at its TTL. Where no acknowledgement may come (Pace), V1_RATE_MS also admits (Floor), or alone admits (Rate), the first message and then each one at least that long after the sender’s previous one, whatever was acknowledged, so those admissions depend on the stamps alone and an acknowledgement only ever adds to what is admitted. Steers and seen lines are not paced. Pure: send decides by it alone. Its numbers are protocol, as every node must replay them alike: 1, the least window that lets a message reach a recipient that has read none; doubling and halving, so a reading recipient’s window grows to the cap within a few messages and an absent one’s falls back as fast.

What it admits depends on the earlier lines, which the TTL and the bound remove: a replay later can admit less than send did. So no node decides a line by it after send: what every window admits has a bound that depends on no earlier line (within_windows), which the mesh checks instead.