| ?/TD> |
| Microsoft DirectX 9.0 |
The Bluetooth wireless technology service provider is a low-cost, low-power wireless technology designed to simplify setting up network connections between devices. This topic describes how to use Bluetooth with the Microsoft?Windows?Powered Pocket PC 2002.
Native Bluetooth support in DirectPlay is designed for hosting sessions where all players in the session are also using the Bluetooth service provider. In this scenario, all players must be located within Bluetooth radio range of each other to participate. DirectPlay does not support using a mixture of service providers within a single session. Note that Bluetooth can also be used as an access technology for other network types. For example, a player might obtain IP connectivity using a Bluetooth Network Access Point. In this case the Bluetooth device is essentially invisible to DirectPlay, and an application should use the IP service provider instead.
The Bluetooth service provider for DirectPlay provides feature parity with the IP service provider. All session types are supported—client, server, and peer—together with the full set of features from each. However, some minor variations in setting up addresses and enumerations with Bluetooth are described here.
Applications should always check to see if the Bluetooth service provider is available before attempting to use it or offering it as an option to the user. Use the IDirectPlay8Peer::EnumServiceProviders or IDirectPlay8Client::EnumServiceProviders or IDirectPlay8Server::EnumServiceProviders method to see if Bluetooth is available.
If the Bluetooth service provider is found, applications should set Bluetooth as the service provider for the address object by calling IDirectPlay8Address::SetSP as illustrated in the following example.
IDirectPlay8Address* pAddress;
hr = CoCreateInstance( CLSID_DirectPlay8Address, NULL,
CLSCTX_INPROC_SERVER,
IID_IDirectPlay8Address,
(LPVOID*) &pAddress);
.
.
.
pAddress->SetSP(&CLSID_DP8SP_BLUETOOTH);
When creating IDirectPlay8Address objects, applications need to specify the address of the host device with the Host Name address component. Each host name should be specified as a string using hex format as shown in the following example.
WCHAR * wszDeviceAddress=L" 50c20003c418"; pAddress->AddComponent(DPNA_KEY_HOSTNAME, wszDeviceAddress, (wcslen(wszDeviceAddress)+1)*sizeof(WCHAR), DPNA_DATATYPE_STRING );
Address objects supplied to the application from DirectPlay as the result of an enumeration operation may be enhanced by adding the name information component. This specifies the name of the Pocket PC 2002 device the address represents and provides a more user friendly string to present rather than the Bluetooth device address. Therefore, applications should test for the presence of the DPNA_KEY_NAMEINFO field when displaying the result of enumerations and present it to the user if possible. Note that this field is purely an informative one and is not used by DirectPlay in anyway. Applications creating their own address objects rather than obtaining them using enumerations should always use the DPNA_KEY_HOSTNAME field to specify the address of a remote device. Connecting to a device using purely the DPNA_KEY_NAMEINFO component is not supported.
When enumerating Bluetooth devices, DirectPlay first attempts to discover all the Bluetooth devices in the area. Each device found is contacted one at a time and sent an enumeration request. This process is hidden from the application but the initial device discovery process can take 10 or more seconds to complete. Therefore, a call to IDirectPlay8Peer::EnumHosts or IDirectPlay8Client::EnumHosts will generate no responses initially and then a rapid sequence of responses after about 10 seconds.
Because of the time it takes to enumerate and because Bluetooth addresses are fixed for each device, it is recommended that applications provide a mechanism to store the last few addresses to which a player connected. This allows a user to pick from a list of recent connections rather than needing to type in a hexadecimal address each time or wait for the enumeration to complete.
A call to EnumHosts works slightly differently with the Bluetooth service provider. The following parameters are different.
Attempting to connect to or host a session automatically cancels any running enumeration. When connecting causes the enumeration cancellation, the result code for the enumeration supplied in the DPN_MSGID_ASYNC_OP_COMPLETE message will be DPNERR_CONNECTING. When hosting causes the enumeration cancellation, the result code will be DPNERR_HOSTING.
Due to the limits of the Bluetooth specification, the maximum number of devices supported in a peer-to-peer session is eight. For a client/server session, up to seven clients can connect to a single server.
Host migration can take several seconds in Bluetooth, and during this period no data transmission occurs between devices. Therefore, if the host player drops from the game, any messages sent by the remaining players will be queued during the time it takes to reestablish the network connectivity.
Bluetooth is essentially a client/server architecture. Although DirectPlay hides this and offers a peer-to-peer mode with host migration, all data still has to be routed through the host in this scenario. Applications should consider this when making assumptions about latency and available bandwidth.