public inbox for nncp-devel@lists.stargrave.org
Atom feed
From: Hadmut Danisch <hadmut@danisch•de>
To: nncp-devel@lists.cypherpunks.su
Subject: Re: ACK packets?
Date: Mon, 15 Dec 2025 13:40:49 +0200	[thread overview]
Message-ID: <f96c5781-12b0-4d33-bef0-0f1a498ece72@danisch.de> (raw)
In-Reply-To: <877buofgjq.fsf@complete.org>

[-- Attachment #1: Type: text/plain, Size: 2236 bytes --]


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











[-- Attachment #2: Type: text/html, Size: 3646 bytes --]

      reply	other threads:[~2025-12-15 11:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-13 22:50 ACK packets? Hadmut Danisch
2025-12-13 23:11 ` John Goerzen
2025-12-13 23:42   ` Hadmut Danisch
2025-12-15  5:41     ` John Goerzen
2025-12-15 11:40       ` Hadmut Danisch [this message]