My proposed plan to handle client/server player movement Using TCP(Just hear me out), for a tile based multiplayer game. All this happens very fast in order. -Client On KEYDOWN client sends ONE forward movement request to the server (so even if they keep holding down the key for 20 seconds only one movement forward request was sent). Regardless, the client begins to move the players character forward every 500ms. At this point the client does not wait for the server to respond before moving the players character forward. -Server Server receives the forward movement request, and also begins to move the player forward every 500ms. How does it do this? The server adds the movement request to a "movement queue" for that player (yes each player has a movement queue). If 64 players are connected the server will loop through all 64 players (in a thread locked, safe environment meaning the actual queue is locked) every 500ms and process their movement requests. -Client On KEYUP client sends ONE stop movement request to the server, etc.... ...... Question... What if the server & client end up out of sync? I will have the server send a "sync check" to the client to ensure both the client & server are synced. What would this result in? The player may experience their character being sucked backwards or something. Things to ponder. Can someone please let me know if this method is feasible, if it is currently being used professionally... Or am I just way off here?! Thanks. Luzarius [Edited by - luzarius on May 24, 2006 1:51:21 AM]

You might want to consider throwing snapshot positions back in response to a stop move. Empirical updates are always useful, but more so under UDP (where some packets may or may not have been received).

Providing your socket's non-blocking, the approach you have should work.

On the server, your movement requests are being processed in a separate thread? I wouldn't maintain a queue for each client (TCP is sequential anyway). Just throw all the movement requests into a single queue with a client ID, and ensure you recv on a cycling basis - look into socket pools. You then have less containers to worry about threadlocking.

The way I do this is by having my socket pool (manages all open sockets) fill a vector of sockets when doing a select. Only when I've processed all those sockets do I call select again. If I run out of sockets in a given server tick, I can move on to do some housekeeping (clearing old packets etc). If I don't run out of sockets I have a lag situation and I should really look at what's going on. ;-)