In the previous parts of this articles I’ve talked about the service components of the XNA Streaming system. In this part, I’m going to talk about the Communication Broker.
The role of the Communication Broker is to cover the communication with the Streaming Service. By doing so, the code required of client applications is simplified, and less duplicate code will be generated for each application using the system. the broker also caches all variable changes and periodically sends all changes accumulated to the service, thus reducing the number of calls per second required by a single client to a predictable amount.
The broker uses a synchronized queue to accumulate changes and a timer to periodically clear the queue and send the resulting TimeSlice to the Streaming service. A receive background worker is used to reconstruct changes received from the Streaming service and raise appropriate UpdateProperty events.
The main operations provided by the broker are:
Start: used to start the processing of the broker by registering with the Streaming service. If the game is run in broadcast mode, this method starts the timer for the periodical TimeSlice send. If in observer mode, the broker requests the whole state from the Streaming service and raises the UpdateGameState event, to allow the application to initialize its state.
Stop: used to stop broker processing and to unregister from the Streaming service.
The events exposed by the broker are UpdateProperty, UpdateGameState and OutOfSynch. The first two events are to be sued by the application to change the value of a single property, or of all properties controlled by the XNA Streaming system. The OutOfSynch event is raised whenever the intervals between two consecutive slices do not match. The application can decide what to do at this point; for example, it could ask for the whole state of the game from the broker, which in turn would make the request to the Streaming service.
The application has to implement the GetCurrentState method of the IObservableGame interface in order to provide the broker with the current state of the application when needed.
Considerations for Writing Applications
There are some aspects that have to be taken into account when writing or adapting applications that use the XNA Streaming system.
User input has to be converted to changes of values. For example, mouse movement in a 3D environment can be translated into a set of 3 camera angles that completely define the way the camera is pointing. Pressing a button can be translated into a boolean flag set to true.
For simplicity, (most) user input should be ignored when in observe mode in order to avoid conflicts in UI commands that could have unpredictable effects.
One should take into careful consideration whether a piece of information is a “user input” variable, or a result of a law being applied to an initial value. Variables that are not broadcast have a high chance of being out of synch between the broadcaster and the observers. If the effect of such a variable is not critical (e.g. hit/miss decision) then it can be left out of the TimeSlice. Otherwise, one might discover that it is possible to miss a target, but hit it at the replay.
Results
The resulting prototype of the XNA Streaming system was presented at the 2008 edition of the Romanian Microsoft Community Bootcamp.
Conclusion
The XNA Streaming system is a good first prototype or toy, but it is by no means a decent communication framework. Aspects such as security, collaboration, dynamic send permissions, multicast, unicast and data conflict resolution have to be solved in order to obtain a communication framework.
I’d say it’s an okish communication framework :). Anyways, I think that we will see this idea in the future more often than one might think.