-
Notifications
You must be signed in to change notification settings - Fork 220
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 OMS to futures 0.3 #655
Milestone
Comments
sdbondi
changed the title
Refactor OMS to be a tokio threadpool task
Refactor OMS to use tokio threadpool
Aug 6, 2019
sdbondi
changed the title
Refactor OMS to use tokio threadpool
Refactor OMS to futures 0.3
Aug 28, 2019
CjS77
added a commit
that referenced
this issue
Sep 10, 2019
Merge pull request #747 Added "actor" for connection manager The ConnectionManagerActor receives and furnishes requests to create connections (a.k.a dial) to peers. Requests are made using an mpsc channel and are processed concurrently and asynchonously. This is an async front for a ConnectionManager (which is still synchronous). The OMS will use this to establish connections and allow the implementation to become fully async down the line. To illustrate (does not compile): // Create a requester/actor pair let (requester, actor) = create_connection_manager_actor(/* connection manager goes here */); // Spawn actor task which will respond to requests from the requester tokio::spawn(actor.start()); // Request to dial `node_id` tokio::block_on(async move { if let Ok(peer_connection) = requester.dial_node(node_id).await { println!("Success!") } }); The Dialer trait is an abstraction that allows decoupling and ease of testing. The ConnectionManager implements Dialer. Motivation and Context Ref #709 Ref #708 Ref #621 Ref #655 https://en.wikipedia.org/wiki/Actor_model
This was referenced Sep 12, 2019
CjS77
added a commit
that referenced
this issue
Sep 12, 2019
Created async outbound messsage service Description Created an async outbound message service which is responsible for constructing messages from a broadcast strategy, requesting connections from the ConnectionManager and sending batches of messages. As before, failed connections to a peer are retried using a exponential backoff strategy. Functionally similar to the current OMS, except that it is asynchronous and lock free (it connects and sends messages on two tasks). Currently this is not included in the module tree to keep the PR smaller. A subsequent PR will make use of the async OMS. Motivation and Context Ref #655 Ref #708 How Has This Been Tested? Unit test in the module - subsequent PR will contain integration tests using the new OMS Types of changes
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
No description provided.
The text was updated successfully, but these errors were encountered: