search

quinn-rs / quinn

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

`send_datagram()` with large packet #1340

Closed YeautyYE closed 2 years ago

YeautyYE commented 2 years ago

The network environment of my program is very poor, and the packet loss rate reaches 50%. I want to use unreliable transmission but the size seems to be unchangeable

djc commented 2 years ago

Datagram sizes are limited by Ethernet packet sizes, since QUIC packets are not allowed to fragment over different Ethernet packets. Do you actually need unreliable data exchange or are you just trying to work around the packet loss issues? Have you tried Quinn's reliable QUIC streams and found them not to work?

YeautyYE commented 2 years ago

Yes, I need unreliable data exchange. Because I care more about real-time than reliability.

djc commented 2 years ago

So you can open a new stream for independent changes, that would make sure that packet loss does not affect inter-stream latency. However, if your payloads are larger than an Ethernet frame payload, you're probably still going to be affected by packet loss-induced latency a little bit.

YeautyYE commented 2 years ago

Do you mean to start a new stream for each packet?

djc commented 2 years ago

Yes.

YeautyYE commented 2 years ago

If 'open_uni()' and 'uni_stream.next ()' are called frequently, will network latency increase

djc commented 2 years ago

I don't think they will meaningfully increase, no. Those just increase some counters, and increasing those counters will eventually result in a few bytes of the new value of the counter being sent per packet.

YeautyYE commented 2 years ago

OK，thx!

YeautyYE commented 2 years ago

Whether open stream need to be flush and close

djc commented 2 years ago

I'm not sure what you mean by that.

Kiddinglife commented 2 years ago

hey @YeautyYE, Sending an oversized datagram unreliably actually corresponds to sending that reliably if you need to keep the message boundary. I suggest you compress your big packet to have it smaller than the ethernet size limit. I am kind of doubt if it makes sense to have such big datagram....

Ralith commented 2 years ago

Closing as there doesn't seem to be any outstanding question here.