Network Awareness

In the past, network-connected machines were stationary devices permanently connected to a network. Applications were developed with this assumption in mind. In the new world of wireless access and mobile devices, application developers can no longer assume that the network is always present or that there is only a single path to a resource. Even though the Transmission Control Protocol (TCP) has complex algorithms to ensure guaranteed delivery, it cannot overcome the transient nature of the mobile user s network environment. Both wireless networking and grab-and-go docking mean that network connections and external hard disks can become disconnected without warning. Although this has always been a concern of desktop applications, these potential problems become much more common on mobile PCs. Applications should be able to handle these dynamic and divergent network environments.

Although each application has its own unique constraints on network behavior, developers should consider implementing several features:

• Implicit online/offline switching If your application has two separate modes for online and offline behavior, take advantage of the network presence detection in Longhorn and switch between them automatically, without requiring user action or approval.

• Background and cached file writing Rather than locking the UI when writing to a file, save immediately to a known local file, and attempt to update the real file in the background.

• Delayed file writing Add functional dexterity by allowing users to save and close a file without the storage available. Prompt users for actions only when necessary (for example, if the online and offline versions become unsynchronized).

• Cache copies of embedded or linked data For example, at a minimum, keep a static representation of all objects in your file as bitmaps. That way, if the source disappears, users can at least perform basic rendering.

You should continue to design your software to account for sudden disconnection from network resources, including the capability to automatically or manually store data on a local device, and use time-outs on all network actions. Some considerations in this regard include the following:

• Handling sudden removal and addition of network connections and peripherals.

• Implementing operations that can recover if problems arise, such as load or save operations to a USB, 1394 hard disk, or CD peripheral. Then, when such operations are interrupted with a docking or undocking action, they can be restarted later.

• Using best practices for network connectivity. Your application should operate seamlessly in situations where networks are temporarily unavailable or set or reset themselves . For example, your application should include the following capabilities:

  • Handle connectivity transitions.

  • Provide auto reconnection that does not require restarting the application.

  • Give clear feedback of network availability so that the user is aware of this state.

  • Have the ability to be used offline. It is not unusual for a wireless network connection to be intermittent or for users to be offline for a short time without realizing it. Your application should behave seamlessly in these situations. The application should not stop responding while the network is unavailable.

  • Implement automatic synchronization capability when a connection is reestablished, if your application needs to synchronize offline and online data. It is tedious for users to have to remember the explicit steps for synchronizing. Manual synchronization is unnecessary if your application can detect a reconnection to the network and can run automatic data synchronization.

You can choose from many methods to make both streaming and transactions applications perform quickly and effectively across transient and low bandwidth networks. MSDN provides several white papers that deal exclusively with that subject. Briefly, these white papers conclude that a well-written network application should provide the following features:

• Limit the number of small transactions. Roundtrips between server and host are expensive.

• Be tested with the applications in environments that have packet loss and low bandwidth.

• Have intelligent error handling systems, which keep the user informed.

• Treat the network as an unreliable resource.

You need to keep in mind several other situations that apply to a mobile user:

• The disappearance of the network completely

• Changes in the network properties

• What happens when a mobile user moves to a new valid network that does not have the resources the application needs

• Dramatic changes in bandwidth

Several improvements in Longhorn will make it simpler to address some of these issues. Network Location API (NLA) will provide a single place where an application can get all the network parameters for a machine. The API will also inform the application whether the parameters have been changed and will even give the application some network context information.

For each interface, the API will provide IP address and configuration information, domain name , adapter GUIDs, and context information. NLA will assign the connection to one of the categories described in the following table.

Type	Definition
Ad hoc	The interface is on an ad hoc network not connected to any other network.
Managed	The interface is connected to a managed secure network such as an enterprise, with a Windows domain controller.
Unmanaged	The interface is not connected to a Windows domain.
Unknown	The service is unable to determine the connection s characteristics.

Each of these categories, with the exception of ad hoc, can also indicate the Internet flag, as described in the following table.

Flag	Definition
Internet	The interface has Internet connectivity, defined as being able to resolve a common DNS A record from the Internet.

Although these categories are not foolproof, they give the application a good idea of where the host is on the network.

Although NLA helps with traversing the network, it does not solve the problem of the absence of a network resource on a valid network. In this case, the application can wait for the send failure, but this provides little real information about why the failure happened . A more elegant and effective solution is an application layer ping .

A standard Internet Control Message Protocol (ICMP) echo of the resource s name provides the application with little information. The ICMP response can fail for many reasons other than the absence of the resource. Broken name resolution and blocking of ICMP responses (common for security reasons) could easily provide false negatives . An application ping or probe can provide much more information than just the presence of the resource on the new network. It tells the application not only that the server is responding but also whether the application on the server is responsive .

You can also use an application ping to calculate the throughput of a connection, which is extremely useful when the user is moving from a high-bandwidth wired connection to a low-bandwidth wide area network (WAN) connection.

Here is a formula that can assist with calculating the true capacity of the connection:

( OID_GEN_LINK_SPEED *RTT(secs)) = capacity (bps)

After the application has knowledge of the throughput of the connection, it can make intelligent decisions about what type of transactions are appropriate for the size of the pipe. For example, an application can use this information to determine whether the download of a large piece of data would be unreasonable given the network conditions. Applications can tailor their behavior to the conditions.

In the near- term , wireless WAN will be severely bandwidth restricted. The quoted maximum speeds are possible only under optimal conditions. The user would need to be stationary, and with most technologies, only one user per cell could get the full amount of bandwidth allowed by the topology. Unfortunately, these technologies also introduce highly varied amounts of delay. A user could easily see roundtrip time changes from 500 ms to 3000 ms from packet to packet. This discrepancy can make a single ping or probe provide erroneous information to the application about current conditions. This problem can be countered by calculating averages gathered over the history of the connection.