Tari services and comms on the futures 0.3 runtime #621
Comments
This was referenced Aug 14, 2019
This was referenced Aug 16, 2019
CjS77
added a commit
that referenced
this issue
Aug 22, 2019
Merge pull request #686 Description LivenessHandler connected up to a stream of PingPong messages Refactored the way services are initialized, keeping it super simple and to allow more flexibility Tari Services are one or more (usually) long-running asynchronous tasks which furnish request via a provided interface (called a Handle). Dropping the handle must cancel the task. This is (usually) implemented using an mpsc channel and/or subscription stream. That is, once all senders have disconnected, the receiver stream will close and so will the task. Services usually subscribe to one or many comms messages and update state or perform operations as necessary. Services are set up by implementing the ServiceInitializer trait - this trait can be passed to the StackBuilder which is responsible for initializing the services and signalling when all services are initialized. Services can access other service handles allowing them to make requests on other services. This is done by retrieving the appropriate handle from the ServiceHandles collection which is provided to every ServiceInitializer. Handles can easily (but not necessarily) be implemented by using the tari_p2p::executor::transport::channel(S) function. This function takes in a service S and returns a Requester/Responder pair - the requester can be used to make asynchronous requests to the given service S. A handle, however, can be implemented in whatever way the service implementer sees fit. Motivation and Context Closes #676 Ref #621 How Has This Been Tested? Unit tests (integration tests to follow)
11 tasks
This was referenced Sep 3, 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 19, 2019
This was referenced Oct 1, 2019
Merged
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Migrate tari services and comms to use the tokio runtime and tower-rs
The text was updated successfully, but these errors were encountered: