Skip to content
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

Gossip swallows unicast errors #1513

Open
vistra opened this issue Dec 26, 2019 · 5 comments
Open

Gossip swallows unicast errors #1513

vistra opened this issue Dec 26, 2019 · 5 comments

Comments

@vistra
Copy link
Collaborator

vistra commented Dec 26, 2019

#1504 changed the behaviour of gossip multicast so it will attempt transmitting to the entire list instead of stopping on the first failure. As a side effect, the multicast call does not return an error even if some of the transmissions failed.
Since unicasts are implemented as a multicast to a list of length 1, the resulting behaviour hides unicast errors.

Some possible solutions are:

  • Create a separate unicast API that can return an error
  • Change the multicast behaviour to return an error in case of a list of length 1
  • Change the multicast to return a list of errors, one for each transmission failure
@electricmonk electricmonk removed their assignment Dec 26, 2019
@electricmonk
Copy link
Contributor

@OdedWx do you have a preference here? I'm in favor of a separate unicast API, but I could live with a list of errors as well.

@netoneko
Copy link
Contributor

netoneko commented Dec 27, 2019

Do you guys think it would make sense to move to something more established, like libp2p?

I am asking this because we will inevitably solve the same problems that authors of libp2p faced in the past, and IPFS uses it successfully in production.

Do we really have to build our own network stack? Maybe we should research the alternatives.

@electricmonk
Copy link
Contributor

it's actually not a bad idea, instead of developing real p2p (relay) capabilities

@netoneko
Copy link
Contributor

This error did come back to bite us in relation to #1526: the halving of the chunks never happened because we never returned an error that would trigger it.

@netoneko
Copy link
Contributor

Relevant conversation: #1514

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants