心情不好，灌水！

rt

灌灌灌！！！！

郁闷，再灌！

孙猴子又跟你过不去了？

Protocol Drivers
Choose the type of protocol driver you will be writing:

With a Connectionless Lower Edge
If you will be writing a protocol driver whose lower edge provides an interface to connectionless miniports, read:
Part 3, Chapter 2

With TDI upper edge
If you will be writing a protocol that has a TDI upper edge, read:
Part 3, Chapters, 2, 3, 4, 5

With Winsock support
If you will be writing a protocol that provides Winsock support, read:
Part 3, Chapters, 2, 3, 4, 5, 6

Connection-Oriented Client or Call Manager
If you will be writing a connection-oriented client, which provides an interface to connection-oriented miniports, or if you will be writing a connection-oriented call manager, read:
Part 3, Chapter 2
Part 4, Chapter 1

Filter-hook Drivers
Read Part 6, Chapter 1

Chapter 2 Network Architecture for Kernel-Mode Drivers
This chapter describes the Microsoft? Windows 2000? network architecture for kernel-mode drivers. This chapter contains the following sections:

Windows 2000 Network Architecture and the OSI Model in Section 2.1
NDIS Network Drivers in Section 2.2
TDI Drivers in Section 2.3
Network Driver Environments in Section 2.4

2.1 Windows 2000 Network Architecture and the OSI Model
The Microsoft? Windows? 2000 network architecture is based on the 7-layer networking model developed by the International Standards Organization (ISO). Introduced in 1978, the ISO Open Systems Interconnection (OSI) reference model describes networking as a series of protocol layers with a specific set of functions allocated to each layer. Each layer offers specific services to higher layers while shielding these layers from the details of how the services are implemented. A well-defined interface between each pair of adjacent layers defines the services offered by the lower layer to the higher one and how those services are accessed.

Figure 2.1 ›The OSI Reference Model

Network drivers under Windows 2000 implement the bottom four layers of this network architecture:

Physical Layer
This is the lowest layer of the OSI model. This layer is involves the reception and transmission of the unstructured raw bit stream over a physical medium. It describes the electrical/optical, mechanical, and functional interfaces to the physical medium. The physical layer carries the signals for all the higher layers. Under Windows 2000, the physical layer is implemented by the network interface card (NIC), its transceiver, and the medium to which the NIC is attached. For network components that use serial ports, the physical layer can also include low-level network software that defines how the serial stream of bits is divided into packets of data.

Data Link Layer
This OSI layer is further divided by Institute of Electrical and Electronics Engineers (IEEE) into two sublayers: LLC and MAC. The LLC sublayer provides error-free transfer of data frames from one node to another. The LLC sublayer establishes and terminates logical links, controls frame flow, sequences frames, acknowledges frames, and retransmits unacknowledged frames. The LLC sublayer uses frame acknowledgement and retransmission to provide virtually error-free transmission over the link to the layers above. The MAC sublayer manages access to the network media, checks frame errors, and manages address recognition of received frames. In the Windows 2000 network architecture, the Logical Link Control sublayer is implemented in the transport driver, while the Media Access Control sublayer is implemented in the network interface card (NIC). The NIC is controlled by a software device driver called the NIC driver. Windows 2000 ships with NIC drivers for a number of popular NICs.

Network Layer
This layer controls the operation of the subnet. It determines the physical path the data should take, based on the following:
network conditions
priority of service
other factors, including routing, traffic control, frame fragmentation and reassembly, logical-to-physical address mapping, and usage accounting

Transport Layer
This layer ensures that messages are delivered error-free, in sequence, and with no loss or duplication. It relieves the higher-layer protocols from any concern with the transfer of data between them and their peers. A minimal Transport Layer is required in protocol stacks that include a reliable Network or Logical Link Control sublayer that provides virtual circuit capability. For example, because the Windows 2000 NetBEUI transport driver includes an OSI-compliant LLC sublayer, its Transport Layer functions are minimal. If the protocol stack does not include an LLC sublayer, and if the Network Layer is unreliable and/or supports datagrams (as with TCP/IP\'s IP layer or NWLink\'s IPX layer), the Transport Layer should include frame sequencing and acknowledgment, as well as retransmission of unacknowledged frames.
In the Windows 2000 network architecture, the Logical Link Control, Network, and Transport layers are implemented by software drivers known as transport drivers, which are sometimes referred to as protocols, protocol drivers, or protocol modules. Windows 2000 ships with TCP/IP, IPX/SPX, NetBEUI, and AppleTalk transport drivers.

Built on Wednesday, June 28, 2000

2.2.1 NDIS Miniport Drivers
A NDIS miniport driver (also called a miniport NIC driver) has two basic functions:

Managing a network interface card (NIC), including sending and receiving data through the NIC
Interfacing with higher-level drivers, such as intermediate drivers and transport protocol drivers
A miniport NIC driver communicates with its NIC and with higher-level drivers through the NDIS library. The NDIS library exports a full set of functions (NdisXXX functions) that encapsulate all the operating system functions that a miniport needs to call. The miniport, in turn, must export a set of entry points (MiniportXxx functions) that NDIS calls for its own purposes or on behalf of higher-level drivers to access the miniport.

Send and receive operations illustrate the interaction of miniport NIC drivers with NDIS and with higher-level drivers:

When a transport driver has a packet to transmit, it calls an NdisXxx function exported by the NDIS library. NDIS then passes the packet to the miniport by calling the appropriate MiniportXxx function exported by the miniport. The miniport driver then forwards the packet to the NIC for transmission by calling the appropriate NdisXxx functions

When a NIC receives a packet addressed to the NIC, it can post a hardware interrupt that is handled by NDIS or the NIC\'s miniport. NDIS notifies the NIC\'s miniport by calling the appropriate MiniportXxx function. The miniport sets up the transfer of data from the NIC and then indicates the presence of the received packet to bound higher-level drivers by calling the appropriate NdisXxx function.

NDIS supports miniport drivers for both connectionless environments and connection-oriented environments.

Connectionless miniports control NICs for connectionless network media, such as Ethernet, FDDI, and Token Ring. Connectionless miniports are further divided into the following subtypes:

Serialized drivers that rely on NDIS to serialize calls to their MiniportXxx functions and to manage their send queues.
Deserialized drivers that serialize the operation of their own MiniportXxx functions and that queue internally all incoming send packets. This results in significantly better full-duplex performance, provided that the driver\'s critical sections (code which only a single thread at a time can execute) are kept small.

Connection-oriented miniports control NICs for connection-oriented network media, such as ATM and ISDN. Connection-oriented miniports are always deserialized ― they always serialize the operation of their own MiniportXxx functions and queue internally all incoming send packets.

An NDIS miniport driver can have a non-NDIS lower edge (see Figure 2.3).