3． NDIS Library and Driver：
1．NDIS library
The NDIS library implements in \Winnt\System32\Drivers\Ndis.sys。NDIS miniport and intermediate drivers don't accept and process IRPs. Rather, the NDIS library receives IRPs from TDI servers and translates the IRPs into calls into the NDIS driver.It uses IRPs to represent network requests.NDIS drivers can report whether or not their network medium is active。
2．NDIS Miniport drivers（NIC drivers,Adapter drivers）
directly manages a network interface card (NIC) and provides an interface to higher-level drivers
kernel-mode drivers that are responsible for interfacing TDI transports to particular network adapters. NDIS miniport drivers are written so that they are wrapped by the Windows 2000 NDIS library. The encapsulation provides cross-platform compatibility with Consumer Windows. NDIS miniport drivers don't process IRPs; rather, they register a call-table interface to the NDIS library that contains pointers to functions corresponding to ones that the NDIS library exports to TDI transports. NDIS miniport drivers communicate with network adapters by using NDIS library functions that resolve to hardware abstraction layer (HAL) functions。
NDIS library (Ndis.sys) provides encapsulation for adapter drivers, hiding from them specifics of the Windows 2000 kernel-mode environment. The NDIS library exports functions for use by TDI transports as well as support functions for adapter drivers
1．Calls NDIS library NdisXXX functions
2．Export MiniportXxx functions
3．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
4．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.
5．An NDIS miniport driver can have a non-NDIS lower edge,But uses the class interface for a bus such as the Universal Serial Bus (USB) or IEEE 1394 (fire wire) to control a device on the bus. The miniport communicates with the device by sending I/O request packets (IRPs) either to the bus or directly to remote devices that are attached to the bus.
NDIS supports miniport drivers for both connectionless environments and connection-oriented environments。
1．Connectionless miniports control NICs for connectionless network media, such as Ethernet, FDDI, and Token Ring。
Connectionless miniports are further divided into the following subtypes:
1．Serialized drivers that rely on NDIS to serialize calls to their MiniportXxx functions and to manage their send queues
2．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
2．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。
A connection-oriented miniport controls one or more network interface cards (NIC) and provides an interface between connection-oriented protocols (connection-oriented clients and call managers) and the NIC hardware。
connection-oriented NDIS drivers send packets through established network connections rather than placing them on the network medium
1．A call manager is an NDIS protocol driver that provides call setup and tear-down services for connection-oriented clients. A call manager uses the send and receive capabilities of a connection-oriented miniport to exchange signaling messages with network entities, such as network switches or remote peers. A call manager supports one or more signaling protocols, such as ATM UNI 3.1 as specified by the ATM Forum。Call managers are NDIS drivers that provide call setup and teardown services for connection-oriented clients (described shortly). A call manager uses a connection-oriented miniport to exchange signaling messages with other network entities such as network switches or other call managers. A call manager supports one or more signaling protocols, such as ATM User-Network Interface (UNI) 3.1
2．An integrated miniport call manager (MCM) is a connection-oriented miniport driver that also provides call manager services to connection-oriented clients. An MCM is essentially an NDIS miniport driver with a built-in call manager.。An MCM driver is a connection-oriented miniport that also provides call manager services to connection-oriented clients. Although an MCM provides the same connection-oriented services to clients as does a call manager paired with a connection-oriented miniport, its call manager/miniport interface is internal to the driver and therefore opaque to NDIS
3．A connection-oriented client uses the call-setup and tear-down services of a call manager or MCM. A connection-oriented client also uses the send and receive capabilities of a connection-oriented miniport or an MCM to send and receive data。A connection-oriented client can be similar to a connectionless protocol in that it can, at its upper edge, provide its own network and transport-layer services to a higher-layer application. However, unlike a connectionless protocol, a connection-oriented client, at its lower edge, uses the services of a call manager and a connection-oriented miniport, or it uses the services of an MCM。Alternatively, a connection-oriented client can be an adaptation layer (that can be an intermediate driver) residing between a legacy protocol and connection-oriented NDIS. Examples of such an adaptation layer are IP/ATM and LAN Emulation (LANE), both of which use call management services to establish underlying connections, but which hide the connection-oriented nature of this interface from the connectionless protocols above it. Note that the definition of such a connection-oriented client's upper-edge interface is beyond the scope of NDIS documentation. If a client is serving as an adaptation layer, its upper-edge interface is defined by the protocol that it is adapting to connection-oriented NDIS。A connection-oriented client uses the call setup and teardown services of a call manager or MCM and the send and receive services of a connection-oriented NDIS miniport driver. A connection-oriented client can provide its own protocol services to higher levels in the network stack or it can implement an emulation layer that interfaces connectionless legacy protocols and connection-oriented media. An example of an emulation layer fulfilled by a connection-oriented client is a LAN emulation (LANE), which hides the connected-oriented characteristics of ATM and presents a connectionless media (such as Ethernet) to protocols above it。
An NDIS miniport driver can have a non-NDIS lower edge：
3．NDIS Intermediate drivers
An intermediate protocol driver interfaces between protocol drivers, such as a legacy transport driver, and a miniport. A typical reason for developing an intermediate protocol driver is to perform media translation between an existing legacy transport driver and a miniport that manages a NIC for a new media type unknown to the transport driver
1． Call NdisXxxo funcionts 。
2． Exposes ProtocolXxx functions, which NDIS calls to communicate requests from underlying miniports。
3． Exposes MiniportXxx functions, which NDIS calls to communicate the requests of one or more overlying protocol drivers.
To translate between different network media,To filter packets ,To balance packet transmission across more than one NIC
such as Microsoft's Network Load Balancing Provider，and Microsoft's Quality of Service (QoS) are based on NDIS intermediate drivers
4．NDIS TDI Server Transports Protocol Drivers
An upper level protocol driver implements a TDI interface, or possibly another application-specific interface at its upper-edge, to provide services to users of the network. At its lower edge, this type of driver provides a protocol interface to pass packets to and receive incoming packets from the next-lower driver.
kernel-mode protocol drivers. They accept IRPs from TDI clients and process the requests these IRPs represent. This processing might require network communications with a peer, prompting the TDI transport to add protocol-specific headers (such as TCP, UDP, IPX) to data passed in the IRP and to communicate with adapter drivers using NDIS functions (also documented in the DDK). TDI transports generally facilitate application network communications by transparently performing message operations such as segmentation and reassembly, sequencing, acknowledgment, and retransmission
Protocol drivers usually reference low level
transport drivers usually reference high level
4． Call NdisXxx functions to send packets, read and set information maintained by lower-level drivers, and use operating system services
5． ExportsProtocolXxx functions that NDIS calls for its own purposes or on behalf of lower-level drivers to indicate up receive packets, indicate the status of lower-level drivers
often used as the lowest-level driver in a transport driver that implements a transport protocol stack, such as a TCP/IP or IPX/SPX stack
the TCP/IP driver (\Winnt\System32\Drivers\Tcpip.sys) implements TCP, UDP, IP, ARP, ICMP, and IGMP. A TDI transport generally creates device objects that represent particular protocols so that clients can obtain a file object representing a protocol and issue network I/O to the protocol by using IRPs. The TCP/IP driver creates three device objects that represent various TDI-client accessible protocols: \Device\Tcp, \Device\Udp, and \Device\Ip。
So that networking API drivers don't need to employ various interfaces for each transport protocol they might want to use, Microsoft established the Transport Driver Interface (TDI) standard. As mentioned earlier in this chapter, a TDI interface is essentially a convention for the way network requests format into IRPs and for the way network addresses and communications are allocated. Transport protocols that adhere to the TDI standard export the TDI interface to their clients, which include networking API drivers such as AFD and the redirector. A transport protocol implemented as a Windows 2000 device driver is known as a TDI transport. Because TDI transports are device drivers, they format requests they receive from clients as IRPs。Support functions in the \Winnt\System32\Drivers\Tdi.sys library, along with definitions developers include in their drivers, make up the TDI interface.。TDI also supports connectionless communications for connectionless protocols such as UDP. In addition, TDI provides a means whereby a TDI client can register event callbacks 。
Microsoft support these transport protocol:DLC,NetBEUI(NetBIOS API),TCP/IP ,NWLink(IPX/SPX ),AppleTalk
5．Filter-hook driver
filter packets, extends the functionality of the IP filter driver supplied with operating system.
6．TDI Clients/Drivers
Defines a kernel-mode network interface that is exposed at the upper edge of transport protocol stacks。TDI clients, which are kernel-mode drivers such as Redirector and Server, interface with such transports through TDI。Transport drivers that expose only the TDI interface can be used only by TDI clients. To provide increased access to such transports, Windows 2000 includes emulator modules for two popular existing network interfaces, Windows Sockets and NetBIOS. Each of these emulator modules exposes its native set of functions, which are accessible through standard call mechanisms in user mode. When called, the emulator module maps the native function and its associated parameters and procedural rules to one or more TDI functions, and then calls the indicated transport driver through TDI.TCP/IP and IPX/SPX transport drivers are implemented as native TDI transport drivers
are kernel-mode device drivers that usually implement the kernel-mode portion of a networking API's implementation. TDI clients get their name from the fact that the I/O request packets (IRPs) they send to protocol drivers are formatted according to the TDI standard。
