http://tunnel.mrq3.com/explain/

TCP/UDP Tunnel

Difference between TCP and UDP

There are two types of internet protocol (IP) traffic, and both have very different uses.

1. TCP(Transmission Control Protocol). TCP is a connection-oriented protocol, a connection can be made from client to server, and from then on any data can be sent along that connection.
   • Reliable - when you send a message along a TCP socket, you know it will get there unless the connection fails completely. If it gets lost along the way, the server will re-request the lost part. This means complete integrity, things don't get corrupted.
   • Ordered - if you send two messages along a connection, one after the other, you know the first message will get there first. You don't have to worry about data arriving in the wrong order.
   • Heavyweight - when the low level parts of the TCP "stream" arrive in the wrong order, resend requests have to be sent, and all the out of sequence parts have to be put back together, so requires a bit of work to piece together.

2. UDP(User Datagram Protocol). A simpler message-based connectionless protocol. With UDP you send messages(packets) across the network in chunks.
• Unreliable - When you send a message, you don't know if it'll get there, it could get lost on the way.
• Not ordered - If you send two messages out, you don't know what order they'll arrive in.
• Lightweight - No ordering of messages, no tracking connections, etc. It's just fire and forget! This means it's a lot quicker, and the network card / OS have to do very little work to translate the data back from the packets.

Why Quake and other games use UDP

Suppose you have a connection streaming 30 packets / second both ways (a typical Quake connection). Now...there's a problem with packet loss and one of those packets goes missing.

A TCP connection would identify the missing packet, and re-request it from the server. Despite the fact that it's still receiving the quake packets, it doesn't pass these on to Quake yet. Because TCP is ordered, it waits until it has a complete stream, exactly as it was sent. The advantage... no packet loss and all packets arrive in the right order! All missing packets are replaced. The disadvantage... a sudden complete lack of packets whilst the missing one is resent.

A UDP connection would continue to send the packets. When quake sees that there are missing packets, it'll put those sexy red lines on your lagometer, and just carry on. It knows it might miss a few packets, and they're not too crucial since it might drop a sound or an item pickup, but whatever happens it will be able to pick up straight away from the next packet. If the lagged / dropped packet ever arrives, it'll just be thrown away because it's out of sequence.

What a firewall does

Depends completely on the firewall! In Essex uni, the firewall blocks all UDP packets, and all tcp connections that aren't made to well-known ports.

To get round this UDP blocking, you have to disguise the UDP packets as TCP data!

The first attempt

The Idea

Write a server and a client that connect to each other via a TCP connection (to get through the firewall). Make the server listen for TCP connections on port 6667. Make the client listen for UDP packets on port 27960. Then, a client can connect (in quake) to localhost:27960, and all UDP data can be forwarded over the tunnel as TCP packets. The server can be run in an unfirewalled place that can exchange UDP packets happily with the Quake server, the client can be run on the PC of the person trying to play Quake.

When data is received by the client (the UDP packets from Quake) it's turned into TCP data, sent to the tunnel server, converted back to a UDP packet, and sent from there to the Quake server. Now, the quake server thinks that the tunnel server is actually where the person connecting to the quake server is, and as such sends all data back to that. The tunnel server does exactly the same thing, turns the UDP packets to TCP data, sends them over the tunnel to the tunnel client, which sends them as UDP to Quake on that PC. Cunning eh?

The Result

Lagggggggggggg. Superb :/ Whilst there was no packet loss at all, when parts of the TCP connection went astray the entire TCP stream waited for the lost parts to be replaced. Not good! Basically this tunnel was unplayable :(

Extreme tunnelling

OK, the first attempt was encouraging in that people could play, but not so good in that it was hardly playable. Back to the drawing board...

The Idea

Same as the last one, but use 20 TCP connections, and send data down a different one each time. In theory TCP connections won't use any bandwidth at all when they're idle, so they won't lag if there's no data :) So, by having that many TCP connections, when one lags, the others won't - so it should pick up after lags and frozen streams really quickly. It's a bit more complicated though because you need multiple TCP connections that all serve the same client Q3 connection.

The Result

Success! Finally a playable Quake3 connection for people behind firewalls. However, because of the way I'd written it...I had to run the tunnel server (because no one else can), and I have to manually set server ips. It was a right hassle, and far from ideal still. But heh, it worked, project complete, yeah?...