Network Programming - Starting out

I would like to start out learning network programming. Are there any books, tutorials and libraries you guys recommend? I would eventually like to get to a stage where I can make player vs player gameplay happen in web and offline gaming if that helps you point out what kind of stuff I should be studying. Thanks for any help. :)
I will offer one piece of advice: do not ever trust the client.
Thanks LB, I shall keep that in mind.
Not that much to say.
Should you use UDP, you must build a reliability system somehow.
Some data must be reliable and ordered, some may be unordered, and in this case only the last packet is really relevant.
As for the rest, I suggest compressing data before sending.
Nowadays CPUs are cheap and networks are expensive, moving network to CPU sounds like a good choice. LZ4 has a good speed/compression ratio for this kind of stuff. (For nonprioritary messages, buffering more packets before compressing is better).
Also, take into consideration lag compensation.
Will you lagcompensate?

or, http://www.raknet.com/raknet/downloads/
Actually, I have more to say: you should use a combination of TCP and UDP. Use TCP for messages which must arrive and which must arrive in order (e.g. most things), and use UDP for messages that don't have to arrive and don't have to arrive in order (e.g. movement packets, things that update constantly, etc) with occasional (5/sec) TCP updates as a backup. UDP makes things smooth whereas TCP makes things surefire.
Last edited on
Actually I have to go against using a mixture of TCP and UDP. It often complicates things quite a bit. If you're programming an action game, use pure UDP at first. If you are experiencing quality issues, then integrate TCP into your code as well.
I think a more complete version of what LB said in his first post is:
Be liberal in what you receive and strict in what you send.
@NoXzema you mean the opposite?
No, I mean what I said.
EDIT: This applies to both client and server as well equally.
EDIT2: There's no reason to trust a server either.
Last edited on
The user gets to decide whether to trust a server. The server should never trust any client.

@Avilius: Why do you suggest that? Mixing TCP and UDP is not a complicated thing to do. I would never use pure UDP for anything, ever.
I'm suggesting it because it will be solving a problem that may or may not even be a problem.
Would a networked computer game not use pure TCP then?
No. TCP is really inefficient.
It depends. If there isn't much real-time interaction, then go ahead and use TCP. If it's an action game, you'll get performance problems very early into development, so it's not even worth it to start with TCP.
TCP shouldn't be used if

1. You dont want a timeout.
2. High packet volume
3. Ultra high security requirements.
4. Real time requirements.
5. No ordering required.
6. No guarantee of arrival required.

I think using something like ZeroMQ is more appropriate than using TCP now adays. Of course, thats usually not possible...
Last edited on
I have a lot of past experience developing (but never finishing) online multiplayer games using a mix of TCP and UDP. It's not hard, and the result works well. As a general rule of thumb, use TCP for things that happen less than 5 times a second and use UDP for things that happen more than 5 times a second. This isn't exact but there is almost never a time where this judgement is ambiguous. Movement? UDP. Chat messages? TCP. In general I find that most things are fine in TCP whereas UDP only sees use for things like smooth real time movement.

For example, the only thing that would benefit from UDP in Minecraft is entity movement. Everything else can stay TCP, and now that TCP is not being bogged down by entity movement the multiplayer experience will be better overall.

My point is: don't mess with rolling your own setup. TCP and UDP are well known and well tested and there is no point in trying to reinvent TCP on top of UDP.
Topic archived. No new replies allowed.