public inbox for nncp-devel@lists.cypherpunks.ru
Atom feed
From: John Goerzen <jgoerzen@complete•org>
To: Sergey Matveev <stargrave@stargrave•org>
Cc: nncp-devel@lists.cypherpunks.ru
Subject: Re: [EN] NNCP 8.6.0 release announcement
Date: Wed, 02 Mar 2022 10:18:19 -0600	[thread overview]
Message-ID: <87k0dc9vlg.fsf@complete.org> (raw)
In-Reply-To: <Yh+F/O2agaxBNBxN@stargrave.org>

On Wed, Mar 02 2022, Sergey Matveev wrote:

> I am pleased to announce NNCP 8.6.0 release availability!

Thank you, Sergey!  I will get to work packaging this version right
away.  This will be very helpful right away!

I'm starting to plan out my implementation...

I have two questions about ACK packet generation.

First, let's say I have two machines, A and B, that are airgapped and
they communicate using nncp-xfer and a USB stick that moves between
them.  I want to use nncp-ack for all the reasons we talked about, on
BOTH ends.

That raises the question of: how do we handle the ACK packets
themselves?

In theory, we sort of have two options:

1) Never keep ACK packets on the source machine, and never send ACKs for
them on the destination.

2) Handle them like any other packet.  But this implies an endless
stream of re-ACKing.

I think option #1 is preferable.  If an ACK is lost, there's no harm
(particularly if -seen is in use, which it should be in this cast [might
want to mention that hint on the nncp-ack documentation page]).  The
sender will simply retransmit, the recipient will re-ACK and then toss
will ignore it as it's been seen.

That implies two questions then: how to prevent nncp-ack from itself
ACKing an ACK, and how to cause nncp-xfer to not keep ACKs?

I *THINK* we can do this with niceness.  If so, maybe this could be
included in the doc page also, or maybe there should be some code in
there so that nncp-ack doesn't ack an ack...

So...

# First receive ACKs
nncp-xfer -rx -nice 1 /mnt/shared

# Toss them, which will delete them before they can be acked.
nncp-toss -nice 1

# Now receive the rest of the packets
nncp-xfer -rx /mnt/shared

# Ack them
nncp-ack -nice 1 -node alice

# Send the ACKs, without -keep
nncp-xfer -tx -nice 1 -node alice /mnt/shared

# Toss the rest
nncp-toss

# Send the other replies, with -keep
nncp-xfer -tx -keep -node alice /mnt/shared


Somewhat related - I have nncp-toss running as a daemon (-cycle) mode on
some nodes that I will want to enable ack generation for.  That implies
a race condition; will nncp-ack or nncp-toss get to the packets first,
after nncp-xfer copies them into the rx directory?

I would be fine with an -ack option to nncp-toss (similar to the -seen
option we already have).  Yes, that may generate unnecessary ACKs to
systems that are communicated with by call/daemon, but it probably makes
things very simple and I'm fine with that very small overhead.
Alternatively, there could be an ack option added to the neigh
configuration for a particular node, which would cause toss to always
generate ack packets when it processes packets inbound from that node.

... in thinking about this a bit more, I suppose this may need some
additional logic such that toss keeps track of what packets it's already
ACKd.  With something like -cycle 60 and a packet for which toss fails,
that could generate thousands of ACKs per day.  I guess nncp-ack would
also generate duplicate ACKs, but most likely in a far smaller quantity.
This may just over-complicate things.


- John

  reply	other threads:[~2022-03-02 16:19 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 [this message]
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
2022-03-03  3:10         ` John Goerzen