public inbox for nncp-devel@lists.cypherpunks.ru
Atom feed
* Confirmation of Received Packets
@ 2022-02-23 13:17 John Goerzen
2022-02-24 11:10 ` Sergey Matveev
0 siblings, 1 reply; 5+ messages in thread
From: John Goerzen @ 2022-02-23 13:17 UTC (permalink / raw)
To: nncp-devel
Hi folks,
I am working to set up a fully airgapped system. It will exchange data
with another system solely by using nncp-xfer and USB sticks. This is
data I really wouldn't want to lose.
This brings to mind a thought...
With nncp-caller/daemon, there is a confirmation of correct receipt of
packets (including checksum). The sending side doesn't delete the
packet until it's received this confirmation from the receiver.
With nncp-xfer/bundle, we don't have that mechanism. We can choose to
either leave packets on the disk after transmission, or not. If we
leave packets on the disk after transmission, that implies that they
will be transmitted over and over. (We can use seen on the receiver
side to prevent multiple processing, but it won't prevent multiple
transmissions.)
If we don't keep the packets on the sender side, then we risk data loss
due to issues such as USB stick failure, loss of the USB stick, etc.
It seems it may be useful to have "something" on the receiver side
(toss, xfer, or bundler) be able to create a reply packet saying "I am
node X, and here is a list of packets I have successfully received and
checksummed." This packet could go back to the sender over whatever
method is used (xfer/bundle/etc).
There is perhaps a workaround (untested):
The sender machine can have a script around nncp-bundle that generates
bundles with unique filenames, placed into a particular "for node X"
directory on the USB stick.
The receiver can process these with nncp-bundle -check -rx. Assuming
that this command exits with code 0 if all packets are successfully
received and checked and nonzero if not (I couldn't find documentation
if this is indeed the case), then if all packets are successfully
received and checked, it could move the bundle into "verified by node X"
directory.
The next time the sender runs, it can run nncp-bundle -rx -delete over
everything in the "verified by node X" directory.
I think it would be nice to be able to handle this within NNCP, however.
It would mean lower storage requirement (just a few bytes to indicate
successful reception instead of keeping the entire bundle around), and
also a lot easier automation.
I would hope it wouldn't be too difficult to implement?
Thanks!
- John
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Confirmation of Received Packets
2022-02-23 13:17 Confirmation of Received Packets John Goerzen
@ 2022-02-24 11:10 ` Sergey Matveev
2022-02-24 22:00 ` John Goerzen
0 siblings, 1 reply; 5+ messages in thread
From: Sergey Matveev @ 2022-02-24 11:10 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 565 bytes --]
Greetings!
Yesterday I started to implement sending of new type of ACK-packets.
They just contain packet's hash, confirming the receipt. I assume that
you would optionally turn their sending on. When tossed, receiver will
just delete probably existing outbound packets mentioned in those ACKs.
I hope that will finish that on holidays. Really would be useful, seems
very easy to implement and currently I do not see drawbacks or complications.
--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Confirmation of Received Packets
2022-02-24 11:10 ` Sergey Matveev
@ 2022-02-24 22:00 ` John Goerzen
2022-02-24 22:03 ` Sergey Matveev
0 siblings, 1 reply; 5+ messages in thread
From: John Goerzen @ 2022-02-24 22:00 UTC (permalink / raw)
To: Sergey Matveev; +Cc: nncp-devel
On Thu, Feb 24 2022, Sergey Matveev wrote:
> Greetings!
>
> Yesterday I started to implement sending of new type of ACK-packets.
> They just contain packet's hash, confirming the receipt. I assume that
> you would optionally turn their sending on. When tossed, receiver will
> just delete probably existing outbound packets mentioned in those ACKs.
> I hope that will finish that on holidays. Really would be useful, seems
> very easy to implement and currently I do not see drawbacks or complications.
Fantastic! That sounds perfect, and I was hoping it would be easy like
that indeed. I suspect it wouldn't require any breaking changes (would
be compatible with older versions unless the new ACK options are turned
on)?
Thanks,
John
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Confirmation of Received Packets
2022-02-24 22:00 ` John Goerzen
@ 2022-02-24 22:03 ` Sergey Matveev
2022-02-25 22:46 ` Jonathan Lane
0 siblings, 1 reply; 5+ messages in thread
From: Sergey Matveev @ 2022-02-24 22:03 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 431 bytes --]
*** John Goerzen [2022-02-24 16:00]:
>I suspect it wouldn't require any breaking changes (would
>be compatible with older versions unless the new ACK options are turned
Absolutely no incompatible changes. Only if ACK packets are received by
an old NNCP version, it will fail and claim about unknown packet type.
--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Confirmation of Received Packets
2022-02-24 22:03 ` Sergey Matveev
@ 2022-02-25 22:46 ` Jonathan Lane
0 siblings, 0 replies; 5+ messages in thread
From: Jonathan Lane @ 2022-02-25 22:46 UTC (permalink / raw)
To: nncp-devel
It occurs to me that this sort of extremely lightweight file based retry
would be of great value for deep space networking where round-trip
latency is too high for TCP. It might be worth listing "interplanetary
email" on the usecases part of the project page!
--
tidux@sdf•org
SDF Public Access UNIX System - http://sdf.org
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-02-25 22:46 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-23 13:17 Confirmation of Received Packets John Goerzen
2022-02-24 11:10 ` Sergey Matveev
2022-02-24 22:00 ` John Goerzen
2022-02-24 22:03 ` Sergey Matveev
2022-02-25 22:46 ` Jonathan Lane