Windows Server 2003 for Dummies

The sets of networking rules that we talk about in the previous section are usually called networking protocols but sometimes they're also called networking standards, standard networking protocols , and so on. You get the idea these rules are shared by some group that seeks to communicate amongst themselves and define a common method for computers to communicate with one another. Any particular protocol defines a language, a structure, and a set of rules to support such communications.

Lots of work goes into defining a set of networking protocols, and even more work goes into building software to implement it. This is a huge project, and the amount of work necessary to pull it off explains why users, software developers, and hardware manufacturers all find it convenient to stick to the protocols that best fit their needs.

In diplomacy , protocol establishes a rigid set of procedures and etiquette that representatives from sovereign governments follow to prevent all-out war. For example, protocol helps explain why diplomats refer to screaming matches as "frank and earnest discussions" and to knotty disagreements as "constructive dialogs." Political doubletalk aside, the word protocol captures the flavor of rules for network communications quite nicely .

Whales come in pods, protocols in suites

Although this book deals primarily with Windows Server 2003 and the Microsoft protocols, the protocols included in Windows 2003 represent only part of a large body of well-known and well-defined networking protocols. Microsoft does a good job of allowing multiple protocols to run at the same time in Windows 2003, including the Internet standard Transmission Control Protocol/Internet Protocol (TCP/IP) and Novell's Internet Package Exchange/Sequenced Package Exchange (IPX/SPX).

Upon examination of any networking implementation, you're likely to observe that protocols rarely, if ever, appear in the singular. Most networking protocols consist of a collection of specific message formats and rules for interaction, each with its own name and functions, rather than a single, monolithic collection of formats and rules. For that reason, protocols may also be called protocol suites , not because they like to lounge around on comfortable furniture, but because they travel in packs , like wild dogs.

One interesting fact about networking rules is that both vendors and standards groups call their protocols standards . Some vendors wax eloquently about differences between de facto and de jure standards. De facto means "It's not official, but a lot of people use it, so we can call it a standard if we want to." De jure means "It's a standard because the ABC (a standards-setting body) has declared it so and published this four- foot -high stack of books to prove it!"

Behind the often-heated discussions about what is and isn't a standard lurks a control issue. Purists including academics , researchers, and techno-weenies flatly assert that only a standards-setting group can be objective and fair. Therefore, only such a group can select the very best that technology has to offer by putting it in its standard making it the best possible standard.

The other heat source comes from the vendors' desperate race to keep up with the marketplace (and customer demands for better, faster, cheaper technology) by struggling to get products finished and out the door. "Of course, we must control our technology," they say. "How else can we keep up?"

The objectivity, fairness, and leading-edge characteristics of most protocol standards may not be open to dispute, but establishing standards involves assembling groups of individuals who must agree on their contents. This takes time. Meanwhile, technology races ahead. (Nothing goes stale faster than leading-edge technology.)

It doesn't matter whether networking protocols are standards or not, whether de facto or de jure. The markets are where the action is. Vendors must involve themselves in all sides of any debate because they must bet on all the technology horses in any race. Some astute vendors, including Microsoft, publish their standards and give customers and industry experts enough documentation to both create workable networks and keep up with the rapid pace of development as well.

Some standards bodies have been wise enough to realize that a standard is viable only when widely used. These groups have allowed hardware and software vendors to deal with the real-world issues involved in getting products to market. The winners in both camps are the most popular protocols. Microsoft's protocol selections for Windows Server 2003 (and other Windows versions) include the leading standard protocol, TCP/IP, and the widely used vendor protocol NWLink IPX/SPX/NetBIOS (IPX/SPX originated with Novell Netware).

Protocols permeate all aspects of networking

If one key concept explains why protocols are necessary, it's that protocols handle the movement of information between the hardware on the network interface and the applications that access the network. The reason why one computer can't talk to another computer without both sharing a common set of protocols is that both the sender and the receiver must be able to understand the other's operations, data formats, and delivery mechanisms. Without this common frame of reference, networking can't work.

Protocols fill the gap between a network's hardware and its software; they're used by programs that let your computer access the network. These protocols ferry data from applications all the way down to hardware, where a protocol says "send this message," to talk to the network. Going the other way, the protocol tells the hardware "give me the message," when the hardware indicates an incoming message has arrived.

Most protocols don't care what type of network they're talking through. In most cases, protocols are unaware of the network technology used, which might be Ethernet, token ring, or tutti-frutti. This indifference is possible because the part of the software that provides hardware access resides in a device driver for the network interface. The protocols themselves originate from other sources. (In Windows 2003, they reside in software components installed as part of the operating system, unless third-party components have been installed to displace built-in ones.) Therefore, when a protocol talks to the network interface, it's really communicating through a device driver to send data to (or to receive data from) the network. Specific device drivers tell a protocol exactly how to talk to the network interface (or interfaces) in your machine.

As we explain in Chapter 2, some applications include built-in networking capabilities that use a special software interface. Such network-aware applications are becoming increasingly common as networks become ubiquitous. Most Microsoft applications include some type of network intelligence, but the amount of such brainpower varies according to each application's focus and capabilities. Other applications may use standard application programming interfaces (APIs) and obtain network access anyway, totally unaware that a network is involved. This is where redirectors and other key system elements play a part. Whether applications are network-ready or use external networking facilities, as soon as they access the network, they use protocol software (and device drivers) to accept incoming or send outgoing messages.

The key to network access from applications or the operating system depends on access to a protocol suite. As we explain in Chapter 2, Windows 2003 includes all the components necessary to support network-aware and network-oblivious applications, which makes Windows Server 2003 itself quite network-aware indeed. Even though applications (and the operating system) may make requests for network service, the protocols do the dirty work, packaging messages to be sent across the network and then unpacking incoming messages into a readable form.

On other operating systems, such as Windows 95, 98, SE, Me, NT, 2000, and XP, UNIX, OS/2, and the Macintosh OS, built-in networking software also handles the network interface and those protocols and services that use it. DOS and older Windows 3.x versions, however, use client networking software that Microsoft supplies with Windows Server 2003 (or some other alternative from a third party).