I am working on a windows game and I am trying to understand the XNA GameComponents and GameServices classes and use. From what I understand about a component is that it has an Update method that gets call in every frame, and a service can be referenced from other components if needed.

So the way I think a network component would work is that in its Update method it would receive and send data. It probably makes sense to receive the network data once per frame, but it doesn't for sending it. Shouldn't the game send its own updates to others the moment it has it to cut down on lag?

  • 1
    \$\begingroup\$ My recommendation is to attempt to write your code using neither of these. IServiceProvider is for something that you don't need. And GameComponent just obfuscates your code flow and makes it harder to craft a nice actor interface (which, in your case will probably need custom Serialize and Deserialize methods for network replication). \$\endgroup\$ Mar 17, 2013 at 15:19
  • \$\begingroup\$ xna can be prone to slowdown due to many factors, and therefore Microsoft introduced GameTime.IsRunningSlowly into the framework, so that this can be checked. If you have the network attempt a tick, or sync, within a standard xna update method, you cannot guarantee that the time interval is constant. You need to implement some sort of callback on the way in which you update the time interval, and handle network messages within that interval. Both are interlinked. My suggestion is to thread the tick or sync message, and let it cycle at 1/60 seconds independently of the main game thread \$\endgroup\$ Mar 18, 2013 at 5:47
  • \$\begingroup\$ "Shouldn't the game send its own updates to others the moment it has it to cut down on lag?" Games often coalesce messages into fewer, larger packets sent less often. This may mean delaying updates by a few milliseconds, or using client side prediction & interpolation to smooth out the gaps, but you save a lot of bandwidth. Data rates may be a platform certification requirement, or just a nice thing to do for your customers who pay through the nose for cellular data. \$\endgroup\$ Mar 18, 2013 at 21:40

1 Answer 1


I would suggest looking at threading to communicate so you know when you lose connections and when to drop that client from your list. There is a good example of this here. A server that uses a COM object will run as a service automatically and may still run even if you close your APP...

I would run the clients and severs as a class and create them on the heap rather than the stack.


Not the answer you're looking for? Browse other questions tagged .