public inbox for nncp-devel@lists.cypherpunks.ru
Atom feed
From: John Goerzen <jgoerzen@complete•org>
To: nncp-devel@lists.cypherpunks.ru
Subject: Questions about nncp-ack and -via
Date: Wed, 09 Mar 2022 16:46:41 -0600	[thread overview]
Message-ID: <87h786u4ku.fsf@complete.org> (raw)

Hi!

I've been thinking about nncp-ack a bit.  It is working fine for my use
case, and now I'm thinking about other interesting possibilities for it.
So let me start with a question.  Let's say there are four nodes, and to
get a packet from node A to node D, it has to go via B and C.  That is:

A$ nncp-file -via B,C foo.txt D:

So, A->B->C->D.

Let's further assume each of these nodes runs nncp-ack.  So here's how
it boils down  on each one:

A: originates the packet, nothing to ack
B: acks to A
C: I'm not sure.  Does it ack to B or to A?
D: Also not sure.  Does it ack to C or to A?

In the case of, say, node D, I could see value in ACKing to C as well as
value in ACKing to A.

ACKing to C could be useful in the nncp-xfer or bundle case as we
recently discussed.

ACKing to A could be useful because that might facilitate a case where A
keeps the data sent until it affirmatively knows that it has arrived at
its destination (somewhat hypothetical, as the tooling to deal with an
end-to-end retransmit isn't really there [eg, caller deletes packets
after sending, if B uses -seen it wouldn't handle a retransmit, etc --
enough complexity that it's probably not worth adding])

My understanding of the packet format - and this may be incorrect - is
that in the specific case I outlined, every node - B, C, and D will have
A as the sender in the header of the packet they process, since A
generates every layer of encryption along the way.

However, I think that's not necessarily the case.  If, say, B's neigh
block for D says:

  via: ["C"]

then A could just say:

A$ nncp-file -via B foo.txt D:

And when it arrives on B, B would generate the encryption layer for the
B->C trip.  So the header senders would be:

A: n/a
B: A
C: B
D: A

However, maybe nncp-ack is ignoring what's in the packet header and just
going by which rx directory it's in?  In that case, the sender would be:

A: n/a
B: A
C: B
D: C

Just spinning some wheels thinking about all this!

Thanks,

John

             reply	other threads:[~2022-03-09 22:47 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-09 22:46 John Goerzen [this message]
2022-03-13 14:32 ` Questions about nncp-ack and -via Sergey Matveev