public inbox for nncp-devel@lists.cypherpunks.ru
Atom feed

From: John Goerzen <jgoerzen@complete•org>
To: nncp-devel@lists.cypherpunks.ru
Subject: Suggestions to make ACK easier
Date: Tue, 11 Jul 2023 09:28:07 -0500	[thread overview]
Message-ID: <87pm4yjz3t.fsf@complete.org> (raw)

Hi,

A question about ACKs came up on the Matrix channel today, which
prompted me to revisit my previous article about it, at
https://www.complete.org/dead-usb-drives-are-fine-building-a-reliable-sneakernet/

There are two sort of pain points:

1) There is a race condition in that nncp-ack must run before nncp-toss
for incoming packets.

2) We have to save off the list of generated ACKs so that we can remove
them from the queue later.

I think the situation could be simplified with two tweaks:

First, nncp-xfer (and all the others, nncp-call, caller, daemon, bundle,
etc) could have a -ack mode that will cause it to automatically generate
an ack after successful receipt of a packet, eliminating the nncp-toss
race condition.  (Or maybe it would make more sense to put this in toss?
But there I think it would be more easy to generate multiple ACKs)

Then, nncp-xfer -tx could have a -keepexceptacks or something, that would
cause it to keep all packets it sends, EXCEPT for the acks.  That
eliminates the need to save off the list of generated ACKs from an
earlier step.  It may be that the status of a packet as an ACK isn't
available at this point, in which case a separate flag file or something
may be useful.

Thanks,

John

next             reply	other threads:[~2023-07-11 14:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-11 14:28 John Goerzen [this message]
2023-07-11 15:55 ` Suggestions to make ACK easier John Goerzen
2023-07-30  7:47 ` Sergey Matveev
2023-08-09 12:04 ` Sergey Matveev
2023-08-10  2:04   ` John Goerzen
2023-08-13 20:30     ` Sergey Matveev
2023-09-13 17:29       ` John Goerzen