 Important: |
|---|
| This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. |
Microsoft Corporation
April 2002
Summary:This paper outlines the networking capabilities of the Windows CE 2.1 operating system. (8 printed pages)
Contents
Introduction
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:
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:
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:
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:
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. 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:
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 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.
Internet Communication
Remote Printers and Files
Winsock and Irsock
IrSock Protocol
Enhanced Socket Options
TCP/IP and IrDA Protocols
Hardware Support
Networking with Modems
For More Information
Introduction
Internet Communication
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.
Remote Printers and Files
Winsock and Irsock
IrSock Protocol
Name Service
Method of Addressing
Enhanced Socket Options
Winsock Security Support
TCP/IP and IrDA Protocols
Hardware Support
Networking with Modems
For More Information