Microsoft Windows CE 2.1-based Networking
Summary: This paper outlines the networking capabilities of the Windows CE 2.1 operating system. (8 printed pages)
Remote Printers and Files
Winsock and Irsock
Enhanced Socket Options
TCP/IP and IrDA Protocols
Networking with Modems
For More Information
Network communications is an important feature of many Windows CE-based devices. It allows your applications to do such tasks as browse the Internet, send and receive e-mail, and access remote printers and files.
Network communications technology is designed to be used when a transmission may be sent or received by one of many devices. With serial communications, you can stream the data to the other device. With networks, the network stack must divide the data into one or more packets and add an address to each packet to ensure that it gets to its destination. Network stacks also include reliability protocols such as the Transmission Control Protocol (TCP) that ensure that lost or damaged packets are retransmitted.
Network communication protocols are required with hardware such as local area networks (LANs). However, even with a one-to-one connection, where serial communications is permitted, serial link networking is often used instead. For instance, a modem is often used to connect a Windows CE-based device to a network service provider. While the phone connection itself is one-to-one, network protocols are needed so that the service provider can forward the message. Even with two devices connected by a cable, network reliability protocols are useful for preventing data loss.
Windows CE provides a broad range of network communications options and related application programming interfaces (APIs). They include virtually everything normally found on desktop platforms including:
- Internet communication, including support for the HTTP and FTP protocols, and ICMP requests.
- Network printer and file access.
- Windows sockets, including the IrSock extension for infrared communication with the IrDA protocols.
- The TCP/IP protocols, including IP multicast support. TCP/IP is configurable for wireless networking.
- The IRDA protocols for infrared communication.
- NDIS 4.0 for local area networking and fast infrared communication with the IrDA protocols.
- PPP and SLIP protocols for serial-link networking.
- Remote access service (RAS) client support.
Windows CE also provides support for managing modem connections through the telephony API (TAPI). TAPI handles such tasks as dialing a phone number, establishing a connection, and terminating a call.
The following graphic is a schematic diagram of the Windows CE networking model.
Figure 1. Windows CE networking model
Much of the communication that takes place over the Internet involves the use of high-level protocols such as FTP and HTTP. The WinInet API simplifies the task of creating Internet client applications that use these protocols. It provides support for the FTP and HTTP 1.0 protocols and handles the details of making and managing socket connections. Gopher, cookies, proxy bypass lists, and persistent URL caching are not supported.
WinInet uses Internet handles to identify sites. Once you have acquired a handle to a site and prepared it for requests, you can then use WinInet to:
- Send HTTP requests
- Send FTP request
- Download information
Note Not every platform supports every module or component. The configuration of the Windows CE operating system for the Handheld PC (H/PC) does not include the WinInet component.
In order to enhance the security of communication, WinInet allows you to use the Secure Sockets Layer (SSL) 2.0 and 3.0, or the Private Communications Technology (PCT) 1.0 security protocols. You simply set the appropriate flags when you make a connection and prepare the remote site for a request. The network stack automatically handles encryption and decryption of your communication.
Although WinInet is the simplest way to use security protocols, your application has relatively little flexibility in how they are used. If you need greater control over how secure communications is handled, use Winsock directly.
Many Windows CE-based devices will be used with network file systems and printers. Windows CE provides access to these remote resources with a Common Internet File System (CIFS) redirector. The CIFS protocol is also referred to as the Server Message Block (SMB) protocol. The WNet API allows you to use the redirector to:
- Add or cancel network connections.
- Retrieve information about the network.
- Upload or download files.
- Enumerate the printers on the network.
- Submit print jobs to a networked printer.
File systems and printers are identified by a Universal Name Convention (UNC) name, such as \\serverXX\shareXX. UNC names may have up to 260 characters. Drive letters are not supported.
The CIFS redirector receives file system requests, and determines if the file system is local or remote. If the file system is remote, the redirector packages the request, sends it to the remote host, and returns the result. The redirector allows connections to computers running Windows 95, Windows NT®, or any other server that is compliant with the NTLM 0.12 dialect of the CIFS specification.
In addition to remote file systems, Windows CE allows access to networked printers, identified by UNC names. When CIFS receives the remote print request from the printer driver, CIFS copies the print output to the remote spooler. When the job is complete or is terminated unsuccessfully, the redirector will notify the application. Retries are not supported.
Windows CE network printing support is basic. The print subsystem does not attempt to determine what kind of printer is being accessed, or what type of output is expected. It is up to your application to ensure that the output is appropriate to the chosen printer.
All network communications passes through the Windows Sockets or Winsock interface. The WNet and WinInet APIs use Winsock internally, and relieve applications of the necessity of explicitly making and managing socket connections. If you need greater flexibility, Winsock can also be used directly.
Sockets are a general-purpose connection-oriented networking interface, supported by most operating systems. Winsock is designed to be compatible with the Berkeley Sockets Distribution (BSD) specification while performing well on Windows-based operating systems. In addition to conventional TCP/IP communication, Winsock provides access to the IrDA transport protocols through the IrSock extension.
Windows CE supports all the standard Winsock 1.1 calls. It also has an implementation of WSAIoctl to support security service providers. Windows CE does not inherently support asynchronous socket communication. However, the Microsoft Foundation Classes (MFC) CCeSocket class provides asynchronous notification for the following three types of socket events:
- Notification that the socket is ready for reading (FD_READ)
- Notification of incoming connections (FD_ACCEPT)
- Notification of completed connections (FD_CONNECT)
The IrDA protocol is designed to provide a more robust form of IR communication than simply streaming data from source to receiver. It includes such services as addressing, collision detection, and retransmission of lost or damaged frames.
Conventional Winsock applications use the TCP/IP transport and address layers of the network stack. The IrSock extension allows the Winsock API to be used with the IrDA protocol. To specify IrSock, use SOCKADDR_IRDA when you create the socket instead of SOCKADDR_IN. The procedure for using IrSock in an application is very similar to conventional Winsock, but IrSock uses some of the functions a little differently. The main differences between IrSock and conventional Winsock are:
Conventional Winsock name service is best suited to fixed networks. IrDA, on the other hand, is intended to allow browsing for whatever resources are within range. Devices may come and go frequently as they move in and out of range. To handle this environment, IrSock incorporates name service into the data stream instead of using Winsock name-service functions.
Method of Addressing
Addressing is based on Logical Service Access Point Selectors (LSAP-SELs), which are numbered from 1-127. Because there are so few, most applications should not bind a socket directly to an LSAP-SEL. Instead, you should use the Information Access Service (IAS). Binding directly to an LSAP-SEL should be restricted to legacy IrDA devices that do not support IAS.
To use the IAS, a server application binds a socket to an IAS service name, rather than an LSAP-SEL. The IAS then dynamically binds the socket to an appropriate LSAP-SEL. The client application uses the service name to make its connection. Neither application needs to know what LSAP-SEL is actually being used.
Windows CE includes two socket options to support the unique features of IrDA:
- IRLMP_IAS_SET lets an application set a single attribute of a single class in the local IAS.
- IRLMP_EXCLUSIVE_MODE allows an application to switch between the reliable TinyTP mode and the less reliable IrLMP mode.
Winsock Security Support
Winsock supports the SSL 2.0 and 3.0 and PCT1.0 security protocols. While these protocols are available through WinInet, accessing them through Winsock gives you much more flexibility in how they are used.
The security protocols can be invoked when a socket connection is established, or deferred until needed. Once the protocols are invoked, encryption and decryption of the data is handled automatically by Winsock. The key to using the Winsock security protocols is authentication.
Authentication is a process of determining whether or not the site sending the data is who they say they are. Such sites are referred to as trustworthy. A remote site establishes its trustworthiness by obtaining a certificate from a Certifying Authority (CA). Windows CE supports X.509 style certificates. The first CA may in turn have obtained a certificate from a higher CA, and so on, creating a chain of trust. The decision on whether to trust the site or not is based on the root CA of the chain of trust.
Windows CE maintains a database of trusted CAs. When a secure connection is attempted by an application, Windows CE extracts the root certificate and checks the CA against the database. It then passes the results of that comparison and the root certificate itself back to the application.
Your application is responsible for deciding whether or not to trust a particular certificate or CA. You can accept or reject certificates based on any criteria you wish to use. If you reject the certificate, the socket connection is not completed. At a minimum, a certificate should meet two basic criteria. It should be current, and the identity contained within the certificate should match that of the root CA.
The transport and address layers of a network stack are responsible for many of the details of transforming a data stream into a form that can be used on a network. They also take received messages and convert them back into their original form. While applications do not have direct access to the Windows CE transport and address layers, some understanding of how they work is essential to using network communications properly.
The TCP/IP protocols were developed for the Internet and are commonly used for network communications. The Windows CE TCP layer supports both the reliable TCP and unreliable UDP protocols. You specify which protocol to use when you make a socket connection. TCP is the most commonly used protocol, as it guarantees that all packets eventually arrive. If speed is more important than an occasional lost packet, UDP may be a better choice.
With conventional TCP/IP or Unicasting, an server sends a separate packet to each client. With some types of applications, such as streaming video, this approach can burden networks with large numbers of identical packets. To preserve network bandwidth, Windows CE supports IP multicasting. This technology allows a server reduce the number of packets it needs to send by allowing it to address a single packet to many receivers.
One of the ways that TCP ensures that packets arrive at their destination is that the receiver must acknowledge each packet. If no acknowledgement is received within a specified timeout period, the packet is retransmitted. The timeout period needs to match the behavior of the network. If it is too long, the network stack may waste time waiting to retransmit. If it is too short, unnecessary retransmissions may occur.
A normally configured network stack has a timeout appropriate to a wired network. However, wireless networks usually have significantly longer transmission delays than wired networks. Using a timeout appropriate for a wired network will may cause many unnecessary retransmissions. To support wireless networking, the Windows CE network stack can be optimized by modifying registry values. There are three parameters that may need adjustment:
- The acknowledgement timeout. Wireless networks generally need a longer acknowledgement timeout than wired networks.
- The receive window size. In general, large receive windows work better with wireless networks. For greatest efficiency, the receive window should be an even multiple of the TCP Maximum Segment Size (MSS).
- The initial roundtrip time. Wireless networks generally need a longer initial roundtrip time than wired networks.
The Infrared Data Association (IRDA) protocol is a widely used standard for IR communication. It is much more reliable than simply streaming data from source to receiver. Most fast IR transceivers will probably only support IRDA communication.
The Window CE IRDA stack is designed to support any compatible IR driver and transceiver, including fast IR and simple IR. No changes in your code are needed. The IRDA stack will do what is necessary to make use of the hardware and drivers available on any particular device.
Windows CE provides low-level support for several types of networking hardware. For serial-link networking over a cable or modem, Windows CE supports the widely used Serial Line Interface (SLIP) and Point-to-Point (PPP) protocols. For authentication, Windows CE supports the Password Authentication Protocol (PAP), the Challenge Authentication Protocol (CHAP), and Microsoft CHAP.
Windows CE includes an implementation of NDIS 4.0 to support local area networking. At present, only Ethernet and fast-IR miniport drivers are supported. NDIS 4.0 is packaged as a DLL rather than as a .sys file. This feature permits OEMs to conserve ROM. DLLs needed for an application are added to RAM.
Mobile devices commonly use a modem to connect to a network. Once a telephone connection is made, the network stack handles the actual data transmission. However, network stacks are not designed to handle the details of making or managing the telephone connection itself. To simplify the process of using a modem, Windows CE provides an implementation of the Microsoft Telephony API (TAPI).
TAPI is a collection of utilities that allow applications to use a wide variety of telephone and communications devices without needing detailed knowledge of the particular technology. It handles such tasks as dialing phone numbers, managing the modem connection, and terminating the call. With Windows CE, TAPI supports only outgoing calls. Unimodem is the only TAPI Service Provider included with Windows CE. It supports AT command-based modems. To allow applications to use a variety of hardware, installable service providers are supported.
- For more information on the IRDA protocol, go to www.irda.org.