A few years ago I worked at a company called VVond, now Vudu.
I don't think they ever shipped it, but I wrote a Linux netfilter
while there to turn TCP into UDP on the send side, then turn it
back into TCP on the receive side.  It's not hard: change the
proto in the IP header, move the TCP seq # to the URP (which
wasn't used), create a UDP len and csum where the TCP seq # was.
And update the IP csum as you go.  Then a bypass mechanism to
allow NAT pinhole probes to be sent on the same port using a
plain old UDP socket.  (I simply assumed anything too small to
be a TCP segment, or invalid, was a pinhole probe and passed it
on unmolested.  That gave plenty of space for probe payload.)
So basically TCP segments were converted (not encapsulated) into
UDP and back.

Worked fine and allowed UDP NAT traversal for what the user level
code thought was a TCP socket.



Allen wrote:
>
> Back about 1998 a company I was working for used a UDP wrapper 
> around TCP packets. Each UDP packet had a unique number in the 
> header for a given message/file transfer and the TCP inside did 
> as well. The client collected them, found which ones had been 
> lost in transit and sent a "resend message" for just those 
> packets. Worked very well in very high RTT latency connections, 
> like satellite and cell phone. The latency we measured on, if I 
> recall correctly, Dokomo got as high as 51 SECONDS! although it 
> averaged about 3 to 4 seconds and satellites was about 2 seconds 
> RTT. TCP would never work, but UDP did. All that was needed was 
> for the client to order the packets correctly and ask for any 
> missing ones. The back haul went from about 13% for TCP on low 
> latency links to under 1% using UDP. Even on high latency links 
> we never saw much over 1% back haul traffic.
>
> One of the fun things about it was that the whole message/file 
> could only be collected at end points due to the various routes 
> UDP took at that time.
>
> The company still exists. It's now called Venturi Wireless at 
> http://www.venturiwireless.com/

_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers

Reply via email to