<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 01/06/11 08:05, Justin Uberti wrote:<br>
<blockquote
cite="mid:AANLkTimkF6QO9cBUjnv7XnoSHXd98QG11hyvWGxxUzQX@mail.gmail.com"
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>
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>
<br>
Harald<br>
<br>
<br>
</body>
</html>