Greetings!

*** John Goerzen [2023-08-09 21:04]:
>> 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 +
>
>That makes sense.  Though if -seen is in use, I guess it will just cause
>a harmless retransmission.

Problem here is that ACK won't be generated at all, because packet is
already tossed. Duplicate ACKs is not a problem indeed, but completely
lost (non-generated) ones are bad of course.

>But there is the problem that toss may run before -ack.  Basically if
>anything at all on the system is going to use -ack, then you can't use
>-autotoss, or nncp-toss with -cycle, because that then means a race
>condition -- packets may be tossed before nncp-ack is run.  You
>basically have to ensure that nothing at all might run toss when you're
>loading stuff up for -ack, and that means some outside-of-NNCP locking
>in some cases.

Everything is right. ACK-based workflow was not compatible with autotossing.

>Maybe the thing to do here is extend nncp.hjson to add an "autoack"
>feature to a given node?  That way, nncp-toss could generate an ack for
>it at toss time.

As with -xfer/-bundle commands, you have to store the knowledge of
packets who carry ACKs. It was made by printing their identifiers to
stdout by nncp-ack command itself. With tossers (that are not only
-toss, but -daemon and -caller) you will have to create some kind of
atomically commitable database of those ACKs. It can be a directory with
just empty files, whose names will be ACK-packets identifiers.

I made ability to automatically generate ACKs during tossing in 8.9.0
release. nncp-toss -gen-ack, nncp-* -autotoss-gen-ack. Although I did
only quick testing if it works fine. It saves knowledge about ACK
packets in spool/tx/ack/PKT empty files. nncp-rm -ack will remove them
and corresponding spool/tx/PKT packets.

>One other thing I've been pondering: end-to-end ACKs.  So if you send
>from node A to node D via B and C, what happens if B receives the packet
>and then its disk dies?

Something badly unexpected will happen :-)
Well, end-to-end acknowledgments is more complicated, because
recipient's node does not know identity of the very first packet that
was sent. Something much more complicated must be done to deal with it.

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