To see why this is the case think about what I talked about in the previous article in regard to hardware abstraction. Suppose that an application needs to be able to communicate across the network. The application developer does not build network drivers into the application, they merely write the application in a way that allows it to make certain calls to the Windows operating system. The manufacturer of the machine’s network adapter provides a driver that also links to Windows, and Windows performs the necessary match ups that allow the application to communicate with the network adapter.
Figure A: The Local Area Connection properties sheet offers a glimpse at the way that the various network layers are implemented in Windows
Of course that is just the quick and dirty version. Things are actually quite a bit more complex than that. After all, the network adapter is just a device that is designed to send and receive packets of data. The card itself knows nothing of Windows, the application, or even of the protocols that are being used.
The example that I provided a moment ago implies that there are three layers at work; the application, the operating system, and the physical hardware. While these layers do exist (but not necessarily by those names), they can be subdivided into several more layers.
Before I explain what these layers are and what they do, I want to point out that the concepts that I am about to teach you are not abstract. In fact, if you open the Local Area Connection properties sheet, shown in Figure A, you can see that a network connection is made up of several different components, such as the network client, the network adapter driver, and the protocol. Each of these components corresponds to one or more individual layers.
 |
| Add caption |
Figure A: The Local Area Connection properties sheet offers a glimpse at the way that the various network layers are implemented in Windows
