<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 01/06/11 22:32, Justin Uberti wrote:
<blockquote
cite="mid:AANLkTinhPFOwaqTJLFzZBSJZX7-RNDVQVe9g8YYhcHV+@mail.gmail.com"
type="cite"><br>
<br>
<div class="gmail_quote">On Thu, Jan 6, 2011 at 7:38 AM, Harald
Alvestrand <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:harald@alvestrand.no">harald@alvestrand.no</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
<div class="im"> On 01/06/11 08:05, Justin Uberti wrote:<br>
<blockquote type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0pt 0pt
0pt 0.8ex; border-left: 1px solid rgb(204, 204,
204); padding-left: 1ex;"> <br>
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.<br>
</blockquote>
<div><br>
</div>
<div>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).<br>
</div>
</div>
</blockquote>
<br>
</div>
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.<br>
<br>
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.<br>
</div>
</blockquote>
<div><br>
</div>
<div>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).</div>
</div>
</blockquote>
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).<br>
<br>
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.<br>
<br>
Harald<br>
<br>
</body>
</html>