Re: [rtcweb] PseudoTCP implementation (Re: realiable data service)

[Justin Uberti <[e-mail]>]

On Sat, Jul 23, 2011 at 5:50 AM, Tim Panton <[e-mail]> wrote:

>
> On 23 Jul 2011, at 03:33, Cullen Jennings wrote:
>
>
> On Jul 20, 2011, at 8:37 , Justin Uberti wrote:
>
>
> Yes, I was going to send a similar email. There are some
> deficiencies/optimizations for the fact it runs over ICE-UDP - doesn't do
> path MTU discovery, no checksum, no OOB data - but it is based on TCP and
> implements slow start and other congestion avoidance mechanisms, and is
> actively used by a number of applications where reliable transfer is
> important, such as file transfer and remote desktop applications.
>
>
>
>
> It would be really interesting to see someone write a draft that subsets
> TCP to make it
>
>
> I just want to flag that TCP isn't an especially good fit here, datagrams
> delivered in events are a very useful
> abstraction in JavaScript, which doesn't really do streams of data very
> well.
>
> I know we can do datagrams over TCP,  but
> it seems wasteful to de-packetize in the TCP layer, just to try and
> re-packetize it a couple of layers further up.
>
> If there is a reliable datagram protocol as opposed to a reliable stream,
> I'd go for the datagram every time.
>

Yes, the API here will be datagram-oriented, just like WebSockets. Ideally,
the API for this would match WebSockets exactly, so that code in higher
layers can be agnostic about exactly how the data is being sent.

Even as a "datagram" service, I think TCP is still the best fit. The fact
that it is well-understood and has countless working implementations is far
more significant than any cost of framing (which will likely be trivial).

>
> Tim.
>
>