Overview
Key Networking Terms and Concepts
✓ Named pipe— a connection-oriented networking protocol, based on Server Message Blocks and NetBIOS.
✓ Socket— the end point of an interprocess communication across a network transport. In Windows, you establish and interact with socket connections using the Winsock API.
✓ RPC— Remote Procedure Call, a networking API that presents a call-level interface (CLI) in place of the traditional I/O model of network programming.
✓ Connection-oriented Winsock application— an application that makes use of a stream or reliable connection to communicate using the Winsock API.
✓ Connectionless Winsock application— an application that makes use of a datagram or unreliable connection to communicate using the Winsock API.
✓ Name resolution— the process of translating a machine name into a network address.
✓ Network stack— the collection of interrelated software used to allow applications to communicate with one another over a network.
Key Networking APIs
| Function | Description |
|---|---|
| CreateNamedPipe | Creates a named pipe |
| ConnectNamedPipe | Waits on a client to connect to a named pipe |
| WSAStartup | Initializes the Winsock API library |
| WSASocket | Creates a new socket (Microsoft-specific) |
| socket | Creates a new socket (BSD Sockets–compatible) |
| listen | Instructs a socket to begin listening for client connections |
| accept | Waits on a Winsock client to connect |
| connect | Connects to a Winsock server |
| send | Sends data over a Winsock socket |
| recv | Receives data from a Winsock socket |
| ReadFile | Reads data from a resource represented by a file handle, including sockets and named pipes |
| WriteFile | Writes data to a resource represented by a file handle, including sockets and named pipes |
Traditionally, networking software is structured around an I/O paradigm—a client typically interacts with networking resources using standard operating system API calls. In Windows, a network operation is automatically initiated when an application requests access to a remote resource. The system detects that the request is for a remote resource and forwards it to a redirector. The redirector acts as a type of remote file system. It passes the operation to the remote machine where the resource is located, which then routes the request to the appropriate operating system component to fulfill it. Once the request is fulfilled, the remote system returns the results across the network to the redirector, which then returns them to the client. All the while, the client does not even need to be aware that the network operation took place because the request was intercepted, redirected, and fulfilled transparently.
Successful networking requires that a machine be able to figure out how to get to a machine containing a remote resource and what communications protocols that machine can use. The process of translating a machine name into a network address is known as name resolution. The process of negotiating a compatible set of communications protocols is known as negotiation.
Once name resolution and protocol negotiation have been successfully completed, a network request must be altered for transmission across the network by dividing it into packets that the physical medium can transport. When the request reaches the destination, it must be reassembled from its packets, checked for completeness, decoded, and passed on to the appropriate OS component for fulfillment. Once the OS component fulfills the request, the process must be reversed in order to send the results back to the client.
The OSI Reference Model
Networking software can be classified into four basic categories: services, APIs, protocols, and network adapter device drivers. Each type is layered on top of the next to form what's commonly referred to as the network stack. The components in Windows that implement the network stack correspond loosely to the Open Systems Interconnection (OSI) reference model, first introduced in 1974 by the International Organization for Standardization (ISO). You can download the OSI reference model from the ISO Web site at http://www.iso.org. Table 6.2 details the seven layers of the model.
Keep in mind that this is more of a conceptual model than something that vendors implement exactly. It's often used to discuss networking in the abstract, with implementation details left to vendors. The important thing is to glean its key tenets and understand how Windows implements them.
| Layer Number | Layer | Description |
|---|---|---|
| 7 | Application | Responsible for transferring information between two machines in a network conversation. It handles such things as machine identification, security validation, and starting the data exchange. |
| 6 | Presentation | Responsible for the formatting of data, including the type of line-break character(s) used, data compression, data encoding, etc. |
| 5 | Session | Responsible for managing the connection itself, including coordination of who is sending and who is receiving at any given time. |
| 4 | Transport | Responsible for dividing messages into packets on the client and assigning them sequence numbers and for reassembling packets on the server that have been received from the client. It's also responsible for abstracting the hardware layer in such a way as to protect the Session layer from changes to it. |
| 3 | Network | Responsible for packet headers and routing, internetworking, and congestion control. It is the topmost layer that is aware of the network topology—the physical configuration of the network (the machines on the network, bandwidth limitations, etc.). |
| 2 | Data-link | Responsible for transmitting low-level data frames, checking to make sure they were received, and retransmitting frames lost due to unreliable lines. |
| 1 | Physical | Responsible for sending data to the physical network transmission medium (the network cable, wireless device, etc.). |
Each layer in the model exists to provide services to the higher layers and to provide an abstract interface to the services provided by lower layers. It's helpful to think of each layer built on top of the Physical layer as another level of indirection removed from the actual process of transmitting bits over the network cabling. As we travel up the stack, we get further and further away from the physical transmission of data until we get to the Application layer, which is completely unaware of how data is physically moved between machines.
Consider how the layers on one machine communicate with those on another in a network conversation. Conceptually, each layer on the first machine talks to the same layer on the other machine, and both layers use the same protocol. For example, a Windows Socket application on one machine will behave as though it is communicating directly with a Windows Socket application on the other machine. Physically, however, data must travel down each machine's network stack to the physical medium, then across the medium to the other machine and back up the other machine's network stack. So, although the Transport layers on each machine involved in a network conversation may logically appear to be talking to one another, in actuality, they are communicating with their own Network, Data-link, and Physical layers, and it is the Physical layers of the two machines that actually communicate directly with one another over the network cabling.
By convention, the seven layers of the model are further divided into two broader tiers. The bottom four layers are commonly referred to as the transport, and the top three are referred to as clients of the transport or users of the transport. The OSI Transport layer is where we start to get into the physical logistics of getting from one machine to another, so dividing the seven layers along these lines is useful from a conceptual standpoint.
Windows Networking Components
As with other operating systems, Windows doesn't implement the OSI reference model precisely. It has some layers that the OSI model doesn't have, and a few of its layers span more than one OSI layer. Table 6.3 lays out the OSI-to-Windows network component mapping.
Windows supports multiple network APIs in order to be compatible with industry standards and to provide support for legacy applications. For example, Windows' Sockets implementation closely resembles that of Berkeley Software Distribution (BSD) Sockets, the standard for Internet communication on UNIX since the 1980s, in order to make porting UNIX applications to Windows simpler.
| Layer Number | Windows Networking Component | OSI Layer | Comments |
|---|---|---|---|
| 7 | Network application | Application | |
| 6 | Network API DLL | Presentation Session | Allows applications to communicate across a network in a manner that's independent of transport protocol. |
| 5 | |||
| 5 | Network API driver | Session | Kernel mode drivers responsible for the kernel mode portion of a network API's implementation. |
| Transport Driver Interface | Specifies a common API for kernel mode device drivers. | ||
| 4 | Protocol driver (TCP/IP, IPX, etc.) | Transport Network | |
| 3 | |||
| NDIS protocol drivers | Kernel mode drivers that process I/O requests from TDI clients. | ||
| 2 | NDIS library and miniport | Data-link | The NDIS library encapsulates the kernel mode environment for adapter drivers. NDIS miniport drivers are kernel mode drivers that interface a TDI transport with a specific network adapter. |
| Hardware abstraction layer | |||
| 1 | Ethernet, IrDa, etc. | Physical |
As with any technology decision, which network API you should use in a particular application comes down to how well the API meets your application's needs. What a network API can offer an application can vary a great deal in terms of the network protocols it can use, what types of communication it supports (reliable versus unreliable, bidirectional versus unidirectional, and so on), and its portability to other versions of Windows or other operating systems that you might want it to either run on or be easily portable to. There's no single networking API that is better than every other networking API in every situation.
Windows' key networking APIs include the following:
Common Internet File System
Named Pipes
Windows Sockets
Remote Procedure Call
NetBIOS
Of these, we'll discuss RPC, Named Pipes, and Windows Sockets because SQL Server offers network libraries for each of them (the multiprotocol Net-Library uses Windows' RPC facility). Common Internet File System is the mechanism by which files are shared on a Windows network. NetBIOS is mostly a legacy API that predates the emergence of TCP/IP and Sockets as the prevalent internetworking technology for computers.