[RTW] Comments on draft-alvestrand-dispatch-rtcweb-datagram

[Harald Alvestrand]

On 01/06/11 22:32, Justin Uberti wrote:
>
>
> On Thu, Jan 6, 2011 at 7:38 AM, Harald Alvestrand 
> <harald at alvestrand.no <mailto:harald at alvestrand.no>> wrote:
>
>     On 01/06/11 08:05, Justin Uberti wrote:
>>
>>
>>         Background: I had a discussion with a coworker who wanted to
>>         have a single API to both streaming and datagram service; I
>>         believe it makes more sense to define an API to a datagram
>>         service and an API to a streaming service separately - the
>>         big argument for PseudoTCP is the client-to-client connection
>>         case, where one often finds that UDP works and TCP doesn't.
>>
>>
>>     I had been thinking the datagram and streaming services should
>>     use a single API - much of the API ends up being the same, and
>>     that's how BSD sockets work. There are a few differences for
>>     streaming services, but they are mostly (entirely?) additive
>>     (flow control being the main one).
>
>     The huge difference is that a streaming API gives you a sequence
>     of bytes, in strict order, while a datagram API gives you a (not
>     necessarily ordered) sequence of datagrams. Each datagram is
>     guaranteed to be treated as an unit, but order is not preserved.
>     There is no guarantee about block boundaries in a stream (you have
>     to create them yourself if you want them), but order is strictly
>     preserved.
>
>     For most of the rest of the functions, the APIs can (and should)
>     be the same, but the sending and reception of data is different.
>
>
> Sure, but that doesn't seem like something the API has to worry about, 
> other than to allow the mode to be specified (datagram or streaming) 
> when the transport is created. For example, BSD sockets use the same 
> APIs for stream and datagram operations; send and recv each take a 
> pointer and a length, although the semantics are slightly 
> different. (Note that sendto and recvfrom also exist in BSD sockets, 
> but aren't relevant in this case, where the destination is fixed as a 
> result of the ICE process).
The semantics are a whole lot different; send(3 bytes) + send(3 bytes) 
on a streaming socket can get you a recv(6 bytes); send(3 bytes) + 
send(3 bytes) on a datagram socket gives you recv(3 bytes), twice. The 
fact that the BSD socket interface tries to hide this distinction is a 
weakness of BSD sockets. (My master's thesis work back in 1984 involved 
an email exchange with Jon Postel to verify the semantics of TCP wrt 
packet boundaries - it seems that it's been an argument within the ARPA 
community for quite some time before that, too).

The programmer has to be completely clear on whether packet boundaries 
will be preserved over the API or not. This is clearest when it's 
visible in the API.

                        Harald

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtc-web/attachments/20110106/4a71c72b/attachment.html>