My point is that what it seems to me by your explanation is that your game loop depends on the receiving of messages or a disconect exception by the client. If none of those arrives, it will be in blocking state forever. You said that the client will send a message every 500 ms, but then you are assuming that the clients will play fair, this may lead to security issues.

Let me try to explain the problem this may cause with an example:
Assuming you will have multiple single threaded servers running multiple instances (each instance is a match where one or more players can play). I can create a hacked client that will:
1) Mimic the behavior of an original program until I get into a new world for myself. Up to here I am a normal client.
2) By the point I should start sending messages to the server, I just don't send anything.
3) The server is in a blocking state, waiting for info that will never arrive.

In this scenario the client will not be dropped because the hacked client can send TCP keepalive packages, which will keep the connection up. This is a "vandalism hacking attack" that your server may be susceptible.
You should set a server-side timeout on this so it will take actions every few ms even if no client sent any messages to avoid this kind of attack. As I said, I don't know anything about C# (I am a C/python programmer), but I believe the method you should look is this one:
http://msdn.microsof...8(v=vs.80).aspx (NetworkStream.ReadTimeout)

Well, that does make sense, but the latency messages arn't necessarily "keepalive" message.

About a hacker trying to crash the server; all the establish-connection related stuff IS in a separate thread (should have probably said that xD), after the client/server handshake with a sequence of bytes then both the client/server go into "gameplay" mode, changing from the "login" mode (the server adds the client to the list of clients for the client to be iterated though on the main thread), the game state also changes on the client side and the client can now play. After that I don't think there are any game related messages that can actually freeze the server. The hacker could surely freeze the thread in the separate "establish-connection" thread, but that'd be pointless lol (but they could also create a infinite amount of pointless threads by doing this, I actually thought of this and will probably implement a timeout value so the hacked client just gets dropped, liked you said).

That is not necessarily the right thing to do. Async development needs more careful design and planning than that.

Haha yeah I know xD

Thanks,
Xanather.

Not only that (creating loads of useless threads), sometimes you have small interpolated actions based on last time difference.
For instance, on a general approach, you have the movement calculated in something similar to (this example is a client server game I coded for college some time ago):

[source lang="python"] def calcNewPosition(self, movespeed, timeInterval, ang):
posTuple = self.getPos()
x = posTuple[0] + (movespeed * (timeInterval) * sin(radians(ang)))
y = posTuple[1] + (movespeed * (timeInterval) * cos(radians(ang)))
z = posTuple[2]

return (x, y, z)
[/source]
If the client can "freeze" the server, it may make the time inverval vary so much that it will end up "teleporting" in the game. If this happens, the collision calculation won't be effective and the character may end up being able to cross walls, fly or just create some unhandled situation that may end up with a crash.