Greetings!

*** John Goerzen [2023-07-11 09:28]:
>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)

I am afraid I dislike all those ideas unfortunately, basically because
of non-atomic operations.

If "nncp-xfer -rx" will generate ACK packet, then what if something will
go wrong and outbound ACK packet could not be saved? We loose that ACK
and our running nncp-toss can already toss retrieved packet. -xfer +
-ack + -toss guarantees that if -ack will fail, then no packet will
disappear because of tossing. We can rerun -ack and be sure that ACKs
are generated (or will catch some error again (missing free disk space
for example)), and only after that we will toss them. So that won't
eliminate the race between reception and tossing.

>Then, nncp-xfer -tx could have a -keepexceptacks or something, that would
>cause it to keep all packets it sends, EXCEPT for the acks.

Unfortunately it can not, because -xfer sees only already encrypted
packets, which lacks packet type identification. It does not know what
it transfers. Or we have to keep some state, list of encrypted ACK
packets that can be safely removed, that leads to current workflow again.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: 12AD 3268 9C66 0D42 6967  FD75 CB82 0563 2107 AD8A