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

Added async request-reply for Tari p2p services #670

Merged
merged 3 commits into from
Aug 15, 2019

Conversation

sdbondi
Copy link
Member

@sdbondi sdbondi commented Aug 14, 2019

Description

This PR contains the building blocks for async p2p services.

It consists of the following modules:

  • builder: contains the MakeServicePair trait which should be implemented by a service builder and theStackBuilder struct which is responsible for building the service and making service handles available to all the other services. Handles are any object which is able to control a service in some way. Most commonly the handle will be a transport::Requester<MyServiceRequest>.
  • handles: struct for collecting named handles for services. The StackBuilder uses this to make all handles available to services.
  • transport: This allows messages to be reliably send/received to/from services. A Requester/Responder pair is created using the transport::channel function which takes an impl of tower_service::Service as it's first parameter. A Requester implements tower_service::Service and is used to send requests which return a Future
    which resolves to a response. The Requester uses a oneshot channel allow responses to be sent back. A Responder receives a (request, oneshot::Sender) tuple, calls the given tower service with that request and sends the result on the oneshot::Sender. The Responder handles many requests simultaneously.

Notes:

TODO:

Motivation and Context

Ref #654
Epic #621

How Has This Been Tested?

Relevant unit tests

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Feature refactor (No new feature or functional changes, but performance or technical debt improvements)
  • New Tests
  • Documentation

Checklist:

  • I'm merging against the development branch
  • I ran cargo-fmt --all before pushing
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have added tests to cover my changes.

This PR contains the building blocks for async p2p services.

It consists of the following modules:
- `builder`: contains the `MakeServicePair` trait which should be implemented by a service builder and the
`StackBuilder` struct which is responsible for building the service and making service _handles_ available to all
the other services. Handles are any object which is able to control a service in some way. Most commonly the
handle will be a `transport::Requester<MyServiceRequest>`.
- `handles`: struct for collecting named handles for services. The `StackBuilder` uses this to make all handles
available to services.
- `transport`: This allows messages to be reliably send/received to/from services. A `Requester`/`Responder` pair is
created using the `transport::channel` function which takes an impl of `tower_service::Service` as it's first
parameter. A `Requester` implements `tower_service::Service` and is used to send requests which return a Future
which resolves to a response. The `Requester` uses a `oneshot` channel allow responses to be sent back. A
`Responder` receives a `(request, oneshot::Sender)` tuple, calls the given tower service with that request and
sends the result on the `oneshot::Sender`. The `Responder` handles many requests simultaneously.
neonknight64
neonknight64 previously approved these changes Aug 15, 2019
Copy link
Contributor

@neonknight64 neonknight64 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With my limited futures knowledge, it looks good.

Copy link
Contributor

@neonknight64 neonknight64 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

@CjS77 CjS77 added this to the TestNet Release milestone Aug 15, 2019
@CjS77 CjS77 merged commit 86aa48a into development Aug 15, 2019
CjS77 added a commit that referenced this pull request Aug 15, 2019
This PR contains the building blocks for async p2p services.

It consists of the following modules:

* builder: contains the MakeServicePair trait which should
  be implemented by a service builder and the
  StackBuilder struct which is responsible for building the
  service and making service handles available to all the other services.
  Handles are any object which is able to control a service in some way.
  Most commonly the handle will be a transport::Requester<MyServiceRequest>.

* handles: struct for collecting named handles for services.
  The StackBuilder uses this to make all handles available to services.

* transport: This allows messages to be reliably send/received to/from
  services. A Requester/Responder pair is created using the transport::channel
function which takes an impl of tower_service::Service as it's first parameter.
A Requester implements tower_service::Service and is used to send requests
which return a Future which resolves to a response. The Requester uses a
oneshot channel allow responses to be sent back. A Responder receives a
(request, oneshot::Sender) tuple, calls the given tower service with that
request and sends the result on the oneshot::Sender. The Responder handles many
requests simultaneously.

Notes:

This PR adds the rust feature #![feature(existential_type)] to reduce the need
to box futures in many cases - more info here: rust-lang/rfcs#2071

TODO:

Hook up pub/sub messages from the comms layer. (Ref #644)
@CjS77 CjS77 deleted the sb-p2p-async-services branch August 15, 2019 08:16
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.

3 participants