public inbox for nncp-devel@lists.stargrave.org
Atom feed
* ACK packets?
@ 2025-12-13 22:50 Hadmut Danisch
2025-12-13 23:11 ` John Goerzen
0 siblings, 1 reply; 5+ messages in thread
From: Hadmut Danisch @ 2025-12-13 22:50 UTC (permalink / raw)
To: nncp-devel
Hi,
when sending A->B->C, then C can send ACKs back C->B->A.
But what exactly do these ACKs on A then?
http://www.nncpgo.org/ACK.html is not really talkative about that and
explains, that one can send ACKs, but only nncp-xfer seems to support
-keep, and the explanation suggests that these ACKs are used for manual
administration.
I would have thought that regular messages generated from nncp-file or
nncp-exec are kept after sending, until ACKed, and resent if not ACKed
withon reasonable (=configurable) time.
regards
Hadmut
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ACK packets?
2025-12-13 22:50 ACK packets? Hadmut Danisch
@ 2025-12-13 23:11 ` John Goerzen
2025-12-13 23:42 ` Hadmut Danisch
0 siblings, 1 reply; 5+ messages in thread
From: John Goerzen @ 2025-12-13 23:11 UTC (permalink / raw)
To: Hadmut Danisch; +Cc: nncp-devel
Hi Hadmut,
ACK packets are most useful when used with nncp-xfer and such. You
could also use them if you think that, for instance, machine B in your
example is not entirely reliable.
I have an article at
https://www.complete.org/dead-usb-drives-are-fine-building-a-reliable-sneakernet/
that may explain it more for you.
- John
On Sun, Dec 14 2025, Hadmut Danisch wrote:
> Hi,
>
>
> when sending A->B->C, then C can send ACKs back C->B->A.
>
> But what exactly do these ACKs on A then?
>
>
> http://www.nncpgo.org/ACK.html is not really talkative about that and explains,
> that one can send ACKs, but only nncp-xfer seems to support -keep, and the
> explanation suggests that these ACKs are used for manual administration.
>
>
>
> I would have thought that regular messages generated from nncp-file or nncp-exec
> are kept after sending, until ACKed, and resent if not ACKed withon reasonable
> (=configurable) time.
>
>
> regards
>
> Hadmut
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ACK packets?
2025-12-13 23:11 ` John Goerzen
@ 2025-12-13 23:42 ` Hadmut Danisch
2025-12-15 5:41 ` John Goerzen
0 siblings, 1 reply; 5+ messages in thread
From: Hadmut Danisch @ 2025-12-13 23:42 UTC (permalink / raw)
To: nncp-devel
Am 14.12.25 um 01:11 schrieb John Goerzen:
> You
> could also use them if you think that, for instance, machine B in your
> example is not entirely reliable.
That's what I had intended, but when using internet connections instead
of usb-drives, I'm not using nncp-xfer, but nncp-exec, nncp-file,
nncp-daemon, and nncp-caller, and as far as I can see, they do not
support this -keep option.
regards
Hadmut
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ACK packets?
2025-12-13 23:42 ` Hadmut Danisch
@ 2025-12-15 5:41 ` John Goerzen
2025-12-15 11:40 ` Hadmut Danisch
0 siblings, 1 reply; 5+ messages in thread
From: John Goerzen @ 2025-12-15 5:41 UTC (permalink / raw)
To: Hadmut Danisch; +Cc: nncp-devel
On Sun, Dec 14 2025, Hadmut Danisch wrote:
> Am 14.12.25 um 01:11 schrieb John Goerzen:
>> You
>> could also use them if you think that, for instance, machine B in your
>> example is not entirely reliable.
>
>
> That's what I had intended, but when using internet connections instead of
> usb-drives, I'm not using nncp-xfer, but nncp-exec, nncp-file, nncp-daemon, and
> nncp-caller, and as far as I can see, they do not support this -keep option.
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.
-keep wouldn't be relevant for exec or file, since they don't do
anything that would remove packets.
https://www.complete.org/nncp-concepts/ may possibly help you out there.
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.
- John
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ACK packets?
2025-12-15 5:41 ` John Goerzen
@ 2025-12-15 11:40 ` Hadmut Danisch
0 siblings, 0 replies; 5+ messages in thread
From: Hadmut Danisch @ 2025-12-15 11:40 UTC (permalink / raw)
To: nncp-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-12-15 11:41 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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