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

Support for stream-oriented protocols #1727

Closed
mzabaluev opened this issue Sep 2, 2020 · 2 comments
Closed

Support for stream-oriented protocols #1727

mzabaluev opened this issue Sep 2, 2020 · 2 comments

Comments

@mzabaluev
Copy link
Contributor

The trait infrastructure of NetworkBehaviour, ProtocolsHandler etc. is very generic, so stream-oriented protocols should be possible to implement. Streamed processing is useful for efficiently implementing transfers of bulky sequences of messages, where the receiving party can cancel the transfer early or apply back pressure to avoid buffering large amounts of data.
However, the utilities available in the library are geared towards unary request-response exchanges:

  • The protocol handler in the request_response module encodes and decodes one message per substream. The substream I/O object is passed to the codec by reference, so it's not possible to take ownership of it to return a stream object as a decoded message.
  • OneShotHandler could be a better fit, but its connection_keep_alive implementation only regards outbound substreams under negotiation when deciding whether to keep the connection alive. When stream or sink objects corresponding to protocol requests or responses are given to the NetworkBehaviour impl or to the application to use, the keep-alive logic should keep track of the substream handles that are in use.

It would be nice to have a stream-oriented equivalent, or possibly a generalization of, RequestResponse, so that the library users would not need to implement substream management on their own.

@wngr
Copy link
Contributor

wngr commented Dec 9, 2020

Wouldn't it be possible to refactor the request_response behaviour in such a way, that a codec can read (respectively write) >= 1 message from the I/O object? This probably would mean though, that the current design using the upgrade mechanism to exchange messages won't work anymore, and some book-keeping would need to be done inside the ProtocolsHandler.

Anway, I very much agree with the need for a stream-oriented RequestResponse protocol, basically comparable to channels.

@thomaseizinger
Copy link
Contributor

Closing in favor of #2657.

@thomaseizinger thomaseizinger closed this as not planned Won't fix, can't repro, duplicate, stale Mar 29, 2023
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

No branches or pull requests

3 participants