Hi, I just wanted to ask this in order to learn a little more about the XNA internals.

I see that some NetworkSession method, like NetworkSession.BeginFind, are implemented asynchronously. That is perfect, since these methods may take a long time to complete. I also see that the NetworkSession class exposes some events that you can subscribe to, like GamerLeft.

Honestly, I was expecting this class to expose an event to asynchronously handle the receiving of data. Or maybe BeginReceive and EndReceive methods simliar to those found on System.Net.Sockets

Having to constantly call networkSession.Update() and then do something like while (gamer.IsDataAvailable) to parse the receiving packets makes me wonder if that is the proper way to implement network communications on videogames. Surely the XNA team will have a reason, and I am very curious about it.

I also wonder about the SendDataOptions enum. used on LocalNetworkGamer.SendData . When using the Reliable or ReliableInOrder option, does the game halts execution to wait for the packet to be delivered?

Thanks in advance for any information provided

 

The XNA Framework takes care of the asynchronous parts of packet sending/receiving, so the Update/while method works well. As for how the various SendDataOptions work, check out Shawn's post in this topic.

 

Having to constantly call networkSession.Update() and then do something like while (gamer.IsDataAvailable) to parse the receiving packets makes me wonder if that is the proper way to implement network communications on videogames.

The actual network data is buffered by the OS anyway. It's not like the machine won't be receiving packets if you're not currently calling IsDataAvailable. The API they chose is one that allows you to very easily actually receive the data where it makes best sense for your game. If you want it to be asynchronous, you can declare your own events, and fire them (with the data) from within your own version of Update(), which is pretty much what the network implementation does. Put it all in a thread if you feel really adventurous.

But, in general, I think it's a fine choice to put "events" that happen seldom in event members, but put the main data pump (that pumps your own, game-specific data) in a polling interface.

Threading is difficult. One of our API design goals was not to force beginners to deal with asynchronous programming. Hence you have the choice between a blocking NetworkSession.Find (which you can either just call on the main thread and put up with the stall if you are a beginner, or call on a background thread of your own if you know how to do that) or you can choose the asynchronous BeginFind version. It's always up to you to opt in to any kind of asynchronicity, so we'll give you an asynchronous completion callback if you explicitly ask for one, but never raise any of the regular session events in an asynchronous context, and there is always a way to do things without any asynchronous programming at all.

SendData never blocks. All the blocking calls have an alternative Begin/End async version.

For most network games, the update loop goes something like:

• Read incoming data
• Update physics
• Send outgoing data
• Draw

For that pattern, a polling model works nicely. In fact this is much more convenient than if network data was delivered by an asynchronous event! Most games are not going to be able to process incoming data if that arrives in the middle of their physics update or draw operations, so if we did things that way, they'd just have to queue the packet in a buffer of their own (and deal with all the associated locking shenanigans) until they reached a safe time when it makes sense to process the new information. Since most games only want to process network data at a specific point in their update cycle, we take care of the necessary data queuing for you.

A handful of genres (for instance a twitch shooter that is optimized for super-low-latency LAN gaming) may want to process network data faster than their display framerate. If you fall in that category, you can just update the session more often (perhaps on a second thread).

I was programming a turn based game where network traffic seldom occurs, so asynchronous networking was an option, but after reading your comments, specially the point that Shawn made about events firing in the middle of a Draw, I am convinced that pooling for data is the right choice.

It is also nice to know that SendData never blocks.

Thanks again.