quinn-rs / quinn

Async-friendly QUIC implementation in Rust
Apache License 2.0
3.76k stars 380 forks source link

sending delay detection #1662

Closed szguoxz closed 5 months ago

szguoxz commented 1 year ago

I have a very basic question, as I am kind of new to this.

How do I know if my packet has arrived safely?

I know I can use sendstream.finish to detect whether it's acked. But it seemed take too long, sometimes over 3 seconds!

Before I know for sure, I don't even know if the line is broken or something.

in a very unreliable environment, what's the best way for me to detect of there's a connection problem? What is the reasonable time and method for me to know: OK, This line is broken (too slow can also be called broken), I got to try something else.

Ralith commented 1 year ago

How do I know if my packet has arrived safely?

This depends on what exactly "arrived safely" means to you. Usually what people mean is "has been processed by the remote application", but SendStream::finish only tells you when a stream has been received by the transport -- the application might still shut down or crash or lose power before processing the stream. To be certain that a message was actually processed, you usually need to have an application-layer response of some kind that the peer only sends when it's done.

But it seemed take too long, sometimes over 3 seconds!

Why is 3 seconds too long? If the link is very slow and/or lossy, that might be a perfectly reasonable duration, especially if you're sending much data.

what's the best way for me to detect of there's a connection problem?

Set TransportConfig::max_idle_timeout according to your needs. Also consider setting TransportConfig::keep_alive_interval. Ultimately it's up to you to define what behavior counts as a broken link.

too slow can also be called broken

You'll need to track this yourself, though Connection::stats might be useful.

szguoxz commented 1 year ago

In the PathStats, there's a lost_packet. I am wondering what this means? Does this mean quinn finally give up re-transmitting the packet? Or is it just quinn found a packet without ack, and wait it long enough? So quinn will retransmit it?

Also, usually how long will quinn wait to decide re-transmit? or give up?

Thanks.

djc commented 1 year ago

In QUIC, packets are never retransmitted. So if the peer never reports receiving a packet, that packet is lost -- and the QUIC implementation will make sure the contents of that packet are resent in new packets if necessary.

Read the spec for more on how all of this works:

https://www.rfc-editor.org/rfc/rfc9000.html#name-retransmission-of-informati

Ralith commented 5 months ago

Closing as there don't seem to be any outstanding questions, but feel free to open a new issue if you still have a problem!