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