I am making my first multiplayer game (I've done a bit of TCP/IP sockets programming before though). As I said, it's a first person shooter so following the forum FAQ I'm using UDP. I have a few ideas about how I'm going to do this and I just want some of you people with more experience than me to make sure my design makes sense. Each packet will have the first two bytes be the size of the packet, and the third byte will be an ID indicating the purpose of the packet. After that, each packet will be unique depending on what it does. I have a dedicated server exe as well as the client exe, and I think this presents a problem (if you want to host and play at the same time, you'll have two things fighting over the same port). To resolve this, I'm going to have two sockets for each the server and the client - one to send data on, and one to recieve data on. Each player in the game will have their own unique ID (a short), which will be known only to the player and the server. This way the server can tell what player is sending what, and a hacker couldn't simply change the ID to another player's ID to mess with them. Does all of this make sense, or are there better ways to do these things?

a few ideas:

http://www.gamers.org/dEngine/quake/QDP/qnp.html

You might also want to check this out: http://enet.bespin.org/index.html

Enet looks decent, but it's written in C which makes it ugly at best, and clumsy and hard to use at worst. Is there an OO version out there?

Sending and receiving on diffenrent ports will make playing through NAT not work right.

If you have server separate from client, you should have the server always bind to port X (specified by the user, with a default by you), and client bind to port 0, which means "assign any free port". It doesn't matter what port the client runs on, because the server will always call recvfrom() to receive data, and will reply back to the same address using sendto().