use tcp over udp? (Re: [p2p-hackers] UDP file transfer link speed identification)

[Adam Back]

On Sat, Jul 23, 2005 at 11:09:36PM -0700, David Barrett wrote:
> Adam Back wrote:
> >Why don't you just use the tcp stack's tcp implementation and tunnel
> >the IP packets that TCP sends over upd?
> 
> That's a damn good idea, actually.  Can you give the 30-second
> architectural overview of how Cebolla exposes a virtual Linux TCP
> interface?

Here's a forwarded response from Zach one of the authors of cebolla:

| Sure can :)
| 
| The most basic premise is that the application gets a file descriptor
| that is used to read and write packets from a networking device in the
| system.  When a packet is delivered to this networking device, it is
| made available to the application for read() on the fd.  When the
| application write()s to this file descriptor, the packet is injected
| into the networking stack as though it just arrived at the device.
| 
| So the trick is to configure this device<->fd path and then tell the
| linux routing pieces to forward traffic for the TCP stream you're
| interested in down that device.  When the locally generated TCP traffic
| is routed out the device, the application reads it, encapsulates it in
| whatever goo it wants, and sends it out a UDP socket as usual.  When
| traffic comes back in to the application via UDP, the app trips off the
| encapsulation and write()s the packet out the fd.  This injects it back
| into the local TCP stream.
| 
| This stuff is no problem.  The fd<->device path is setup with a magic
| /dev/net/tun device.  The routing is generally done by tagging streams
| by user/endpoints/etc with iptables and then using iproute2 to configure
| the routing subsystem to forward such tagged packets to the fake device.
| 
| I don't know how much detail you're interested in, but there are some
| tricky parts to this and the worst is propagating icmp for path mtu
| discovery.
| 
| Anyway, some resources:
| 
| http://lxr.linux.no/source/Documentation/networking/tuntap.txt
| http://lartc.org/howto/lartc.netfilter.html
| 
| I couldn't find a strong description of the path mtu and icmp forwarding
| problem that tunnels introduce, but section 3 of this rfc comes pretty
| close:
| 
| http://www.faqs.org/rfcs/rfc1853.html
| 
| - z