Perhaps send the "current" server tick as part of the heartbeat?

All replies are greatly appreciated.
Thanks, Xanather.

Too lazy to read every response. I worked on an open-source MMORPG (Open-Tibia) for several years, and I'll answer your questionsto the best of my ability:
1) That's fine. CLR is a good runtime for a server.
2) Use asynchronous sockets. This is generally the best method for an MMORPG. Here's an example from MSDN, where you will find all the reference you need: http://msdn.microsof...y/fx6588te.aspx
3) How many threads you have depends on the nature of your game. Two may be enough, you may find you need more to handle a larger world or higher player levels, I can't tell you that. In Open-Tibia we have three: one for network, one exclusively for scheduling tasks, and one exclusively for executing tasks. This is a pretty good model for a smaller server, but no Open-Tibia servers have ever reached the player levels of, say, WoW; so what the limits of this design really are is unknown.
4) Only players who can see the event (or who are within the general range of sight, in the case of a first-person game, since it would be a ton of overhead to calculate this) should recieve any event. You may find you have more specific needs, say, for a first person shooter a bullet can travel for a longer distance and may need to re-send its own event as it moves into range.
5) This is the only safe way to make a multiplayer game.
6) That's perfectly reasonable, as long as the client is also to be written in C# (may be better to use non-blocking sockets or blocking sockets on their own thread for the client).

Also, don't worry about the latency. Once you get the game up and running, you can afford to host it on a legitimate hosting service provider, and latency will shrink to negligible levels.