Asynchronous Networking with the DirectPlay Protocol

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:

• When the DirectPlay protocol is active, synchronous nonguaranteed sends may block because of throttling. By setting the asychronous flag on your sends, you can get the nonguaranteed sends to return immediately and prevent your game thread from blocking.
• Even though the DirectPlay protocol makes better use of the network link, you still have to think carefully and minimize the amount of data you send. Always, less data per state update is better, and the goal is to get more updates per second to improve the user experience.
• When you are making asynchronous sends, the protocol makes a copy of the send data so you can reuse your buffer (or allocate your messages on the stack), so remember that every sent message that is still in the pending queue represents a memory allocation as big as that send, and don't let the send queue grow without limits. There is generally no advantage to letting the send queue to a particular player grow beyond 16 sends. The number of messages in the send queue is absolutely limited to 29 by the current implementation of the DirectPlay protocol. Any additional sends will not be sent concurrently—that is, they will wait for other sends to finish before they put any packets on the network link. You can check the send or receive queue for an individual player by using GetMessageQueue.
• Do not get confused by the difference between the send queue to a particular player and all the send queues. When you are throttling sends, you generally want to get the queue for the player you are sending to and not for all the players. This also means you will probably want to use directed sends rather than group sends.
• If you always find the send queue is empty, you should send at a higher data rate in order to improve game synchronization. Since the protocol feeds back from the receiver, there is no danger of swamping the receiver. An empty queue is wasted bandwidth.
• Don't loop tightly when checking the queue—sleep in between. A constantly spinning thread can use all the CPU cycles. You can adapt the sleep period based on how long it takes the queue to get down to a level where you usually issue another send.
• The send queue represents a backlog. The longer the send queue is, the longer the latency of additional sends. If the queue is growing too large or too long, cancel messages.