Quick NAT Compatibility Guidelines

Following these guidelines will help you maximize your application's compatibility with Network Address Translation (NAT) devices, proxies, and firewalls.

• Keep host enumerations active while connecting.

  Ending a call to EnumHosts before calling IDirectPlay8Peer::Connect or IDirectPlay8Client::Connect on the same interface might close a virtual connection that was established with some NAT devices. This could prevent the call to Connect from succeeding. Instead, specify INFINITE for the dwEnumCount parameter when calling EnumHosts and let Microsoft?DirectPlay?stop the enumeration for you when the call to Connect completes successfully.

• Avoid relying on DPNSVR.

  DPNSVR can simplify discovering multiple hosts on a single computer or a migrated host, but packets sent to the DPNSVR port can seem like separate connections to many NAT devices. They might not be forwarded in the same way as packets sent directly to the game's port. If you use DPNSVR, you should enumerate both the DPNSVR port and the game port when possible. See Using the DirectPlay DPNSVR Application for more information.

• Use default ports but allow user to override if necessary.

  You should let DirectPlay select the local device port to use by default. The addresses returned by IDirectPlay8Peer::GetLocalHostAddresses and IDirectPlay8Server::GetLocalHostAddresses can be used to identify the port actually selected for hosts. Your game can then use external means, such as DirectPlay Lobby match-making, as a way to get the host's addresses to clients. However, applications should still provide the option for users to select a particular port. Some NAT scenarios require the end user to manually set up port-forwarding and they will appreciate the greater flexibility. See Understanding Ports for more information.

• Use the client/server topology.

  Every player in the peer-to-peer topology must be able to communicate directly with every other player. This increases the chances that any particular player is prevented from joining a session successfully because of one or more NAT devices. Use the IDirectPlay8Client and IDirectPlay8Server interfaces to be sure that as long as the client can reach the host, it can join the session.

• Avoid hosting behind NAT devices that are not Universal Plug and Play (UPnP) compatible when possible.

  Almost all NAT issues involve accepting inbound connections through a NAT. IDirectPlay8Peer or IDirectPlay8Server hosts require inbound connections by definition, and are therefore most susceptible. Hosting only on the open Internet or behind devices that support UPnP simplifies the NAT limitations presented to the user.

• Use match-making services to hide address complexity from user.

  When NAT devices are involved, a player might have multiple addresses even though the computer only has a single physical network interface. Most users will not know which address is correct for a given situation. Your application should use match-making services to pass a combined address returned by IDirectPlay8Peer::GetLocalHostAddresses or IDirectPlay8Server::GetLocalHostAddresses to the client application for a better user experience. You can also use match-making to facilitate advanced NAT traversal techniques. See DirectPlay Lobby Support for more information on match-making.

These guidelines and example implementations are described in more detail for each topology.