public inbox for nncp-devel@lists.cypherpunks.ru
Atom feed
* Some questions about areas
@ 2021-08-17  5:19 John Goerzen
  2021-08-17 18:35 ` Sergey Matveev
  0 siblings, 1 reply; 4+ messages in thread
From: John Goerzen @ 2021-08-17  5:19 UTC (permalink / raw)
  To: nncp-devel

Hello,

I'm working on a tool to use NNCP areas to facilitate syncing of 
git repos.  I'm pretty excited about this use case.

I have a few questions - perhaps the answers would also make good 
additions to the documentation.

1) What is the interaction between "subs" and "via"?  If I list a 
node in subs and have a default via for it elsewhere in the 
config, is that via used?

2) I'm a little unclear on the difference between having a machine 
that lacks the keypair and one that lacks the area entirely.  I 
think it may have something to do with the answer to #1?  Is it 
that such a machine can only route packets in a traditional "via" 
way?  (That is, the originator of the packet [or some other 
area-aware system] would have to do the routing to end nodes 
directly?)

Thanks,

John

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Some questions about areas
  2021-08-17  5:19 Some questions about areas John Goerzen
@ 2021-08-17 18:35 ` Sergey Matveev
  2021-08-17 21:04   ` John Goerzen
  0 siblings, 1 reply; 4+ messages in thread
From: Sergey Matveev @ 2021-08-17 18:35 UTC (permalink / raw)
  To: nncp-devel

[-- Attachment #1: Type: text/plain, Size: 1250 bytes --]

Greetings!

*** John Goerzen [2021-08-17 00:19]:
>1) What is the interaction between "subs" and "via"?  If I list a node in
>subs and have a default via for it elsewhere in the config, is that via
>used?

Yes, "via" is applied everywhere where packet sending happens.
Everything listed in "subs" is used as a destination for every
copy of relayed area packet.

>2) I'm a little unclear on the difference between having a machine that
>lacks the keypair and one that lacks the area entirely.

The one that lacks the area entirely can not do with the packet anything
at all. It just can tell that "I see some area packet, and won't/can't
do anything with it". If you add area knowledge (its area id), then you
can at least create copied of the encrypted area packet to everyone in
"subs". You can relay it, that is treated like successful processing.
Adding keypair gives ability to decrypt that area packet for storing the
file/exec transmissions.
No keypair -> you can still relay packets.
No area knowledge at all -> you can only drop that packets.
No "via" and routing plays any special role in multicast areas.

-- 
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] 4+ messages in thread

* Re: Some questions about areas
  2021-08-17 18:35 ` Sergey Matveev
@ 2021-08-17 21:04   ` John Goerzen
  2021-08-18  7:21     ` Sergey Matveev
  0 siblings, 1 reply; 4+ messages in thread
From: John Goerzen @ 2021-08-17 21:04 UTC (permalink / raw)
  To: Sergey Matveev; +Cc: nncp-devel


On Tue, Aug 17 2021, Sergey Matveev wrote:

>>2) I'm a little unclear on the difference between having a 
>>machine that
>>lacks the keypair and one that lacks the area entirely.
>
> The one that lacks the area entirely can not do with the packet 
> anything
> at all. It just can tell that "I see some area packet, and 
> won't/can't
> do anything with it". If you add area knowledge (its area id), 
> then you
> can at least create copied of the encrypted area packet to 
> everyone in
> "subs". You can relay it, that is treated like successful 
> processing.
> Adding keypair gives ability to decrypt that area packet for 
> storing the
> file/exec transmissions.
> No keypair -> you can still relay packets.
> No area knowledge at all -> you can only drop that packets.
> No "via" and routing plays any special role in multicast areas.

OK, I think I have it.  Let's say you have a machine A, that 
connects to only machine B.  Machine B connects to C, D, and E. 
Like this:

A <-> B <-> [C, D, E]

If there was an area with all of these members, but B not trusted 
to decode, and a packet originating from A, there would be two 
ways to handle it:

1) In A's subs, it's only B.  In B's subs, it's A, C, D, E.  B 
lacks the keys for the area but has the area definition.  When the 
packet originates at A, it is sent only to B, which then explodes 
it to C, D, and E.  C, D, and E would all have just B in their 
subs, which would cause them to not relay the packet any further, 
since they got it from B.

2) Or, B could not know about the area at all.  Every node except 
B would have "via B" on every other node.  The subs on A would be 
C, D, and E.  When creating a packet on A, it would explode it out 
itself, queueing three messages for B: one each for C, D, and E. 
Then, over on, say C, it would receive the packet, and queue up 
what turn out to be duplicates for D and E, routing them via B. 
They'd be ignored on D and E, since they would have already seen 
the original message from A.  The same would happen with nodes D 
and E, creating 6 duplicate packets.

Have I got that right?

So, for a setup like this, it is most efficient to have the 
"untrusted" relay node B be part of the area, but lack the keys.

- John

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Some questions about areas
  2021-08-17 21:04   ` John Goerzen
@ 2021-08-18  7:21     ` Sergey Matveev
  0 siblings, 0 replies; 4+ messages in thread
From: Sergey Matveev @ 2021-08-18  7:21 UTC (permalink / raw)
  To: nncp-devel

[-- Attachment #1: Type: text/plain, Size: 529 bytes --]

*** John Goerzen [2021-08-17 16:04]:
>A <-> B <-> [C, D, E]
>[...]
>Have I got that right?

Yes, everything you wrote is correct.

>So, for a setup like this, it is most efficient to have the "untrusted"
>relay node B be part of the area, but lack the keys.

Yep, also right. The first setup you described (with "keyless" B-node)
is the most efficient from the point of less possible duplicated messages.

-- 
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] 4+ messages in thread

end of thread, other threads:[~2021-08-18  7:42 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-17  5:19 Some questions about areas John Goerzen
2021-08-17 18:35 ` Sergey Matveev
2021-08-17 21:04   ` John Goerzen
2021-08-18  7:21     ` Sergey Matveev