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 12:59:55 -0600	[thread overview]
Message-ID: <87ee3k9o44.fsf@complete.org> (raw)
In-Reply-To: <Yh+7uz07s3QDWFDv@stargrave.org>


On Wed, Mar 02 2022, Sergey Matveev wrote:

> *** John Goerzen [2022-03-02 10:18]:
>>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 honestly forget about an endless reACKing problem. Somehow we must not
> send ACK for an ACK obviously. Currently nncp-ack is a separate command
> call, that just generates ACK for everything it saw in rx-directory.
> nncp-toss is a candidate for that job instead, because it sees the plain
> (unencrypted) packet's type. But that will lead to more configuration
> file's options to control if ACKs need to be generated. However,
> nncp-ack already has access to private keys (that is required to
> generate outbound encrypted packets), so it also can decrypt packets.

Hi Sergey,

I just had another thought - maybe the ideal place to generate ACKs is
in the nncp-xfer/bundle rx code itself?

That would allow it to:

- Generate an ACK for an incoming packet even if there is a .seen for it

- Avoid the race with toss

- Decrypt the first chunk and avoid generating ACKs for ACKs

> Probably, but I do not like that idea at all. Niceness is not a "type of
> the packet", however it is tempting to use it for that. Currently there

Agreed, that is a workaround.

[ regarding toss -cycle ]

I find it very useful for machines that primarily interact via
daemon/call/caller where there is not always a definite "done" state
even.

> So currently I see two relatively simple changes I have to done:
>
> * nncp-ack must (partly) decrypt packets, to determine if it ACK and skip it
> * nncp-ack must generate list of generated ACK encrypted packets, to use
>   it at least with nncp-rm, to be able to remove them after xfer transfer.
> * nncp-rm could take a list of PKTs from stdin for convenience there
> * probably nncp-xfer can take a list of packets (from the file/stdin) to
>   skip. To be able to leave ACK packets in the spool just for a while
>
> nncp-ack won't generate ACK for ACK, fixing the biggest problem.

So generating ACKs in nncp-xfer/bundle still leaves the problem of keep
for them.  Maybe the answer would be a simple option to xfer/bundle tx:
-always-delete-sent-acks or something.  Then an ACK that's transmitted
would always be deleted, regardless of -keep.  Combined with -seen for
toss, that should provide good behavior in all cases.  (If an ACK is
lost, the sender will retransmit the packet, but since it's already been
seen, the recipient will immediately generate a new ACK)

- John

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