- From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
- Date: Wed, 21 Feb 2018 17:10:56 +0100
- To: public-webrtc@w3.org
On 21/02/2018 7:37, Randell Jesup wrote: > On 1/24/2018 12:59 PM, Sergio Garcia Murillo wrote: >> On 24/01/2018 18:50, Michael Tuexen wrote: >>> >>> Are you referring to a non-congestion controlled way of sending >>> unordered, unreliable datagrams? >>> You can right now use and unordered delivery, limit the number of >>> retransmissions to 0 and >>> get a congestion controlled unordered unreliable datagram service... >> >> Except that it can be buffered, chunked, there is no way of knowing >> the MTU and last time I checked didn't work as expected on any >> browser.. ;) > > There is a transmit buffer, and it does hide the MTU from you, true - > it provides an abstracted UDP API, not a raw socket API. If you could > ask the current apparent MTU as seen by the protocol, you could > restrict your messages to that. But of course that same issue exists > for UDP - you can send larger messages (ok, max 64K) and it will > fragment and reassemble (maybe) the messages for delivery, just like > DataChannels. > > So that leaves exposing the (current) MTU, and the fact it can be > buffered (though normal network IO can be buffered as well). Would you > be happy with exposing MTU? Yes, I think that exposing the MTU, or current "maxChunkSize" would be enough for me so far. Best regards Sergio
Received on Wednesday, 21 February 2018 16:11:20 UTC