UDP over TCP

The_Nerd · 07-21-2004, 04:22 PM

I am wondering wether or not I should use UDP in my game instead of TCP. Every one says that is is "faster", but how much? Is it worth the trouble involved? Also, how does it work? In TCP you connect to a remote host by their IP address. But with UDP, it looks like you just open up a port. Does this mean that when you send a packet, all clients with that port open receive the data? If this is the case, then after sending enough data in your packets to get them in the right order and to the right client, is it really faster than TCP?

Thanks for your time!

The_Nerd · 07-21-2004, 04:31 PM

I just read that some games use UDP and TCP. They use UDP to send data that doesn't matter too much, and TCP to send critical data. Does this answer my question about speed? Is UDP soooo much faster that they goto all this trouble? Is it really allot of trouble?

deiussum · 07-21-2004, 04:35 PM

When you send data with UDP you still specify an IP and port to send to. You just don't "connect" to an IP because it is a "connectionless" protocol.

Basically with TCP you have the following steps:

Server: create TCP socket
Server: bind to port
Server: set to listen state
Client: create TCP socket
Client: connect to server's IP/Port
Server: accept connection from client
Client and Server: Send and receive data as necessary

With UDP you typically have steps like so:
Server: Create UDP socket
Server: Bind to port
Client: Create UDP socket
Client: Bind to port
// Repeat the following as necessary...
Client: send packet to server's IP/Port
Server: respond to packet from client

UDP has a number of pros and cons over TCP. I'll try to cover a few of them:

PROs

Packet boundaries are preserved. This means that if you send 12 bytes the other side will receive 12 bytes in a single receive call. With TCP, you sometimes have to do your own boundary checking, because for instance if you send 12 bytes, then another 12 bytes, the other end might receive all 24 bytes in a single recv call. Or if the network is slow and you send a lot of bytes, it might take multiple recv calls to receive everything sent in a single send call... IMO, This is a big benefit to UDP packets.
Sockets are connectionless, so there is potentially fewer sockets to manage.
UDP can be a bit faster because it doesn't do a lot of the underlying sequencing, resending of lost packets etc. that is done with TCP sockets. However, if you plan to implement this functionality yourself, you will likely negate these benefits.

CONs

UDP packets are not guaranteed to arrive in the order they are sent. If you absolutley need them received sequentially, you must do your own sequencing.
UDP packets aren't guaranteed to arrive at all, and there is no built-in way to know if they were received. You have to implement this yourself by using some sort of ACK system, or you can send redundant packets in hopes that one of them gets through, or you can accept the packet loss and move on...
Because UDP is a connectionless protocol, you don't know if one side "disconnects" without implementing some sort of ack system, or timeout system if you expect packets received on a regular basis.

I'm sure there are a number of other Pros and cons that I am forgetting at the moment, but hopefully you get the idea.

deiussum · 07-21-2004, 04:41 PM

To answer your other questions...

yes, a lot of games use UDP, and many use both UDP and TCP.

No, it's not a lot of trouble. In many cases, UDP sockets can actually be easier to implement than TCP sockets.

Hko · 07-21-2004, 04:43 PM

Quote:

Originally posted by The_Nerd
In TCP you connect to a remote host by their IP address. But with UDP, it looks like you just open up a port. Does this mean that when you send a packet, all clients with that port open receive the data?

No. When sending/receiving data an IP-address as well as a port number needs to be specified. The difference is that there's no connection is maintained. Two programs (client and server) talking to eachother via UDP need to either send just one UDP packet or provide for re-assembly of the data in the right order themselves. Also, if a UDP-packet is lost on its way, the two programs are not notified (using TCP they would) and re-sending such a lost packet will not occur automatically.

This reduces some overhead in the IP-packets and resending and checking, which makes UDP faster, but less reliable.

UDP is often used for short data transfers, like DNS for example. Strangely enough (to my perception) it's also used for NFS though. (nowadays NFS over TCP also seem to be possible)

The_Nerd · 07-21-2004, 04:49 PM

Well, I have looked at and worked on the source code for Vavoom (www.vavoom-engine.com), and it had two functions to send data, and unreliable one, and a reliable one. I am guessing that Vavoom either used UDP and TCP (wich seams like a waste to me), or when sending reliable, then did its own ACK/NACK.

I don't have any problem with ACK and NACK.

I am using SDL_Net, could someone please use this link to gather info, and write up a quick UDP (as in like pesado, 10 lines or less) program to open a UDP connection to a pretend server and send a packet?

Thanks!

Link:
http://jcatki.no-ip.org/SDL_net/SDL_net_frame.html

This is what I am thinking:

Code:

IPaddress Address;
SDLNet_ResolveHost(&Address, "192.168.1.100", 1234);
UDPsocket MySocket=SDLNet_UDP_Open(1234);
SDLNet_UDP_Bind(MySocket, Channel, Address);
SDLNet_UDP_Send(MySocket, Channel, MyPacket);
SDLNet_UDP_Unbind(MySocket, Channel);
SDLNet_UDP_Close(MySocket);

Is that right?

itsme86 · 07-21-2004, 08:47 PM

The reason games use UDP is because they don't care about knowing whether or not the receiving end got every packet. UDP is also used in things like video and audio streaming, because a lost packet really doesn't matter. UDP really is much faster than TCP for these types of applications. But if you're going to use UDP and need to make sure the receiving end gets all of the data intact and in the right order then you'll just be re-implementing everything that you'd gain by not using TCP.

Not only do UDP packets create less overhead for the system, but they also save bandwidth. Each TCP packet you send has to receive an ACK from the receiving end. This creates extra traffic which the programs I mentioned above don't need.

The rule of thumb is: If you don't care that the receiving end gets all the packets, use UDP.

infamous41md · 07-21-2004, 09:45 PM

these two books are great for network programming:
http://www.kohala.com/start/unpv12e.html
http://www.kohala.com/start/tcpipiv1.html