Platform SDK: DirectX |
When you are designing a network gaming application, the object of the networking code is to provide the basis for a synchronized game environment to many players. The networking code must handle many different network environments which may provide low or high latency, low or high bandwidth, and varying reliability.
Before the advent of DirectPlay, it was left to the game developer to determine the characteristics of the network link and adapt the game appropriately. Typically, the solution developers applied was to minimize the amount and frequency of the data sent. Although this approach provides a solution that works well in the harshest environments, it does not provide the best gaming experience to the end user. In many cases, the game could send many more updates or more information per update to enhance the user experience and keep tighter synchronization of the gaming environment.
The goal of the network code should be to use all available bandwidth for updating the game state. At the same time, the code must avoid backlogging the connection by sending faster than the link can handle, which leads to higher latencies and worse game synchronization.
The DirectPlay protocol and asynchronous messaging provide an environment where the network code in an application can determine the abilities of the link and adapt its behavior to make the greatest use of available bandwidth.
The DirectPlay protocol uses feedback from the receiver, letting the protocol know how much data is arriving at the receiver. Unlike existing network protocols, the feedback allows the DirectPlay protocol to precisely control its sending rate so as not to build up a backlog of message packets between the sender and the receiver.
The DirectPlay protocol also applies this feedback to nonguaranteed messages. This throttling of sent messages not only guarantees that the client application does not introduce excessive latencies into the game by creating a backlog, it also allows the client to adapt itself. By viewing the send queue, the client can recognize when it is sending data faster than the link can deliver the data or when the client is not using nearly the available bandwidth. This gives the client the opportunity to adjust its sending strategy to the capabilities of the existing link.
In order to take maximum advantage of the DirectPlay protocol, you should send messages asynchronously. (For information on how to do this, see Asynchronous Messaging.) Messages sent asynchronously do not block. When you send a message asynchronously, the send is not completed when the call to SendEx returns. Instead, the send will complete at a later time and inform you by posting a completion message to the receive queue.
If you use asynchronous sends, the DirectPlay protocol can be sending many messages, both guaranteed and nonguaranteed, simultaneously on a link. That is, the protocol does not wait for the completion of one message before sending another. This prevents single packet losses from hurting link use. It also prevents the loss of one guaranteed packet from slowing the delivery of other guaranteed messages.
Typically, network games have used nonguaranteed messages only for transferring a real-time game state. The primary reasons for this strategy are that sending a nonguaranteed message generally does not block and that many nonguaranteed messages can be sent without waiting. The DirectPlay protocol enables you to send guaranteed messages that do not block and to have many outstanding guaranteed sends on each connection. This means your game can use guaranteed sends and be just as responsive as a game that uses nonguaranteed sends. This can greatly simplify the design of your game state updates and allows you to use incremental updates, which are almost impossible with nonguaranteed sends.
There are a few things you must watch out for when using the DirectPlay protocol: