stream: allow reading after stream is closed #14
Conversation
|
I think it's sensible to allow reading out all buffered data after close, but shouldn't an error still be caused in the event that you try to read after the buffered data is exhausted and the stream is closed? Alternatively if it makes sense to close either the reading half or the writing half for long periods of time then shouldn't the state be split i.e. |
That's not how TCP stream behaves, neither SCTP should. async-std Interestingly enough, async-std |
That makes sense. Along with adding |
- deprecate Stream::close in favor of it - only shutdown writing half of stream in PollStream::poll_shutdown Refs webrtc-rs#13 (comment)
Codecov Report
@@ Coverage Diff @@
## main #14 +/- ##
==========================================
+ Coverage 40.18% 40.27% +0.09%
==========================================
Files 48 48
Lines 7765 7818 +53
Branches 2226 2249 +23
==========================================
+ Hits 3120 3149 +29
Misses 3217 3217
- Partials 1428 1452 +24
Continue to review full report at Codecov.
|
|
@k0nserv ready for another review. PTAL 😸 |
when stream's reading half is shutdown
NOTE: we don't need to shutdown the stream as it was already done by the association minus sending the reset request, which is not needed in this case (i.e. if we've just received one, we don't need to send one back in response). Refs webrtc-rs/sctp#14
* return early if the incoming stream was reset NOTE: we don't need to shutdown the stream as it was already done by the association minus sending the reset request, which is not needed in this case (i.e. if we've just received one, we don't need to send one back in response). Refs webrtc-rs/sctp#14 * do not account for data, which we've failed to send * format code * only count number of bytes actually sent not the number of bytes we're going to send https://github.com/webrtc-rs/data/pull/11/files#r904854127
* return early if the incoming stream was reset NOTE: we don't need to shutdown the stream as it was already done by the association minus sending the reset request, which is not needed in this case (i.e. if we've just received one, we don't need to send one back in response). Refs webrtc-rs/sctp#14 * do not account for data, which we've failed to send * format code * only count number of bytes actually sent not the number of bytes we're going to send https://github.com/webrtc-rs/data/pull/11/files#r904854127
2 participants
Closes #13