*** 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