-
-
Notifications
You must be signed in to change notification settings - Fork 119
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add backpressure to Channel receivers
Fixes #392. Simply put, this changes its `UnboundedReceiver` from `unbounded_channel` with a `Receiver` from `channel(...)`, with a configurable value in `channel_buffer_size` of 100. This means that, for each channel that's created, it can hold up to 100 `Msg` objects, which are at most as big as the window size plus metadata/indirection pointers. This is enough to force messages to be read from the underlying `TcpStream` only as quickly as the server/client is able to handle them. This has been tested with the example given in #392, including a modification to slowly read into a non-expanding buffer, and appears to fix the issue that's been pointed out. Some other considerations: - It is still possible to cause memory to explode by opening multiple channels, although that might be intentional on the user's part. In this case, it's up to the user to handle when channels get created or not. - The limited buffering also means that control `Msg`s (eg. `Eof`) will also be delayed by the transport layer backpressure, although this might be expected by the SSH standard. Reading through RFC 4254, I couldn't find any mention of non-`Data`/`ExtendedData` messages having to be dealt differently, but I don't think it's even possible to do so over TCP. If this assumption is wrong, this might require a separate `mpsc::unbounded_channel` just for control messages. **BREAKING CHANGES**: - This removes `fn send_channel_msg`, which doesn't seem to be used anywhere in this library, but is part of the publicly exposed API nonetheless. - This adds the configuration value `channel_buffer_size` to both servers and clients that allows setting how big the buffer size should be.
- Loading branch information
Showing
7 changed files
with
127 additions
and
91 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.