Inside NT Networking

Microsoft learned a lesson when the lack of native networking support in DOS and Windows 3.0 limited those OSs' acceptance in business environments and left the networking market open for Novell and UNIX vendors. Microsoft strove to ensure that the first release of Windows NT contained an array of networking options out of the box. NT's debut in 1993, with version 3.1, fulfilled NT's promise as an OS that is ready for peer-to-peer and client/server networking configurations. NT 3.1 included a variety of popular network programming APIs, networking protocols, and a network card driver model that facilitated third-party support for Microsoft networking hardware.

This month, I'll peel away the layers of NT's network architecture to show you how this architecture implements network programming APIs. I'll describe how the APIs interface with protocol drivers and implement NIC drivers. Along the way, I'll introduce you to some new networking features that Windows 2000 (Win2K—formerly NT 5.0) will include.

Network APIs
In 1978, the International Standards Organization (ISO) introduced the Open Systems Interconnection (OSI) model to standardize defining network communications in layers. The OSI model consists of seven network layers, which Figure 1, page 52, illustrates. Higher layers represent higher levels of abstraction. The idea behind network layering is that lower layers transform requests coming from above to a lower level of abstraction, and higher layers transform requests coming from below to a higher level of abstraction. The highest level of abstraction occurs at the application layer, in which network programming APIs such as remote procedure call (RPC) and sockets fall. The lowest level of abstraction occurs at the physical layer, in which bits and bytes on wires or cables transmit between computers. The division of networking into layers promotes a model of standardized interfaces between layers, and flexible and replaceable layer implementation.

In general, OS designers don't divide the network I/O path into seven well-defined layers, as the OSI model promotes. For simplicity and performance, OS designers can designate one layer in an OS's network architecture to correspond to several OSI layers. Figure 1 shows how NT's network architecture maps to OSI layers. The highest of the three NT layers is the network API layer. A network API gives applications an interface to networking I/O. Application designers can define their own networking APIs, but relying on standard APIs is simpler. NT incorporates the following networking APIs: named pipes, mailslots, NetBIOS, Winsock, RPC, Network Dynamic Data Exchange (NetDDE), Server Message Block (SMB), Distributed Component Object Model (DCOM), and Message Queues.

Named pipes and mailslots are programming APIs that Microsoft originally developed for OS/2 LAN Manager, then ported to NT. Named pipes let programs on different computers establish a reliable 2-way communications link. A named pipe server calls the CreateNamedPipe function to define a pipe on the local computer, and a named pipe client opens a connection to the server's pipe by specifying the pipe's name to the CreateFile Win32 function. With the established connection, the client and server can use WriteFile and ReadFile, standard NT file I/O routines, to exchange data through the pipe connection. Named pipes are popular NT programming APIs, but applications that use pipes do not generally port to Windows 98 and Win95, because these OSs do not implement named pipe server APIs.

Mailslots give programs an unreliable, connectionless broadcast facility. Similarly to a named pipe server, a mailslot server defines a mail slot using the CreateMailSlot API. Mailslot clients can open the server's mail slot and send the server messages through the slot. The mailslot service is unreliable, because the server might not receive messages clients send. Mailslots also support message broadcast. In message broadcast, when two or more mailslot servers in a domain create a mail slot with the same name, those servers will receive the messages clients send to that mail slot name. What kind of application can make use of an unreliable broadcast mechanism? One example is a time-synchronization service, which might broadcast a source time across the domain every few seconds. Receiving the source-time message is not crucial for every computer on the network.

Until the 1990s, the NetBIOS programming API has been the most widely used programming API on personal computers. NetBIOS allows for both reliable-connection-oriented and unreliable, connectionless communication. NT supports NetBIOS for its legacy applications. Microsoft discourages application developers from using NetBIOS, because other APIs, such as named pipes and RPC, are much more flexible and portable.

Winsock is Microsoft's implementation of BSD Sockets, a programming API that became the standard by which UNIX systems communicated over the Internet during the 1980s and 1990s. Support for sockets on NT makes the task of porting UNIX networking applications to NT relatively straightforward. Winsock includes most of the functionality of BSD Sockets but also includes Microsoft-specific enhancements, which continue to evolve. Winsock has a mode it calls streams for reliable-connection-oriented communication, and a mode it calls datagrams for unreliable, connectionless communication.

RPC is a network programming standard that Sun Microsystems originally developed. The Open Software Foundation (now The Open Group) made RPC part of the distributed computing environment (DCE) distributed computing standard. An interesting aspect of NT's implementation of RPC is that RPC in NT uses other network programming APIs. Thus, RPC in NT is really a programming API layer that rides on top of named pipes, Winsock, NetBIOS, or Message Queues.

Programmers developing an RPC client/server application define functions that the server implements. The developer writes the client program as if the program can invoke the server functions directly. What happens under the hood, however, is that a client-side library takes the parameters the program passes to the server function and shapes the parameters into a message. This message transmits to the server, which has a library that unpacks the parameters from the message and passes them to the server function. When the server function finishes, any return parameters go through the same process as the server sends them back to the client. The fact that the parameter packing and unpacking (called marshalling and unmarshalling) and the message transmission are hidden from the application developer makes RPC an attractive API. The Microsoft Interface Definition Language (MIDL) Compiler automatically builds client and server libraries for a developer, based on the function definitions the developer provides.

The Dynamic Data Exchange (DDE) API lets Windows applications communicate with one another via special types of Windows messages. Windows has used DDE since Windows 2.x. Network DDE (NetDDE) lets Windows applications that communicate via DDE reside on different computers. DDE is not a general communications API because graphical Windows are the basis for DDE connections, but DDE is a convenient API whenever it is an option.

SMB communication is the basis for NT's file-sharing client and server, which are known as the Workstation and Server services, respectively. Recently, Microsoft enhanced the SMB API as the Common Internet File System (CIFS) API, in an effort to promote SMB as a network file-sharing standard that can compete directly with Sun Microsystems' Web Network File System (NFS). Use of the SMB API is usually transparent to applications, which access network files by specifying filenames relative to local drive letters that map to a server's share point on a remote file system. Thus, standard file-opening, -reading, and -writing APIs give the application access to the remote files. The Uniform Naming Convention (UNC) method lets applications directly identify the names of files relative to a remote computer's share points.

NT's next built-in network API, DCOM, is the API Microsoft has focused the most attention on in recent years. Microsoft's COM API lets applications consist of different components that are replaceable self-contained modules. A COM object exports an object-oriented interface to methods for manipulating the data within the object. Because COM objects present well-defined interfaces, developers can implement new objects to extend existing interfaces and dynamically update applications with the new support. DCOM lets an application's components reside on different computers, which means applications need not be concerned that one COM object might be on the local computer and another might be across the LAN. DCOM thus provides location transparency, which simplifies developing distributed applications. Similarly to RPC, DCOM is not a self-contained API but relies on RPC to carry out its work. COM+, the COM version that Win2K includes, makes it easier for developers to write COM-based applications by adding language-specific compiler and runtime support for COM objects.

Microsoft introduced its newest network API, Message Queues, in the NT 4.0 Option Pack. The Message Queues API is similar to RPC in that its basis is client/server message exchange. However, whereas RPC is a synchronous interface (i.e., a client must wait until a server finishes processing the client's request before performing other work), Message Queues are asynchronous. For example, a client can send many requests to a server, and the requests fall into a queue. The server processes the client's requests in order, as quickly as possible, and the client can perform other work in the meantime. Message Queues can also perform reliable transactions when used with Microsoft Transaction Server (MTS).

   Previous  [1]  2  3  Next