*** John Goerzen [2021-02-20 22:31]:
>Interesting.  How do these different options interact with removing the
>packet from the remote end?

Packet is deleted only and only when confirmation is sent. And
confirmation is sent only if either packet with the same hash exists in
the spool directory (completely checksummed and fully downloaded), or
corresponding .seen packet exists (that can appear only after tossing of
completely checksummed and fully downloaded packet).

By default, after packet is received, it is renamed .part->.nock and it
is added to background checker queue. When checker finishes
checksumming, it renames .nock->"no extension" and sends confirmation to
the remote side. If remote side is unavailable (connection is lost),
then that confirmation is lost. But ordinary packet (or .seen after its
tossing) will be in the spool. Each online session starts with sending
the whole list of packets (taking niceness in advance) to the remote
side. And during the next session, because of packet/.seen, confirmation
will be sent and packet deleted on remote side. Also, when session
begins, background checker is started with pre-filled queue of currently
existing .nock files (by default, if no -nock option is turned on), that
will send confirmation when .nock-s are checked.

So no loss is possible (.nock files are not enough for confirmation).
Lost connections are not a problem, if you keep state of seen packets --
confirmation will be sent during the next sessions.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF