<br><br><div class="gmail_quote">On Thu, Jan 6, 2011 at 7:38 AM, Harald Alvestrand <span dir="ltr"><<a href="mailto:harald@alvestrand.no">harald@alvestrand.no</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div bgcolor="#ffffff" text="#000000">
    <br>
                          Harald<br>
    <br>
    <br>
  </div>

</blockquote></div><br>