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

server: 🌽 listen_channel for in-memory connections #41

Closed
wants to merge 2 commits into from

Conversation

cratelyn
Copy link

@cratelyn cratelyn commented Feb 9, 2024

this introduces a Server::listen_channel interface. this is like the existing listen_tcp or listen_unix methods, but instead applies to an in-memory channel of (read, write) tuples.

this is motivated by work like penumbra-zone/penumbra#3588. to summarize the motivation, it would be nice if we had a way to run a tower-abci service in cargo tests, without needing to bind to an actual port, or create a unix-domain socket within a temporary directory.

this introduces a `Server::listen_channel` interface. this is like the
existing `listen_tcp` or `listen_unix` methods, but instead applies to
an in-memory channel of `(read, write)` tuples.

this is motivated by work like penumbra-zone/penumbra#3588. to summarize
the motivation, it would be nice if we had a way to run a tower-abci
service in cargo tests, without needing to bind to an actual port, or
create a unix-domain socket within a temporary directory.
@hdevalence
Copy link
Member

I'm not sure this is the right approach for that testing use-case.

tower-abci is a compatibility layer to bridge the bespoke Tendermint socket protocol to a more reasonable, request/response-oriented API.

Using it in an in-memory test would mean translating all the requests and responses through the TSP wire encoding and then back, re-interpreting them as requests and responses, and then feeding them into the generic C: Service<...> passed into the tower_abci::Server. But if the test code is instantiating the tower_abci::Server, it already has a consensus service that it's plugging in (the C: Service<...> mapping ConsensusRequests to ConsensusResponses), and it could just call that Service directly.

I'm not sure whether this was made explicit, but that was the intent of the C in the Engine<C> we sketched while pairing: passing in a generic consensus Service into the Engine means it can make ABCI requests directly (using the tower::Service API, or the convenience methods in ServiceExt), without any need for extra encoding.

pushing this, as experimentation continues. this really does seem like
a very promising avenue for abci testing!
@cratelyn cratelyn closed this Feb 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants