Subject: Re: Suggestions to make ACK easier

From: John Goerzen <[email-masked]>
Date: Tue, 11 Jul 2023 10:55:49 -0500

I guess one other thought - doing it at toss time, while it may have a
risk of acking more than once, could also be nice as it would make it
convenient to do end-to-end ACKs even on cases where things traverse
several network hops.

- John

On Tue, Jul 11 2023, John Goerzen wrote:

> 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