Comments (2)
Thanks for the report! I believe this was intended. In particular, the current behavior is described accurately by the rustdoc:
May fail if [and only if]
finish()
orreset()
was previously called.
The reasoning here was that it's common for peers to routinely stop
a stream or close
an entire connection upon reading some data without waiting for the stream to be finished. If the sender finish
es all streams and considers finish
on stopped streams or closed connections to be an error, then this is very likely to produce unhelpful error signals, and may do so unpredictably depending on timing. We've had a number of issues opened due to this behavior in earlier releases.
I appreciate that it's counterintuitive that calling finish
succeeds on a connection you know to be closed, but I think this is consistent with the semantics of finish
. Consider that a connection might also become closed in the time between calling finish
and the next opportunity for the connection to transmit any packets, resulting in the same lack of effect that you get from calling finish
after closing.
I'm interested in feedback about how much sense this makes to you, and where we could improve in documentation or API to make things more obvious or convenient. You can reconstruct the previous behavior by waiting on SendStream::stopped
after finishing, but I think the errors you might receive from doing so are usually not interesting.
from quinn.
I guess it is reasonable to not give an error, after all the peer already knows no more data will be written on the stream if it is closed and as you say stops and finishes may be crossing on the wire anyway.
I think the docs can be a little better though. Right now I'm not sure how to interpret that error and wonder if calling .finish().ok()
is the only sensible way to call it. Which means it could not even return anything from an API point of view?
My attempt at rewriting the docs right now would look something like:
Notify the peer that no more data will ever be written to this stream.
After calling this the remote's [
RecvStream::read_to_end
] will complete. The remote may already have stopped the stream itself, maybe because it knew this situation already from the application-level protocol. This also means the remote is already aware that no more data will be written on this stream so is considered a success forfinish()
.To wait for the peer to receive all buffered stream data, see
stopped()
.Mail fail if
finishe()
orreset()
was previously called locally. This error is harmless and serves only to indicate that the caller may have incorrect assumptions about the stream's state.
from quinn.
Related Issues (20)
- long running bi stream HOT 5
- seems like quinn 0.11 not working well under heavy load HOT 12
- API for awaiting for stream reset on the reader HOT 5
- build fails on Solaris HOT 4
- Rotation of Connection IDs HOT 5
- How to run insecure connection example? HOT 1
- Weird issue when transferring large file HOT 3
- `ACKs are delivered in order` panic when packets are reordered
- Allow a client to specify Initial Connection ID HOT 2
- Bundle flow control and ACK frames opportunistically
- RTT calculation of connection is pretty unreliable when _just_ using the library as is HOT 8
- `SendStream::stopped` suffers excessive delay in terminating with `ZeroRttRejected`
- Dropping `Endpoint` can cause unnecessary "Incoming dropped without passing to..." warnings
- Allow certificate access on Connecting HOT 5
- Allow disabling backtraces in panics HOT 3
- Consider adding an expect message to unwrap in packet_builder.rs HOT 6
- quinn is failing `zerortt` interop HOT 1
- Panic with tokio 1.39 HOT 8
- `handshakecorruption` crash HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from quinn.