public inbox for nncp-devel@lists.cypherpunks.ru
Atom feed
* Questions about nncp-ack and -via
@ 2022-03-09 22:46 John Goerzen
2022-03-13 14:32 ` Sergey Matveev
0 siblings, 1 reply; 2+ messages in thread
From: John Goerzen @ 2022-03-09 22:46 UTC (permalink / raw)
To: nncp-devel
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Questions about nncp-ack and -via
2022-03-09 22:46 Questions about nncp-ack and -via John Goerzen
@ 2022-03-13 14:32 ` Sergey Matveev
0 siblings, 0 replies; 2+ messages in thread
From: Sergey Matveev @ 2022-03-13 14:32 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 4933 bytes --]
Greetings!
*** John Goerzen [2022-03-09 16:46]:
>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?
* When nncp-file is finished on A-node, then spool-of-A/B/tx/ contains
the packet PKT-AB to B-node.
* B-node receives PKT-AB and places it to spool-of-B/A/rx/PKT-AB
* nncp-ack on B-node generates ACK packet to A-node for PKT-AB
* B-node tosses PKT-AB and generates spool-of-B/C/tx/PKT-BC packet
* C-node receives it and places to spool-of-C/B/rx/PKT-BC
* nncp-ack on C-node acknowledges B-node about PKT-BC. It knows nothing
about A-node. nncp-ack looks only on spool/NODE/rx/* packets and ACKs
the NODE
* C-node tosses PKT-BC, generates PKT-CD
* D-node receives PKT-CD, acknowledges C-node
* Although spool-of-D/C/rx/PKT-CD is an inbound-queue of node-C, but
PKT-CD has A-node as the sender
So yeah, currently A-node gets acknowledgement only about PKT-AB
delivery (even not about its tossing).
>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.
Correct. nncp-pkt can be used to view various packet's headers to see
who is the actual sender.
>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:
Also correct. Exactly that case I just used now to check the packets and
behaviour.
>However, maybe nncp-ack is ignoring what's in the packet header and just
>going by which rx directory it's in?
Correct.
I think that nncp-ack can generate an additional ACK packet if received
encrypted packet's sender differs from the node it was get from and if
its type is not "transitional" (so current node is the "final" destination).
D-node sees that PKT-CD's sender is A-node, it is in C-node's rx-queue,
it is not transitional, so it can acknowledge A-node.
But there is complication one have to think about: nncp-ack optionally
takes "-via" and "-node", that are fine when we generate only single
packet. nncp-ack -all do not use "-via" and takes its from the
configuration file. Currently "-node ... -via ..." will be applied to
C-node's ACK packet, but not way to override via for A-node. Actually we
do not know if C-node's rx/ contains packets from A-node. Probably
nncp-ack should check all rx/ directories, parse all headers and so on.
Another complication is that when A-node sends its packet to D-node,
then its tx/ queues has only the packet PKT-AB, but no knowledge about
all intermediate ones and the final PKT-CD. So even if D-node will
acknowledge A-node about PKT-CD, then nncp-toss on A-node just does not
have anything to remove. All of that is solvable somehow of course,
nncp-toss can simply even touch files in some/dir/with/received/ACKs and
external scripts will just check if the required packet is acknowledged.
For example I nncp-file something and wait in cron-ed scripts about
PKT-CD packet's acknowledgement. But currently there is no easy way to
know that PKT-CD's packet identifier, or even PKT-AB's one. One can
parse -debug logging output (that is recfile-format) to find the
packet's hash, but that is not too convenient of course.
And let's not forget that those ACKs only about the delivery, not about
successful tossing. If somebody wishes that kind of ACK, then currently
the only way is to create custom programs/scripts, call them through
nncp-exec, and those scripts must call another nncp-exec that will send
some higher-level (toss) acknowledgement. nncp-toss could send it
automatically if corresponding exec-handler will return successful
return code. But that leads immediately to the desire of sending of NAK
packet, probably containing at least the return code itself and probably
the stderr of the failed exec-handler.
NNCP is a long time not a too Unix-way thing, that actually replaces
gpg/zstd/tar(sometimes)/split and other things that could be used as
external pipes/utilities. So all that ACK/NAKs generated during the toss
of exec-handlers are pretty ok too and I am not against them. But
currently I do not have much ideas and readiness of that kind of
features implementation.
My TODO file have remarks about basically total lack of error handling
(and toss-NAKs can help with that), lack of integration tests (today
only the very first one appeared related to nncp-rm, but I think it
won't work anywhere outside FreeBSD or BSD systems at all :-)), area's
authorization subject and some other issues. So there are many things
needed to be done.
--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2022-03-13 14:32 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-09 22:46 Questions about nncp-ack and -via John Goerzen
2022-03-13 14:32 ` Sergey Matveev