On Wednesday, August 21, 2013 02:57:33 PM Zack Morris wrote: > Hmm DCCP looks pretty cool but how supported is it? Games and p2p just use > UDP and TCP right now. Originally I think a mistake was made in the design > of the internet where it should have gone IP->UDP->TCP instead of IP->UDP > and IP->TCP. That way if TCP worked, UDP would have too, and we wouldn't > have run into the problems with NAT we have now for UDP. Although NAT > issues are by design in many ways, so perhaps we still would have. I > realize that TCP header savings used to be important but I don't think they > are nearly as much now except for wireless. > > Mainly what I would like is a wrapper that turns an unreliable layer like > UDP into a reliable one. Like literally give me a socket that acts like a > TCP socket but uses UDP internally. I thought about implementing this > somehow as a library that returns a pipe to the process but didn't get far > with it. I'm still reading about nanomsg and it looks like it doesn't > maintain its own queues, so I'm wondering if it's even possible. > <snip> You may find TNG interesting: http://dedis.cs.yale.edu/2009/tng/ The idea is to split up the transport layer into four sub-layers: Endpoint (essentially UDP, not e2e) Flow (essentially DCCP-without-ports-inside-UDP, not e2e, allows flow middleboxes to specialize congestion control for the transport [such as wireless] on a hop-by-hop basis w/o breaking fate sharing) Isolation (basically DTLS, *is* end-to-end, prevents stuff from poking about inside the data trying to be 'helpful' [leading source of incompatibility when updating TCP and HTTP]) Semantics (handles things like reliability [TCP, SCTP, SST], stream-vs- datagram [TCP, SST are stream; SCTP is datagram], subchannels [SCTP, SST] and the like) They've implemented a toolset called "Minion" which does this in a way that is indistinguishable on the wire from TCP, SSL, or DTLS too.