-
Notifications
You must be signed in to change notification settings - Fork 187
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
with gossipsub subscribers may not receive the first couple of messages #331
Comments
This is probably because "peers" is all peers we know that speak the topic while we really care about "grafted peers". There's a new publish option |
Yes, it will take a heartbeat for the new peer to get grafted, which is by default 1s. |
Is changing pubsub.peers() to grafted an option? |
Well, |
@vyzo that sounds great! @Stebalien is this something we can bubble up to go-ipfs ? maybe in a arg like |
We shouldn't need to wait. |
This needs to be fixed the right way: ipfs/kubo#7350 |
where can i follow this issue? the one you mentioned is already closed does that mean its already in master ? |
Actually, the delay has been fixed in v0.3.0: So when we join, we immediately graft some peers. |
This is biting us in the interop tests too, where the delay needs to be longer than 2s, more like As it's fixed in go-libp2p-pubsub master will the fix ship in go-IPFS 0.6.x? |
Because of libp2p/go-libp2p-pubsub#331 we have to wait for a the gossipsub peer to become grafted before sending messages we expect to be recieved. There's no way to tell from the API which peers are grafted so we just have to add an abitrary wait and hope it happens during that time window. Also refactors the pubsub tests to remove duplicated code.
Because of libp2p/go-libp2p-pubsub#331 we have to wait for a the gossipsub peer to become grafted before sending messages we expect to be recieved. There's no way to tell from the API which peers are grafted so we just have to add an abitrary wait and hope it happens during that time window. Also refactors the pubsub tests to remove duplicated code and the ipns-pubsub tests to use named variables instead of array indices for readability.
It looks like these interop tests are failing with go-IPFS master, even though the build step says it succeeded: https://app.circleci.com/pipelines/github/ipfs/go-ipfs/2908/workflows/0b7a5ebf-cb6c-4960-b19e-fd4c1b61983c/jobs/34278 |
Would it please be possible to have some way of getting the list of peers who are likely to receive a pubsub message for a given topic? That would unblock us and fix the interop tests which can then be made to fail the go-ipfs build if compatibility is broken again. Getting a list of peers for a topic when those peers may not receive a message sent to the topic because they aren't grafted is not very useful. |
Actually, if you enable flood publishing in gsv1.1 ( We can still add a |
I think if you provide a method that claims to return the peers subscribed to a topic, then send a message to that topic and those peers do not receive the message, the user is likely to encounter significant surprise. |
Yes, that's true -- we'll have to update if we add a different interface. But I really do recommend enabling flood publishing, it's a security feature of the protocol. |
Flood publishing for the first hop sounds reasonable. |
|
While trying to sync js repos with go-ipfs 0.5.x i notice pubsub tests were failing for js-ipfs-http-client the specific test works like this:
So this test started to fail with go-ipfs 0.5 talking to @aschmahmann we discovered that this behaviour is due to 0.5 defaulting to gossipsub because with floodsub the test passes.
To make the test pass with gossipsub i needed to add a ~2s (may work with less just a random number) delay between step 3 and 4.
Can we remove the need for that delay and make gossipsub work like floodsub ?
issue ipfs/js-ipfs#3030
pr ipfs/js-ipfs#3013
The text was updated successfully, but these errors were encountered: