Subject: Re: ACK packets?

From: Hadmut Danisch <[email-masked]>
Date: Mon, 15 Dec 2025 13:40:49 +0200

Am 15.12.25 um 07:41 schrieb John Goerzen:
> Hi Hadmut,
>
> It sounds like you might be confusing the different types of commands.
> exec and file both create packets.  daemon and caller exchange them over
> the network, and of course xfer exchanges them over the filesystem.

No, not confusing. I understood this.

But I'm talking about a different point.

nncp seems to make use of these acks only for nncp-xfer (filesystem), 
and not for daemon/caller, as you point out yourself:

>
> The network protocol confirms delivery to the next hop itself, so
> packets are only deleted off the origin machine with daemon or caller
> once the remote confirms delivery.
>
> However, this of course can't protect against an intermediate maching
> dying in the midst of a multihop delivery.  I could see ack being useful
> there.  Sergey will have to comment on that one.
>

This is exactly what my question is about.

I do have a configuration like

A -> B -> C, where   transmission needs B, because C only sometimes 
powered on,  but B not reliable, because just a single SSD, not 
mirrored, and for other reasons.

I therefore configured C to call B (and send to A via B) with

calls: [ { cron: "*/30 * * * *" , autotoss: true, autotoss-nofile: 
false, autotoss-nofreq: true, autotoss-gen-ack: true} ],

and it works: For every successfully exec, C sends an ACK back to A.

But: What is that ACK in calls: good for, if only nncp-xfer makes use of 
it?

One could argue that this meant for the case that A-B is handled with xfer.

But wouldn't it make sense if A kept the packets until it received the 
ACK from C, and either retransmit them automatically after some period, 
or with manual administrator interaction? And to give nncp-file and 
nncp-exec a -keep option to keep the packet until acknowledged?

I admit, that this comes with difficulties. As I understood, keeping the 
packets would be useless if B is gone and recreated from scratch, and 
B's secret nncp keys are gone as well, because no node is able to 
decrypt them.

But given the case B is totally gone and recreated, with keys recovered 
but packets lost: Wouldn't it help if A kept the packets until C has 
acknowledged them?

regards

Hadmut