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

refactor(bitswap) internal notifications #50

Closed
wants to merge 4 commits into from

Conversation

btc
Copy link
Contributor

@btc btc commented Sep 11, 2014

@whyrusleeping @jbenet

Context: In the bitswap subsystem, local actors block in GetBlock waiting on a message from the network. When results are received, a different actor receives the value and must dispatch to all waiting subcribers. If within the deadline, the GetBlock subscriber receives the retrieved value.

This PR introduces a simplified interface for this internal communication.

Insights:

  • Within bitswap, the actors don't need anything more than simple pubsub
    behavior. Wrapping and unwrapping messages proves unnecessary.

Changes:

  • Simplifies the interface for both actors calling GetBlock and actors
    receiving blocks on the network
  • Leverages a well-tested third-party pubsub library

Design Goals:

  • reduce complexity
  • extract implementation details (wrapping and unwrapping data, etc)
    from bitswap and let bitswap focus on composition of operations

Brian Tiger Chow added 4 commits September 11, 2014 16:38
use a third-party pubsub library for internal communications

Insights:
* Within bitswap, the actors don't need anything more than simple pubsub
behavior. Wrapping and unwrapping messages proves unneccessary.

Changes:
* Simplifies the interface for both actors calling GetBlock and actors
receiving blocks on the network
* Leverages a well-tested third-party pubsub library

Design Goals:
* reduce complexity
* extract implementation details (wrapping and unwrapping data, etc)
from bitswap and let bitswap focus on composition of core algorithms
operations
@btc
Copy link
Contributor Author

btc commented Sep 12, 2014

In the framework introduced by https://github.com/jbenet/go-ipfs/tree/net, GetBlock is implemented synchronously. There's no need for communication between a handler and a caller. The async behavior is an implementation detail of net/service/SendRequest interface.

recall:

  • handler listens to incoming messages
  • caller waits for block

Closing this for now.

@btc btc closed this Sep 12, 2014
laurentsenta pushed a commit to laurentsenta/kubo that referenced this pull request Feb 25, 2022
…/libp2p/go-libp2p-core-0.2.3

Bump github.com/libp2p/go-libp2p-core from 0.2.2 to 0.2.3
laurentsenta pushed a commit to laurentsenta/kubo that referenced this pull request Feb 25, 2022
…dules/github.com/libp2p/go-libp2p-core-0.2.3

Bump github.com/libp2p/go-libp2p-core from 0.2.2 to 0.2.3
ariescodescream pushed a commit to ariescodescream/go-ipfs that referenced this pull request Apr 7, 2022
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

Successfully merging this pull request may close these issues.

1 participant