I have read the linked articles in the portion of the forum FAQs that pertains to how often the server should send data to realtime clients. However, even after reading the articles, I still don't understand the proper way this should be handled! Should the server be constantly receiving, processing, and sending data in an infinite while loop, or should this loop include a buffer so that the server doesn't process (ie execute game logic) and send data, say, more than 30 times per second? I was thinking that the former is more feasible (constantly processing and updating clients)-- the client could just keep a queue of messages from the server to be processed, in the case that the server sends packets more frequently than the client renders a frame. This way everything should stay synchronized as long as the client always checks the last couple of messages in the queue when rendering the next frame. Though, the problem with this method is that a malicious client that's not locked to a certain time interval for sending updates could continuously send input to the server, hence making the server update the user's data far too often (x and y coordinates for instance). So this brings me back to the latter method. I suppose I could always check to see if an amount of time has elapsed since the last update of a user's state before performing the update for that particular user, but somehow this feels unneccessary... So, the real question is, how do you guys usually handle deciding when the server should process and send data, with a realtime (~30 fps) TCP client in mind? Am I totally off track here?

It depends on your simulation. Is it time-stepped? If so, the server should time-step the physics that many times a second, and (possibly) generate updates after every step. If it's more of a continuous simulation, you can choose when to send (and accept) updates. Merging multiple fast updates in into a single slower update out is a good way of making sure you don't flood slower links.

Quote:

Is it time-stepped?

Ah yes, if I have the definition of time-stepped correct, then I forgot to consider that everything would have to be time-stepped if I had any AI/physics updates occurring. For now though, I'm just focusing on building an application that will send/receive x and y coordinates used for displaying graphics on the connected clients- ie a client running at 30 fps that displays sprites for each connected user. Even though in reality I wouldn't have to update anything until the server received input from a client, I would still like to treat it as an app that needs to be redrawn at 30fps because I'd like to add enemies, NPCs etc later.

Quote:

If it's more of a continuous simulation, you can choose when to send (and accept) updates. Merging multiple fast updates in into a single slower update out is a good way of making sure you don't flood slower links.

That is a good idea; I never thought about flooding the client with updates. So, if the client is redrawing the screen at 30fps, how often should the server send updates to it? Should the server act like a game running at 120 fps (update every ~8 ms)? Or does this depend a lot on how many users I'm expecting to send updates to?

Also, if the server is updating the game data faster than the rate a client draws a frame, I should always check the last time the client sent input, right?