-
Notifications
You must be signed in to change notification settings - Fork 60
Error "No content routers available" calling provide() in browser #221
Comments
Related issue about 60 second delay in test procedure libp2p/js-libp2p#950 |
Related issue about insecure https problem libp2p/js-libp2p-webrtc-star#360 |
Hello @mcclure Content Routers need to be specified in libp2p configuration: https://github.com/libp2p/js-libp2p/blob/master/doc/CONFIGURATION.md#setup-with-content-and-peer-routing The error states that you have any module to use. I see you added the DHT, but this should only work if it is enabled in the config as well: https://github.com/libp2p/js-libp2p/blob/master/doc/CONFIGURATION.md#customizing-dht Bear in mind that the DHT implementation is not stable and not recommended at all in the browser due to all the limitations in this environment. You should rely on a delegated content router here |
Thanks so much, adding dht:enabled:true resolved the problem and I can now do successful DHT lookups. I see now that this flag is in the documentation I linked and I missed the enable:true line near the top. One thing that might have helped here: if the content-routing is able to see that content routers are configured but that they are disabled, the error could say "No content routers available (all disabled)". However due to the modular nature of libp2p, it might not be practical to track this information. If there is not a practical way to improve the error message, then I think this bug should be closed. Also I will look into switching to a delegated content router, thanks. |
Closing this, feel free to open if there is still any problem |
I am working on an app whose basis is one browser tab rendezvousing with another using the libp2p DHT, using a server running the js-libp2p-webrtc-star signaling server and one "bounce" node. To ensure all nodes are participating in the DHT, all nodes (including the bounce server) will only talk to nodes that respond to a shibboleth "hello" protocol. I am able to open two tabs behind a NAT, connect them to each other as peers, and successfully connect using the "hello" protocol. However, when I call
node.contentRouting.provide(cid)
, it throws the exception "No content routers available".Repro
Check out https://github.com/mcclure/ts-hello-bug/tree/dht-content-routers-error , branch dht-content-routers-error. This is a minimal example (my app logic is stripped out, all it does is the DHT connection). You can run this using the instructions in README.md and run.txt but the general idea is you run libp2p sig-server and dht-content-routers-error
scripts/bounce.js
on a server, then open two tabs running the dht-content-routers-error web app with Javascript console open and click "login" on both. Wait 60 seconds (there is a conservatively long delay before provide() is called).When I do this, I get this in the inspector console
Peer
QmP4zqavPJM9t7tM3q2G2hoc7WhRcwfkc2iKvejemqrrtY
in this example is the server and 12D3KooWGwQNDjSj8yww4GRg75ery7SPqgz9gAyh32rxHVBBMnHo is the other tab. "Accepting" means each of the tabs has completed change:protocols for the "hello" protocol. "Publish failure" is the caught exception.Expected behavior
This code does essentially the same thing as part 2 of the peer-and-content-routing example in the js-libp2p example, but in a browser. In the past I have successfully run the 1.js 2.js example code. Either the example is broken when you go to step 2 (provide rather than find peer by peer id), or the example code does not work in the browser. Since the browser tabs are able to connect to each other via the signaling server on my hello protocol, plugin protocols like kad-dht should work just as well.
About SSL:
Note this example is set up totally to use insecure https. Both the signaling server and the bounce server use ws rather than wss. This obviously is not how you'd want to deploy it in the real world, but is the only way I know to set up the test to run from localhost. It is possible the error is due to a browser security measure blocking insecure WS under some specific circumstance. If this is the case, I still think this is a bug, because (1) why would my hello protocol work despite WS limitations but libp2p-kad-dht not? (2) the error message should be clearer in this case.
The text was updated successfully, but these errors were encountered: