public inbox for nncp-devel@lists.cypherpunks.ru
Atom feed
* Two Different Routes to the Same Node, One with Via
@ 2021-12-10 4:13 Koushik Roy
2021-12-12 17:33 ` Sergey Matveev
0 siblings, 1 reply; 6+ messages in thread
From: Koushik Roy @ 2021-12-10 4:13 UTC (permalink / raw)
To: nncp-devel
Hey,
I'm in a situation where I have two different routes to the same node,
but in one case the node is not directly accessible and the other case
it is.
The case is simple. I have a box Foo, a box Bar, and a relay box Baz
which has a WAN routable IP. Foo is a laptop and I usually am home with
it, and Foo is on my LAN. Bar is a stationary box that sits on my
LAN. Bar is not accessible through a WAN. Normally Foo can directly
access Bar via the LAN. However, when I travel with Foo, Foo cannot talk
to Bar directly. Instead I use the relay host Baz; Foo sends a packet to
Baz and then Baz relays the packet to Foo.
Right now it doesn't seem possible to have two different paths when one
includes a "via" block. In the meantime, I always use Baz as a relay,
even when Foo and Bar can talk to each other over the LAN because it
simplifies configuration and I'm not in a rush for NNCP packets to make
it from Foo to Bar. Would it be possible to add support for
distinguishing between a direct connection to a neighbor node and a
relay connection to the node? Also, I could make an attempt at modifying the
source myself and submit a patch if you are open to it.
Thanks,
Koushik
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Two Different Routes to the Same Node, One with Via
2021-12-10 4:13 Two Different Routes to the Same Node, One with Via Koushik Roy
@ 2021-12-12 17:33 ` Sergey Matveev
2021-12-12 20:52 ` John Goerzen
0 siblings, 1 reply; 6+ messages in thread
From: Sergey Matveev @ 2021-12-12 17:33 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 2668 bytes --]
Greetings!
*** Koushik Roy [2021-12-09 20:13]:
>Right now it doesn't seem possible to have two different paths when one
>includes a "via" block.
But it can be overriden per every nncp-* command invocation via "-via" option.
>Would it be possible to add support for
>distinguishing between a direct connection to a neighbor node and a
>relay connection to the node?
Problem here is that process of encryption packet creation is
independent and asynchronous to the process of transmitting those
packets. "Routing" information is applied before creating the
encrypted packet: so "via" works when nncp-file/exec/freq are called.
And they do not know anything about the transport will be used further.
So I honestly do not see how those "abstractions" (packet transfer and
packet creation) can be joined together.
Well, of course there can be some kind of hackish way to do that, for
example instead of invoking the "nncp-file ...", you call "nncp-file
-via `my-dynamic-routing.sh DST` ...", where "my-dynamic-routing.sh"
script will ping/curl/whatever the DST host to determine its
availability and return the route path. But... that DST can be
temporarily down. You can leave the LAN after 5 seconds after
my-dynamic-routing.sh was invoked. I think it won't be satisfactory.
Subject of dynamic routing was asked not the first time, but still I
just have not thought about it much, because even in your simple case (I
have exactly the same at home too and I just use "Baz" all the time) it
is not obvious to express what behaviour I want, because of that
asynchronous and independent nncp-* invocation and transport processes.
Currently I assume that multicast can be used in the case you described.
I did not check it and can not tell is it stupid idea, but I believe
that you can create multicast area and subscribe Foo, Bar, Baz on it.
Then you send file/exec/whatever to that area. When you are on LAN, then
both Bar and Baz receives it. After a while Bar will receive the same
multicasted packet from Baz, but will delete it, because it was already
seen after processing the packet got directly from Foo. When you are on
WAN, then packet to Bar is queued, but packet to Baz is sent (and Bar
receives it). When you are back at LAN, then you send previously queued
packet to Bar, that is deleted on it, because it was seen from the Baz.
Of course that doubles the real amount of traffic and disk consumption
on some nodes, so hardly it is helpful :-), but it can deliver packets
directly to Bar faster.
--
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] 6+ messages in thread
* Re: Two Different Routes to the Same Node, One with Via
2021-12-12 17:33 ` Sergey Matveev
@ 2021-12-12 20:52 ` John Goerzen
2021-12-13 6:58 ` Koushik Roy
0 siblings, 1 reply; 6+ messages in thread
From: John Goerzen @ 2021-12-12 20:52 UTC (permalink / raw)
To: Sergey Matveev; +Cc: nncp-devel
On Sun, Dec 12 2021, Sergey Matveev wrote:
> Currently I assume that multicast can be used in the case you described.
> I did not check it and can not tell is it stupid idea, but I believe
> that you can create multicast area and subscribe Foo, Bar, Baz on it.
> Then you send file/exec/whatever to that area. When you are on LAN, then
> both Bar and Baz receives it. After a while Bar will receive the same
> multicasted packet from Baz, but will delete it, because it was already
> seen after processing the packet got directly from Foo. When you are on
> WAN, then packet to Bar is queued, but packet to Baz is sent (and Bar
> receives it). When you are back at LAN, then you send previously queued
> packet to Bar, that is deleted on it, because it was seen from the Baz.
> Of course that doubles the real amount of traffic and disk consumption
> on some nodes, so hardly it is helpful :-), but it can deliver packets
> directly to Bar faster.
This is a really interesting point; as I was reading this, I was
thinking "the packet could be encrypted to both the destination and the
relay when it's created" but multicast can effectively achieve this
also.
Actually all that is needed to support Koushik's scenario perfectly
would be a "max delivery" setting. Set it to 1, and after NNCP delivers
a multicast packet to one destination, it would stop efforts to deliver
it to any more.
I also have the same use case Koushik identified and this would be
perfect there.
- John
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Two Different Routes to the Same Node, One with Via
2021-12-12 20:52 ` John Goerzen
@ 2021-12-13 6:58 ` Koushik Roy
2021-12-15 8:38 ` Sergey Matveev
0 siblings, 1 reply; 6+ messages in thread
From: Koushik Roy @ 2021-12-13 6:58 UTC (permalink / raw)
To: John Goerzen, Sergey Matveev; +Cc: nncp-devel
John Goerzen <jgoerzen@complete•org> writes:
> On Sun, Dec 12 2021, Sergey Matveev wrote:
>
>> Currently I assume that multicast can be used in the case you
>described.
I'll give this approach a shot. It sounds promising, and in my case
repeating a packet twice doesn't really matter that much as I'm sending
small packets anyway.
> Actually all that is needed to support Koushik's scenario perfectly
> would be a "max delivery" setting. Set it to 1, and after NNCP delivers
> a multicast packet to one destination, it would stop efforts to deliver
> it to any more.
>
This would be a cool feature, but how would you be able to enforce "max
delivery" across multiple neighbors?
- Koushik
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Two Different Routes to the Same Node, One with Via
2021-12-13 6:58 ` Koushik Roy
@ 2021-12-15 8:38 ` Sergey Matveev
2021-12-17 0:03 ` John Goerzen
0 siblings, 1 reply; 6+ messages in thread
From: Sergey Matveev @ 2021-12-15 8:38 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 1096 bytes --]
*** Koushik Roy [2021-12-12 22:58]:
>This would be a cool feature, but how would you be able to enforce "max
>delivery" across multiple neighbors?
I have got the same question. We have to keep the state of number of
deliveries per area message. There is also always race: probably you
connect to Baz a second earlier than to a Bar directly. What to do if
caller connects to both Baz and Bar -- should it "lock" encrypted packet
transmission because it want to send it at most once? What if
transmission is interrupted: for example you begin sending packet to
Bar, but then you go outside LAN and only Baz (via WAN) will be
accessible for a long time. Should the packet be in "locked" state?
Moreover hypothethical locks depend on encrypted packet's content
(decrypted area message), leaking some knowledge that it is some kind of
special. There are too many questions, and hardly they are easy to
answer with confidence. All of that smells like huge complication :-)
--
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] 6+ messages in thread
* Re: Two Different Routes to the Same Node, One with Via
2021-12-15 8:38 ` Sergey Matveev
@ 2021-12-17 0:03 ` John Goerzen
0 siblings, 0 replies; 6+ messages in thread
From: John Goerzen @ 2021-12-17 0:03 UTC (permalink / raw)
To: Sergey Matveev; +Cc: nncp-devel
On Wed, Dec 15 2021, Sergey Matveev wrote:
> *** Koushik Roy [2021-12-12 22:58]:
>>This would be a cool feature, but how would you be able to enforce "max
>>delivery" across multiple neighbors?
>
> I have got the same question. We have to keep the state of number of
> deliveries per area message. There is also always race: probably you
> connect to Baz a second earlier than to a Bar directly. What to do if
> caller connects to both Baz and Bar -- should it "lock" encrypted packet
> transmission because it want to send it at most once? What if
> transmission is interrupted: for example you begin sending packet to
> Bar, but then you go outside LAN and only Baz (via WAN) will be
> accessible for a long time. Should the packet be in "locked" state?
> Moreover hypothethical locks depend on encrypted packet's content
> (decrypted area message), leaking some knowledge that it is some kind of
> special. There are too many questions, and hardly they are easy to
> answer with confidence. All of that smells like huge complication :-)
You may be right. If the "max delivery" were also 1 on the
receiving end, it would know it received it from 1 node and then not
pass it on, right?
But you are right to raise those questions about partial delivery and
such. In my scenario, that wouldn't happen, but there's nothing about
the tooling to prevent it, indeed.
John
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-12-17 0:04 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-10 4:13 Two Different Routes to the Same Node, One with Via Koushik Roy
2021-12-12 17:33 ` Sergey Matveev
2021-12-12 20:52 ` John Goerzen
2021-12-13 6:58 ` Koushik Roy
2021-12-15 8:38 ` Sergey Matveev
2021-12-17 0:03 ` John Goerzen