From dc013e3cd887da2989176853837cea578c84da57 Mon Sep 17 00:00:00 2001 From: tv Date: Wed, 4 Nov 2026 23:38:17 +0100 Subject: one delta at a time --- docs/peers.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/peers.md b/docs/peers.md index 1219149..d22fef6 100644 --- a/docs/peers.md +++ b/docs/peers.md @@ -166,7 +166,11 @@ as it knows them). The peer fetches them as a blob, in chunks, from the sender a other peer holding those heads (every such peer produces the same bytes), loads them, and syncs on; the rest goes in ordinary messages. Until the peer answers, the sender sends it nothing; if the answer is overdue, it offers again. This is how a join without a -recent remake, or a return after much was written, gets the bulk of its changes. +recent remake, or a return after much was written, gets the bulk of its changes. A node +downloads one delta at a time: while a large one comes, it lacks those changes, so its +other neighbours offer them too, and they would come once per offer. Offers that come +meanwhile wait; once the delta is in, the node syncs with those that offered, which then +send only what is still missing. Towards a peer on a slow link the limit is lower: a message is offered as a delta if it would take more than 5 s at the throughput measured to that peer (`syncThroughput`, -- cgit v1.3.1