Connecting to Another Device (Windows Embedded CE 6.0)

1/6/2010

Networking is slightly different from the desktop implementation, especially when it comes to name resolution.

The embedded implementation supports only a TCP/IP network stack.

Because IP addresses change in a mobile environment, MSMQ depends heavily on the following capabilities:

• The ability to resolve a name to an IP address, such as the Domain Name System (DNS) or Windows Internet Naming Service (WINS).
• The ability to resolve an IP address to a name by DNS reverse lookup or through NetBIOS node status.
• The uniqueness of the name of every device, which must be different from the default.

Statically Configured Networks

In statically configured networks, IP addresses are assigned to computers and rarely change.

DNS provides forward or reverse lookup.

Configuration data can be stored in the hosts file on Windows NT or the HKEY_LOCAL_MACHINE\COMM\TCPIP\Hosts registry key.

This is the simplest way to set up MSMQ and does not require MSMQ to provide registration services or take steps to query WINS servers.

Dynamically Configured Networks

Some networks dynamically provide IP addresses for networked computers and server information, such as WINS and DNS. This is usually accomplished using the Dynamic Host Configuration Protocol (DCHP) and presents a challenge to MSMQ.

IP addresses can change. For example, a device has one IP address when connected through dial-up link and another IP address when connected through a network card. These addresses change every time a connection is established. Changing an IP address means that the DNS name servers must be updated.

Network Tracking

MSMQ supports instant reconnection, called Network Tracking, when a network card is inserted or when a dial-up connection established.

With Network Tracking, if a value of the registry entry CETrackNetwork is set to Yes, there is an immediate reattempt to connect to all target computers.

Effective with version 3.0 of Windows Embedded CE, the information that controls how MSMQ retries failed connections is stored in the registry. This allows you to control this retry schedule and defer connection attempts until LAN hardware is available.

The following list describes registry entries and their uses.

• LanRetrySchedule, a DWORD value, controls tracking network interfaces.
  If nonzero, connection attempts are not made until network interfaces exist; that is, a dial-up line must be connected or a network card inserted.
  If a scheduled reconnection time arrives for a computer, reconnection attempts are deferred by the number of seconds specified by this key. If the value is not set, the default value is 15.
  If the value is set to 0, the presence of a network interface is not checked and the connection attempt is made in accordance with the standard connection schedule.

  Note

  This situation is different from Network Tracking, when a reattempt at connection happens immediately after a network card is inserted or a dial-up connection established.

• RetrySchedule, a BINARY value that contains an array of little-endian short values and controls the retry schedule.
  If the value is not set, the default value is 300, 300, 600, 600, 900 (seconds).
  If the value is set, it must be an array of little-ended short (2 byte) values that make up the retry schedule in seconds. The last number in the schedule is repeated forever.

The connection logic accommodates potential changes in IP numbers. When a DNS query fails, MSMQ uses the MQPing User Datagram Protocol (UDP) to check whether destination computer is available before attempting to reconnect.

MQPing can be disabled by specifying the PingTimeout value of the registry to be 0. Otherwise, it is a DWORD (with a default value of 1000), which specifies a timeout on receiving the reply after sending MQPing datagram in milliseconds.

See Also

Concepts

MSMQ Application Development
Creating Queues
Sending Messages to a Queue
Receiving Messages from a Queue
MSMQ COM Support
MSMQ Security