You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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:
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 itsconnection_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 theNetworkBehaviour
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.The text was updated successfully, but these errors were encountered: