Alo I have a multiplayer card game. On my client I received 2 message. message no 1. The player profil message no 2. List of players public void getPlayerProfil(GameEvent event) { ... Create a player instance ... } public void getPlayerList(GameEvent event) { ... Some code depends on the player object .. } Sometimes I get the message no.2 first which is not good. Should I use some kind of locking or is the only way to only received 1 message with playerProfil and playerlist. Thx in advance

It's hard to help with how vague your post was...

are you receiving message no. 2 first sometimes because you are using unreliable or un-ordered UDP?

if it's not that, then it's just a problem in your logic somewhere.... just have the client request for the list of players AFTER receiving the player profile.

This would generaly mean you are using UDP, and that means you are going to need to implement a form of packet ordering yourself, since you cannot be dependent on an ACK packet as you would with TCP. Basicaly the simplest thing to do is switch to TCP , which should do this for you automaticaly. Another less-simple-but-still-simple-nonetheless thing you can do is have a packet header attached to each UDP packet. Have a certain segment of memory dedicated as an integer and require them to increment and be in order during execution. You can also get cute and add an expiration stamp on each of the packets.

Why not include in the header of the packet what function should handle it? Not a name but more a code like PROFILE 1, LIST_OF_PLAYERS 2 or something? That way the order it arrives doesn't matter, or you drop it until you get the packet you want then request the next one?

Just a throught.

To be honest, I see no particular reason why you would want to use UDP in this particular situation. Basicaly if you need sockets that implement both ordering and awknowledgement (knowing that they got there), you are just reimplementing TCP...

Paul,

That is simply un-true. There are several things that reliable UDP offers over TCP - NAT punch through, better scalability because you are only using a single socket, etc... Also, many, probably MOST games, require SOME things to be reliable and other things to not be reliable. The only way to accomplish this w/o problems (mixing TCP and UDP can cause problems) is to write a reliability layer over UDP. I'm sure someone could explain it better then me but there are many reasons that make what you said un-true.

You are correct graveyard filla, sorry for spreading misinformation, wasnt my intention. You pointed out many very valid reasons to go with UDP over TCP, it didnt cross my mind at the time they would be refering to something _IN GAME_. It looked to me like a simple lobby-esqe scenario, where writing an entire TCP-like interface layer over UDP SEEMED LIKE major major overkill in my mind (though not unusefull perse, just not worth it to me). the fact of player profile and list of players is what pointed me in that direction.

Then again

If this is a peer to peer or LAN based game (where multicast would be used) then UDP will be the godsend. If your just logging into a lobby to get results, generaly you should be fine IMHO (go ahead and disagree if you will on that one graveyard)

Paul,

I never meant to say that TCP isn't useful in games - sorry if that's how my post appears. TCP is perfectly acceptable, in plenty of games. And in fact plenty of commercial games use TCP. I'm pretty sure that WoW uses TCP in at least some of their code - I know Ultima Online is fully TCP based, and I'd bet that the majority of RTS games use TCP. Best tool for the job kind of thing. [grin].