Twitter  Facebook  YouTube  E-Mail  RSS
The One Man MMO Project
The story of a lone developer's quest to build an online world :: MMO programming, design, and industry commentary
Networking Part I
By Robert Basler on 2011-08-09 23:44:38
Homepage: www.onemanmmo.com email:one at onemanmmo dot com

I haven't really talked about networking at all on the blog. That might seem a bit odd given that I was a 'networking guy' at EA. There's no conspiracy here though, the simple fact is that my networking code was done and dusted before I tackled the blog in earnest and I write about what I'm thinking about. Networking is a big topic, so there'll probably be other articles later.

TCP or UDP



I suppose I should get the big question out of the way first. Do you use TCP or UDP for your packet transport? I'm using UDP. For most games, TCP is a better solution. TCP is simply way easier. A whole lot of effort has gone into TCP's design and implementation and it has all sorts of functionality you'll need to build yourself if you choose UDP. The only reason to choose UDP for a game is if you have data which must arrive very quickly and you don't care if sometimes that data gets lost.

Are you making a twitch shooter? Then you might want to choose UDP. Are you building an RPG? Think TCP. World of Warcraft runs on TCP, and if you watch it run, it only sends data a couple times a second (so if your network freaks out, it takes a little while for it to have any effect on gameplay.) Not sure what to pick? Choose TCP.

What am I Getting Into with UDP



UDP drops packets - they just never show up. That can be inconvenient.

UDP also doesn't guarantee delivery order, so you might get a packet you sent 30 seconds ago right after one sent 30 milliseconds ago. Better take that into account and stick a packet sequence number into your packets.

Sooner or later you're also going to need to know that a piece of data has actually arrived. That means you're going to need to build a reliability layer on top of the basic unreliable transport offered by UDP. A really good place to start is the IETF Reliable UDP Protocol. Read it, a lot of what you need to know is right there.

Packet size is something you'll need to consider as well (go read up on MTU, I'll wait.) If you send a packet that is too big for one of the hops between your client and server, IP may fragment a packet into one or more packets and recombine it automatically later. Once packets start to fragment, you're going to have performance problems. A typical LAN connection can do about 1500 bytes in a single packet reliably. Over DSL it drops to 1492. Modern networks should be able to do 1200 pretty reliably, but if you want to be really super sure, go with 576 which is the datagram size that all networking equipment is required to accept. Keep in mind that the smaller you make your packets, the more packets you will need to send, and you may have performance problems there as well. Nothing is ever simple.

When you're figuring your packet size, don't forget the header. Every UDP packet you send will have 28 bytes of overhead over IPV4. So for example, a packet size of 576 - 28 bytes of UDP header = 548 bytes per datagram.

If you're really obsessed with packet size, it is possible to measure the MTU between the client and server, but keep in mind that the MTU can change over time as packets take different routes. And measuring MTU is a pain.

Jumbo Packets



Sending data via UDP, if you want to send more data than will fit in a single packet, that reliability layer will come in handy again. I built what I call Jumbo packets on top of my networking system and those have proved to be a real timesaver. The need to send oversize data happens for things like the initial sync when the client connects. You can make your code for serializing entities really complicated, checking constantly to see if things are going to fit, or you can just write it all to one gigantic packet and let the lower layers take care of splitting the data into a set of packets that are sent separately and automagically recombined on the client.

Or you can use TCP and have it take care of all of this for you.

New Comment

Cookie Warning

We were unable to retrieve our cookie from your web browser. If pressing F5 once to reload this page does not get rid of this message, please read this to learn more.

You will not be able to post until you resolve this problem.

Comment (You can use HTML, but please double-check web link URLs and HTML tags!)
Your Name
Homepage (optional, don't include http://)
Email (optional, but automatically spam protected so please do)
What color is a lemon? (What's this?)

  Admin Log In



[Home] [Blog] [Video] [Shop] [Press Kit] [About]
Terms Of Use & Privacy Policy