Having a Detailed Look at the Event Model

You've dealt with the basics of client/server sessions, and peer-to-peer as well. However, thus far you haven't really gotten into the advanced features of networking or how to use them. This chapter will begin to look further into how you should create an efficient networking layer.

You've looked at a few of the possible events that can be fired during the course of a networking session, but haven't yet looked at the exhaustive list and why they actually occur. Some of these events will not occur for certain class types, so the text will be sure to mention which class the event applies to. Without further ado, the events:

  • ApplicationDescriptionChanged Applies to Peer, Server, and Client. This event is fired when the application description has been changed; for example, possibly the name has been changed. If you care, you will need to get the new application description when you receive this event.

  • AsyncOperationComplete Applies to Peer, Server, and Client. This event is fired when an asynchronous operation has been completed. Any of the DirectPlay methods that can return an asynchronous operation handle (for example, the Connect method or the Receive method) will notify the application when they have completed via this event. It is also possible to cancel these methods by using the CancelAsyncOperation method and passing in either the handle or a flag to cancel all operations of a particular type. You should remember that certain operations are automatically cancelled by other actions. For example, the FindHosts method is automatically cancelled when you connect to a session.

  • ConnectComplete Applies to Peer and Client. We've already covered this event when dealing with our client and peer sessions. This event is fired after attempting to connect to a session, even if that connection was not successful. You can check the ResultCode member of the event arguments object to determine whether or not the connection was successful. For example, if the host rejected your connection, you would expect the result code to be HostRejectedConnection.

  • FindHostQuery Applies to Peer and Server. This event is fired when a new connection has called FindHosts and is attempting to find your session. If you do not capture this event or if you do not modify the RejectMessage property of the event arguments, the caller of FindHosts will successfully enumerate this session. Setting the RejectMessage property to true before leaving this event handler will cause the enumeration to be rejected, and the caller will not be able to see this session. A common practice is to use the ReceivedData from the FindHosts call to determine if this enumeration should be successful.

  • FindHostResponse Applies to Peer and Client. This event is fired once a host is found. The event arguments object returned in this event will contain enough information to connect to the server that was found, including the hosts address object and the application description. Since the enumerations happen continuously, if you do not connect to a host immediately, it's possible (and probable) that the same host will be found multiple times.

  • GroupCreated Applies to Peer and Server. DirectPlay allows the creation of groups, which naturally are a collection of players and even other groups. The hosts of a server session or any peer in a peer-to-peer session can call the CreateGroup method to create a new group. After this method has been called and the group has been created, this event will be fired.

  • GroupDestroyed Applies to Peer and Server. When a group is about to be destroyed, this event will be fired. A group can be destroyed in multiple ways, either because DestroyGroup was called, or because the session is ending. If the AutoDestruct flag was used when creating this group, the group will also be destroyed when the creating player has left the session. You can check the Reason property in the event arguments object to determine why the group was destroyed.

  • GroupInformation Applies to Peer and Server. When a group's information has been changed (due to a call to SetGroupInformation), this event will be fired to all members of that group. This event will only provide the id of the group; you will be responsible for retrieving the new group information.

  • HostMigrated Applies to Peer. This event is fired in a peer-to-peer session when the current host has left the session. The new host's player id will be included with this event. This event will only be fired if the host migration flag is passed in when the Host call is made.

  • IndicateConnect Applies to Peer and Server. This event is fired when a player is trying to join your session. Much like the FindHostQuery event, you can reject this event to cause the connection to fail.

  • IndicateConnectAborted Applies to Peer and Server. Once the IndicateConnect event has been fired, normally the next event you would see would be the PlayerCreated event. However, if for some reason the connection was aborted before this event had occurred (for example, the line was dropped), you will receive this event. While this event may not be common, it is important to understand why you might receive it.

  • PeerInformation Applies to Peer. Like the other information events, this is fired when a peer's information has been changed. You will be responsible for retrieving the new information after this event is fired if you need it.

  • PlayerAddedToGroup Applies to Peer and Server. After a group has been created, players (or other groups) can be added to it. When this occurs, this event will be fired with the group's id, as well as the player (or group) id.

  • PlayerCreated Applies to Peer and Server. After the IndicateConnect event has been processed, you will receive this event next informing you that the new player has been created. You may set the player context variable (any application-specific object) during this event (it is a property of the event arguments object). Any time you receive an event from this player (such as receive) you will also receive this player's context variable as well.

  • PlayerDestroyed Applies to Peer and Server. You will receive this message when any player has left the session. Even if the session itself is exiting, you will always receive one destroyed message for every created message you received.

  • PlayerRemovedFromGroup Applies to Peer and Server. Much like the PlayerAddedToGroup event, you will receive this event when a player has been removed from a group. This removal can come from a call to RemovePlayerFromGroup, or from the player leaving the session.

  • Receive Applies to Peer, Server, and Client. This event is fired anytime new data has been received. You will receive a network packet including the data that you have just received, as well as the player id and player context variables of the sending player. This is where the majority of your work will take place. Since it is common to do a lot of work on each receive, it is common to have a separate thread perform these actions so that the DirectPlay threads are not blocked. Also note that you will receive this event for any data you send to a group you belong to, unless the NoLoopback flag is enabled.

  • SendComplete Applies to Peer, Server, and Client. This event is fired when an asynchronous send operation that you initiated has completed. Exactly when you receive this event depends on how the data was sent. If you used the CompleteOnProcess flag, you will receive this event only after the receiving player has processed the message. If you used the NoComplete flag, this event will not be fired at all. Otherwise, this event will be fired when the data has successfully been sent from this session.

  • SessionTerminated Applies to Peer and Client. This event is fired anytime a session is terminated. You may examine the ResultCode member to determine why the session was terminated. This event may also contain user-defined data that could (for example) tell a client to connect to a new server.

  • ClientInformation Applies to Server and Client. Like the other information events, this is fired when a client's information has been changed. You will be responsible for retrieving the new information after this event is fired if you need it.

  • ServerInformation Applies to Server and Client. Like the other information events, this is fired when a server's information has been changed. You will be responsible for retrieving the new information after this event is fired if you need it.



Managed DirectX 9 Graphics and Game Programming, Kick Start
Managed DirectX 9 Kick Start: Graphics and Game Programming
ISBN: B003D7JUW6
EAN: N/A
Year: 2002
Pages: 180
Authors: Tom Miller

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net