I'm currently in the late stages of implementing my first multiplayer game vaguely similar to Bomberman on the SNES. The game currently supports 8 different game modes (deathmatch, ctf, etc) and uses UDP with a network model similar to Quake 3. The actual in game playing part is working great over the internet apart from the odd bug, however the initial connection and game setup leaves little to be desired. Currently each player has to choose the same game mode on their client that the server is set to before connecting and all starting variables for the game modes remain constant between the server and client. If a clients 'connect' packet or the servers 'startgame' packet is lost then the client is simply ignored. My question is basically what is the best way of implementing an initial reliable handshake in which the server dictates the game mode and appropriate starting variables to the client? Thanks :)

I'm not sure what the complication is here. So I'll just offer a simple suggestion - the server can send out the required settings to the client, and the client responds with the settings it's using. The server can then verify that it gets the same settings back as those it sent out, and can assume that client is correctly synchronised. When bandwidth isn't a problem, there's no better way to verify information transfer than to have it echoed back to you intact.

Sorry I probably described the problem badly, thanks for your quick reply though! By my current implementation if either the 'connect' packet from the client to server, or the 'startgame' packet from the server to the client were to be lost the client will simply idle forever (not starting the game). So basically I need a reliable method of setting up the game. I've just skimmed over an article about the TCP 3-way handshake and think a similar implementation in UDP might be the solution. Would this be a good way to go? Sorry I'm kind of new to multiplayer games!

Your basic problem is that UDP is unreliable, and you currently need to transmit couple of reliable packets to get your game to start. There are various schemes to making UDP reliable. The method Kylotan mentions above is one: send your packet, and if you don't get an echo back from the other side saying "yes, I got this packet," you retransmit your original packet until you do. Alternatively, you could use a lightweight library where this problem has already been solved. See the answer to question 7 in the Forum FAQ:

http://www.gamedev.net/community/forums/showfaq.asp?forum_id=15

Yeah, really all you're looking for is a way to know when a message hasn't been received. Generally fixing this is a simple 2 part process - first, decide a way of verifying receipt, typically a response message. Second, note whenever you send a message out that requires acknowledgement and decide how long to wait for a response before assuming your message or the response was lost.

Why not use TCP for that kind of metadata?

You can still use UDP for the gameplay. But you probably want to check that the UDP connection is working before you let them join the game.

Mark