public inbox for nncp-devel@lists.cypherpunks.ru
Atom feed
From: Sergey Matveev <stargrave@stargrave•org>
To: nncp-devel@lists.cypherpunks.ru
Subject: Re: [EN] NNCP 8.6.0 release announcement
Date: Wed, 2 Mar 2022 22:26:02 +0300 [thread overview]
Message-ID: <Yh/EyqR4g/snxgvF@stargrave.org> (raw)
In-Reply-To: <87ee3k9o44.fsf@complete.org>
[-- Attachment #1: Type: text/plain, Size: 3287 bytes --]
*** John Goerzen [2022-03-02 12:59]:
>I just had another thought - maybe the ideal place to generate ACKs is
>in the nncp-xfer/bundle rx code itself?
Actually initially I started exactly in them. But:
* if ACKs are in use, xfer/bundle (let's call them xfers) must use the
config with private keys. I do not use that use-case, but last time I
checked, you can use xfers with nncp-cfgmin-imized configuration file
version, that you safely can keep on unsafe storage/device. For
example you take a laptop with minimized configuration, keep the spool
on it, go outside, get connection with xfers in a place, where your
laptop can be stolen/compromised. Anyway it is used only for just
copying of files from one place (storages, tapes, whatever) to
another. No private keys (even encrypted ones (nncp-cfgenc)) are used
If we move all ACKing only to xfers, then there will be no way to
use xfers only for transport and some other thing only for ACKing.
Those are two completely different tasks with different requirements
* I used bundle with the tape drive, that REALLY has to be able just to
stream the data without any interruptions. That is why nncp-bundle
does not check checksum on the fly (I used all of that previously on
pretty low-performance CPU and BLAKE3 was not used in NNCP at that
time). And that is also desireable for HDDs too, to be able to do as
much sequential operation as it could (but it is not as critical as
with tapes). If xfers will generate ACKs on the fly after each
received packet, then it will interrupt sequential operations, it will
"touch" our spool or xfer's mounted directory
* we could just "remember" what ACKs we have to generate at the end of
the process, but... if the process is suddenly interrupted? We loose
that state and any knowledge of what was received and what we must ACK
>- Avoid the race with toss
Currently I am sure that it should not be run at all, because of
obviously undefined behaviour.
>I find it very useful for machines that primarily interact via
>daemon/call/caller where there is not always a definite "done" state
>even.
I do not find the idea of running it sometimes in background, while
those (long-live!) daemons are running, bad. I find that there sould be
used daemontools'es supervise service with it, like some kind of trivial:
$ cat services/nncp-toss/run
sleep 60
exec nncp-toss ...
which you will "down" when you insert your removable media to do
xfering and acking:
$ svc -d services/nncp-toss
$ nncp-xfer ...
$ nncp-ack ...
$ svc -u services/nncp-toss
>So generating ACKs in nncp-xfer/bundle still leaves the problem of keep
>for them.
Yes, that is independent problem. That I currently plan to solve with
temporary intermediate file generated by xfers with a list of packets
you need to ACK, that is used by nncp-ack/rm after.
>Maybe the answer would be a simple option to xfer/bundle tx:
>-always-delete-sent-acks or something.
If xfers will be capable to generated packets, then yes. But I am
against that, for the reasons at top of that letter.
--
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 --]
next prev parent reply other threads:[~2022-03-02 19:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-02 14:57 [EN] NNCP 8.6.0 release announcement Sergey Matveev
2022-03-02 16:18 ` John Goerzen
2022-03-02 16:22 ` John Goerzen
2022-03-02 18:55 ` Sergey Matveev
2022-03-02 18:47 ` Sergey Matveev
2022-03-02 18:59 ` John Goerzen
2022-03-02 19:26 ` Sergey Matveev [this message]
2022-03-03 3:10 ` John Goerzen