The information is encoded in (<property name>, <value>) pairs. All serializable data types are supported for values. Users register with the Stream Service either as Broadcaster or as Observer. After this step, the Broadcaster uses the service to send updates for information (property-value pairs). Observers get notified by the service of the updated information via a IXNAStreamCallback callback contract, a feature of WCF services.

Updates for a certain variable can occur at a very high frequency (camera angle in a 3D application). If a separate call to the service would be generated every few milliseconds, then the service would easily become overwhelmed by the calls. The solution chosen is to “buffer” several information changes and send them all at time, at set time intervals. We name this “buffer” a TimeSlice. A time slice has a Duration and several time slice entries. A TimeSliceEntry has a PropertyName, a Value and a SliceOffset, used to express the time since the beginning of the TimeSlice when the value change has occurred. This way we gain control over the number of calls made to the service.

The Stream Service provides the following operations:

RegisterCallback: used to register with an application (given by name) for a role (given as a member of a GameMode enumeration). Only one Broadcaster can exist. This operation involves storing a user’s callback interface instance in a dictionary that has the application’s name as key and a list of callback interfaces (IXNAStreamCallback) instances.

UnregisterCallback: used to safely end a registration with an application (if a client does not unregister, sending updates or requesting the overall state would fail).

UpdateStateVariables: used to send a TimeSlice to all subscribers of an application. This is the actual method that performs the broadcast. It uses a method defined in the callback contract to broadcast the TimeSlice to all registered clients except the broadcaster.

GetCurrentState: to be used by an Observer in order to resynchronize with the broadcaster. This method should be called right after registering with an application. The GameState returned is a collection of game state entries. Each GameStateEntry contains a Key (the name of the variable) and a Value. The Stream Service request the current GameState from the Broadcaster via the callback contract.

The IXNAStreamCallback contract contains the following operations:

StateVariablesChanged: service calls this method for Observers whenever it receives a TimeSlice from the Broadcaster. It is up to the client to reconstruct the information changes in the TimeSlice with proper timing.

GetCurrentState: service calls this method for the Broadcaster whenever it receives a corresponding request from an Observer. The method returns the current GameState.

The Stream Service does not provide complex functionality, in order to make the actual information broadcast as fast as possible. The more complex functionality is implemented in the Communication Broker, that will be described in the next part of the series.

The main responsibility of the File Transfer Service is to provide access to streamable games. The service stores the game files in a database table, together with their relative file paths. This way the file system structure can be recreated when downloading the game. The game’s name, author and a short description are also stored in another table.

The operations that the File Transfer Service supports are:

• Create a game with no files: This operation simply creates a game entity with the game’s name, author and description with no files.
• Upload a file for an already created game: This operation stores a file together with it’s relative path to the game’s folder for a previously created game. This operation gets invoked for each file in a game’s folder.
• Delete a game: Removes a game from the database together with its files.
• Get all uploaded games: This operation returns a collection of general information about uploaded games (game name, uploader and description).
• Get all relative file paths for a game: This operation returns a collection containing the relative paths for all the files of a game. This list can be used to download each file and save locally.
• Download a file from a game: This operation downloads a file specified by the game to which it belongs and its relative path to the game folder.
• Get start up information for a game: This operation returns the game’s name, which is used to identify the streamed game at runtime, the address and endpoint name for the Streaming service. This information is used to start a game, both in observe or in broadcast mode.

The download/upload of each file takes place through streaming. This limits the in memory portion of a potentially large file at any moment to the size of the buffer of the stream. Stream parameters and return values are a feature of WCF services.

The File Streaming Service has as UI an XBAP that helps in uploading, downloading and starting a game.

As I mentioned in my previous post, at this year's Microsoft Community Bootcamp I entered in the demo competition together with Adi. We've had some issues in the past with (cheap) broadcasting of presentations. There are plenty of professional tools out there that accomplish this goal, but that's not my point. My point is that I have not yet found a cheap (free) utility that will allow me to give a presentation to several viewers that may not be in the same room (or the screen isn't big enough for the whole audience).

Given this background, Adi proposed we create a way in which several people can see the same thing that a broadcaster transmits. Further, the "thing" that everyone sees is actually an XNA game, that could might as well be an interactive presentation in 3D.

Description

The main idea is that, given an XNA game (possibly a game that did not take into consideration broadcasting though our "system"), produce a mechanism such that a broadcaster can transmit the content on the screen to any number of observers. As infrastructure for communication a WCF service was chosen. The reason for this is because it is relatively quick to implement and set up, it supports binary protocols and also bidirectional, asynchronous communication via service callbacks.

The first idea that comes to mind when deciding what to broadcast is whole images, pixel by pixel. The trouble with this is that if we have an application with resolution of 800x600 pixels, 32 bit color depth, at 60 frames/second, then we would require at least 109 MBytes/second/observer. This is totally unacceptable. Even with video compression, it would still require substantial bandwidth.

Instead, we decided that we could reduce the whole state of a game to a few state variables and a few "laws" that govern how these state variables evolve in time. Transmitting only some state variables proves to require much less bandwidth than transmitting the whole image. To further reduce the size of the messages transmitted, we identified 2 categories of state variables: the ones that are directly influenced by a user (through keyboard input for example), and the ones that have an initial value, and a law that dictates it's evolution in time. The state variables that evolve independent of user input can be left out of the "frame-by-frame" transmissions, and just the initial value has to be transmitted.

XNA Streaming Components

Given the initial description of the system proposed, we decided initially on three components:

The Streaming Service, that would receive calls from the broadcaster when state variables change and then transmit those changes through callbacks to all the subscribed observers. Aside from this main communication channel, the Streaming Service also provides initial synchronization for observers, meaning the service prompts the broadcaster (through a callback) to send the whole game state each time a new observer connects.

The File Transfer Service is responsible for storing all "broadcastable" game binaries,  delivering them to clients and providing startup information for each game (Streaming Service address).

The actual game, which has to be able to run in two modes: broadcast and observer. The game makes service calls to transmit/request state variables and responds to the callbacks of the Streaming Service.

At this point we analysed the communication between the game and the Streaming Service. Everything seemed fine, except for one detail: if we have a camera component that provides tens if not hundreds of new values every second, and we take into consideration that we have more than just the camera in a game, we can see that the number of service method calls performed by the broadcaster to transmit state variable changes is in the order of hundreds (at least) per second. This will cripple the service, regardless of the hardware it runs on (provided we stick to the "cheap" area...). A way to seriously cut down the number of service method calls was needed.

One way to reduce the service calls is to buffer the state variable changes, i.e. store each value together with the time at which the change occurred, and after a specific amount of time, send all buffered variable changes to the service, which in turn redistributes them to the observers, which reconstruct the sequence of state variable changes using the information received and timers. We call each such buffer a TimeSlice, and a touple of the form <VarName, VarValue, TimeSpan> a SliceEntry, where the TimeSpan is the time interval passed since the beginning of the current TimeSlice.

At this point we decided to call the new component a CommunicationBroker. It became clear that all code that would involve the Streaming Service would now be placed in the CommunicationBroker, and that sending calls/responding to the Streaming Service can be abstracted through this broker. In fact we now obtained an XNA Streaming Framework. This significantly reduces the complexity of the code that is necessary in the streamed game. Further more, now we had an actual streaming part, we stream the variable changes.

This is the end of part one of the article. In subsequent parts, I will describe each component in more detail and present some preliminary test results.