API Transport.has_path & Transport.request_path

[ThomasFreedman]

Can anyone explain why RNS.Transport.has_path always returns False in the following situation?

App A is connected to app B thru an intermediate transport node using TCP client / server interfaces. 3 nodes in total are involved in this test.

1. app A anounces
2. app B creates a link to app A, and calls RNS.Link.identify
3. app A accepts it
4. app B makes a request to app A
5. app A responds to the request

Clearly a path exists between app A and app B, which is established by step 1.

When app A responds to app B in step 5, it creates a destination to app B using the request handler's "remote_identity" argument and tests for a path which fails. It also saves the destination hash for app B to disk.

appB_dest = RNS.Destination(remote_identity, RNS.Destination.OUT, 
                            RNS.Destination.SINGLE, "myAppName")
            print(RNS.Transport.has_path(self.DSdest.hash))
            dest = RNS.prettyhexrep(appB_dest.hash)
            with open("/tmp/appBaddr.hash", 'w') as ds: ds.write(dest)

I verified the address and identity hashes used in app A's request handler are identical to that printed by app B when it starts up.

I also ran the following code within app A and consistently get the same results as I get when I run it in Pycharm's Python Console:

>>> import RNS
>>> RNS.reticulum()
>>> dest = bytes.fromhex("<ed29...6789>"[1:-1])
>>> print(RNS.Transport.has_path(dest))
False
>>> RNS.Transport.request_path(dest))
>>> print(RNS.Transport.has_path(dest))
False
...

Nothing appears in either RNS logfile for app A or B, nd no errors are displayed.

Questions:
1 - Is the path created by the announce of step 1 bidirectional, meaning either app A or app B could create a Link to the other?

2 - Why doesn't the call to RNS.Transport.request_path signal the intermediate transport node to "announce the path" between app A and app B, and why does the call to RNS.Transport.has_path fail?

3 - Does RNS.Transport.request_path(address) establish a path (route) like an Announce does, or does it only query nodes to report if they "know of" the address?

I'm very perplexed why I can't get app A to successfully create a link to app B knowing app B's address and identity.

[SebastianObi]

Hello Thomas,

I have been programming my own application for a while. I try with my best knowledge to answer your questions. If I have misunderstood, someone can correct this.

1
There are no bidirectional paths in Reticulum. Both apps must always send an announcement of their destination.
App A sends an announce.
App B can connect to app a.
(App A cannot connect to app b)
App B sends an announce.
App A can connect to App B.

2
" RNS.Transport.request_path" should actually request the path to app B.
You need to add a queue to wait some time before checking the path with "RNS.Transport.has_path". If this is done directly after the request there is of course no path yet.

Check the interface mode settings of the "3th (transport node)".
Not all interface modes forward path requests. With the default mode "full" no path requests are forwarded.
Change it to "gateway".
https://markqvist.github.io/Reticulum/manual/interfaces.html#interface-modes

3
You are right.
It only query nodes to report if they "know of" the address.
Therefore the 3rd (transport node) must have already heard an announce or must forward the path request. (See answer 2 with the interface mode)

I hope I could help you

[SebastianObi]

I'm not sure if this "request_path" works as far as App B. Generally every destination (also the App B) must send an announce. Only then this destination is reachable in the Reticulum network. Sending an Announce is the basic concept of Reticulum.

Therefore the App B should simply send an announce at startup and/or periodically.

If App A doesn't need to reach App B at any time, you could simply send a regular resource request from App B to App A asking for new/changed data.

Or take a look at the "channel/buffer". A bidirectional channel from App B to App A is established and kept active. App A can then send data to App B via this channel.
https://github.com/markqvist/Reticulum/blob/master/Examples/Buffer.py

[SebastianObi]

About the problem from Winu:
There was no real problem. A few months ago the path request did not work. Then I became aware of the "interface modes", which were the solution for this scenario. It makes sense that the default mode is "full". Forwarding path requests over slow links doesn't make sense. Especially if nodes are running all the time, at some point each announcement will be recognized and saved.

BTW: The announcements are probably only saved for a certain time and then discarded. Somewhere in the manual i seen that each application should send an announcement every 7 days.

[ThomasFreedman]

It appears that a path_request doesn't replace announces to establish a path, that's what I'm discovering. If that is true, announces are ESSENTIAL for all nodes that want to be known and that is not stated clearly in the documentation.

It actually isn't difficult at all to create a periodic announce, if that's all it will take to establish a path/route that allows app A to setup a link to app B.

I have a bias stuck in my head that app A needs to respond to announcements (which it doesn't) because that is how app B responds to app A's announcements. If all I need to do to create a path that app A can use to establish a link to app B is have app B make announcements, my problem will be solved.

However, it doesn't really make sense that should be the case. If app A's announce is received by app B (and app B responds to it), why wouldn't that announce from A to B create a path from A to B, it's the same direction? That is very counter-intuitive and not obvious. That app B needs to send announces (and apparently request_path made by app A to B won't do it) is just not clear.

What's the purpose of request_path if it can't even validate or create a path between 2 nodes that have an operational and active link between them? If a link exists then clearly an actual path for communications must, even if Reticulum doesn't say it has a "path" !

The crux of the problem seems to be the NON-bidirectional functionality of path routes. I don't know the details of why it isn't bidirectional, perhaps there are important reasons for that. I hope Mark will chime in here to enlighten us all. But it isn't obvious and more needs to be said about paths in the docs to clarify that and the (apparently) essential need for every node to make announcements if it expects to be known in the Reticulum network.

I have already implemented a significant amount of code in app A use request_path and check periodically for has_path to return true before app A attempts to create a link to app B. That would be important if it had anything to do with obtaining a path, but it doesn't look like it does much good.

If app B sends an announce every day and app A always has a path to app B and thus doesn't call request_path, all of that code could be removed.

Consider a case where app B is a service provider that wants to remain private, only responding to others that have privately contracted with app B for the service it provides. If Reticulum is going to be useful to that service provider they will need to make announcements and thus publicize their existence to the world, "blowing their cover" and at a minimum reducing their privacy and potentially anonymity over time. That is just a quickly contrived scenario, there may be other considerations that make RNS unsuitable for such a privacy oriented service like app B (just using app A & B to illustrate, that isn't applicable to my app).

[ThomasFreedman]

I have verified that by adding an announce to app B app A can create a link, but it also requires app A call RNS.Transport.request_path before .has_path will return True. Therefore the code I was referring to above that manages the request_path & waits for it before attempting to create a link is necessary after all.

Through this particular problem I've come to realize that my way of asking questions and working through issues can come across to others not with curiosity and merely seeking answers, but rather with a negative tone that suggests "it shouldn't be this way". I see that now and for that I appologize. Mark has done an amazing job bringing RNS to the world and despite my poor way of asking questions I am truly grateful.

If anyone else should happen to suffer from the same confusion I have experienced on the essential nature of announcements for ALL RNS nodes or the use of has_path and request_path, this thread will hopefully help to clear it up.

[SebastianObi]

Mark has done an excellent job with the development of RNS. It is very complex and takes some time to understand how everything works and why it works the way it does. The documentation is very detailed. Perhaps a little too much for the basic start.

For me, some things also looked like a bug or illogical. Because I had not understood it. Mark has put a lot of thinking into how RNS works. It's not as simple as you might think.

I think there are no bidirectional paths because one of the features of RNS is "Initiator anonymity, communicate without revealing your identity". Therefore, the sender is always anonymous and there is no path to them.