Hosting the Session

When you're trying to get started in a peer-to-peer session, a "first" connection must accept the incoming network data from the other peers. In normal terms, this player is considered the host, even though each peer in the session is in reality its own host, considering that it holds its own data and so on. The player who is the host of this session must call a special method, Host (fancy that), to get the session started, so add the code from Listing 16.4 to your class now.

Listing 16.4. Hosting a Session

 /// <summary> /// Will host a session on your computer /// </summary> public void Host() {     // Update with your information     PlayerInformation info = new PlayerInformation();     info.Name = Environment.UserName;     networkDevice.SetPeerInformation(info, SyncFlags.PeerInformation);     // Create the application description     ApplicationDescription desc = new ApplicationDescription();     desc.SessionName = Environment.UserName + SessionName;     // Should be a relatively unique name     desc.MaxPlayers = 2; // 1 on 1 battles     desc.GuidApplication = gameGuid; // Unique ID all games will use     desc.Flags = SessionFlags.NoDpnServer; // We don't want to use the server     // Now host the session     networkDevice.Host(desc, deviceAddress, SessionName); } 

Before hosting the session, you set the username of your peer to the username you're currently logged in as (using the Environment class from the .NET runtime). Most calls in DirectPlay happen asynchronously on different threads, so when you actually call SetPeerInformation, you do so with the SyncFlags enumeration to ensure that it only happens on this thread, and the call doesn't complete until it has finished.

After you set your player name, you're ready to host the session. If you look at the Host method, you'll see that it requires an application description to be passed in. You create that structure and set the four properties you care about. First, you set the session name, which a player could see if you were allowing that. You also set the maximum number of players to two (for some intense one-on-one action). The application Guid is the unique identifier for Tankers that you specified earlier.

The last flag is somewhat special. In the default case, when a session is hosted in DirectPlay, a new process is spawned called DpnSvr. The purpose of this process is to listen for connections on a particular port and then forward them onto the correct applications. This process allows more than one application to be listening for connections on the same port, but a performance cost is incurred by doing so. (A whole other process is running.) Not allowing this process to spawn is the goal of this flag, and it could cause the application to fail when trying to host the session if another application is already using the port. If so, simply change the port you're using.

Next, you're ready to host the session. You pass in the application description and the device address you're using to host the session on, but why did you also pass in the session name? This parameter is the user context parameter, which allows you to provide an arbitrary identifier or a context-based instance relevant to the action taken in the event handler. In this case, you're providing an identifier (SessionName) to uniquely identify any events fired by the hosting peer. Because the player creation event is fired during the call to Host (after all, you are a player as well), you want a quick and easy way to detect whether the player being created is the local player. This parameter is the easiest way to do so. Later in this chapter when I discuss event handling, you will see this part in action.