-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ipfs pubsub for not directly connected nodes #5567
Comments
This should work, usually. We (go-ipfs) use the DHT to rendezvous. However, this happens in the background and may take a while. There's also a race: if both peers start at the same time, they may not find each other. Have you actually run into this issue? |
I haven't been able to make I left |
So, I can't seem to connect to any nodes listening on But yeah, I'll admit that pubsub rendezvous needs to be significantly more reliable. |
Not sure if I'm behind a NAT. I've checked this on the WebRTC Trickle ICE test app, which sends a request to a STUN server, and it returned a single IPv4 address in the 50.x.x.x range. This must be a public address. |
(resurrecting this thread) So, that doesn't mean you're not behind a NAT. It just means that either you or your NAT has a public IP address (required to use the internet). What's the output of |
|
Is your node online? It doesn't have any addresses. |
Now it's online:
|
Hi @Stebalien @klueq I don't know your use case, but if your able, running a private network fixes the slow publish times. Windows 10 x64
|
I played around a bit and when I start 5 nodes, only two receive a message, strangely enough after restarting all, the same two nodes continue to receive messages. |
Can you try go-ipfs master? We had some issues tracking connected peers that were recently fixed. |
So, compiled master from source, no change. Didn't test on network, currently upgrading/replacing machines, once done I'll try again with physical ones, expect some follow up end of the week. |
Wait, what ports are your nodes running on? |
On the local machine it starts from 5001, 4001 and increases by one every node. |
Got it. I wanted to make sure you weren't reusing ports. Unfortunately, because we're intentionally setting the REUSEPORT option, multiple daemons running as the same user can end up taking the same port. |
Hi @Stebalien , sorry if this is considered a dead thread but I've been developing an application using the docker image for go-ipfs version 0.4.18 and have been experiencing this issue. Both nodes on my network have several hundred peers in their Are there any recent thoughts or developments on this? Or any way to force my nodes to mainain a direct connection for the meantime? Thanks |
Yes, actually. There has been some work on integrating the peer discovery system deeper into pubsub to make sure we're always connected to some set of peers (libp2p/go-libp2p-pubsub#184). |
Fixed in 0.5.0 |
Afaik, the current implementation of pubsub expects all the nodes interested in the topic to be directly connected with each other. This means that if two random nodes that haven't talked before subscribe to the same topic and one node publishes a message, the other node won't get it. It would be nice to enable this, though.
The text was updated successfully, but these errors were encountered: