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: Suggestions to make ACK easier
Date: Wed, 09 Aug 2023 21:04:33 -0500	[thread overview]
Message-ID: <875y5nsl4g.fsf@complete.org> (raw)
In-Reply-To: <ZNOBPHRMdVGRayV9@stargrave.org>


On Wed, Aug 09 2023, Sergey Matveev wrote:

> [[PGP Signed Part:Undecided]]
> Greetings!
>
> *** John Goerzen [2023-07-11 09:28]:
>>First, nncp-xfer (and all the others, nncp-call, caller, daemon, bundle,
>>etc) could have a -ack mode that will cause it to automatically generate
>>an ack after successful receipt of a packet, eliminating the nncp-toss
>>race condition.  (Or maybe it would make more sense to put this in toss?
>>But there I think it would be more easy to generate multiple ACKs)
>
> I am afraid I dislike all those ideas unfortunately, basically because
> of non-atomic operations.
>
> If "nncp-xfer -rx" will generate ACK packet, then what if something will
> go wrong and outbound ACK packet could not be saved? We loose that ACK
> and our running nncp-toss can already toss retrieved packet. -xfer +

That makes sense.  Though if -seen is in use, I guess it will just cause
a harmless retransmission.

> -ack + -toss guarantees that if -ack will fail, then no packet will
> disappear because of tossing. We can rerun -ack and be sure that ACKs

But there is the problem that toss may run before -ack.  Basically if
anything at all on the system is going to use -ack, then you can't use
-autotoss, or nncp-toss with -cycle, because that then means a race
condition -- packets may be tossed before nncp-ack is run.  You
basically have to ensure that nothing at all might run toss when you're
loading stuff up for -ack, and that means some outside-of-NNCP locking
in some cases.

Maybe the thing to do here is extend nncp.hjson to add an "autoack"
feature to a given node?  That way, nncp-toss could generate an ack for
it at toss time.  This may imply needing a seen-like method to prevent
sending multiple ACKs for a packet that fails to toss the first time.

One other thing I've been pondering: end-to-end ACKs.  So if you send
from node A to node D via B and C, what happens if B receives the packet
and then its disk dies?  This is similar to the USB drive case.  I
suppose we could have each piece along the chain generate ACKs to the
previous one, or could we have D generate an ack back to A when the
packet arrives at D?  That may be too complicated, but just a thought
I've been having.

> are generated (or will catch some error again (missing free disk space
> for example)), and only after that we will toss them. So that won't
> eliminate the race between reception and tossing.
>
>>Then, nncp-xfer -tx could have a -keepexceptacks or something, that would
>>cause it to keep all packets it sends, EXCEPT for the acks.
>
> Unfortunately it can not, because -xfer sees only already encrypted
> packets, which lacks packet type identification. It does not know what
> it transfers. Or we have to keep some state, list of encrypted ACK
> packets that can be safely removed, that leads to current workflow again.

Ahh, OK, that makes sense.

Thanks,

- John

  reply	other threads:[~2023-08-10  2:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-11 14:28 Suggestions to make ACK easier John Goerzen
2023-07-11 15:55 ` John Goerzen
2023-07-30  7:47 ` Sergey Matveev
2023-08-09 12:04 ` Sergey Matveev
2023-08-10  2:04   ` John Goerzen [this message]
2023-08-13 20:30     ` Sergey Matveev
2023-09-13 17:29       ` John Goerzen