心情不好，灌水！

rt

心情不好的话，你可以去挣专家分呀。呵呵。

会得太少，不会得太多，赚不到阿。

心情不好的话，你可以去挣专家分呀。呵呵。

NDISWAN
NDISWAN is an intermediate NDIS driver that performs PPP protocol/link framing, compression, and encryption. NDISWAN converts an NDIS_PACKET from an upper-layer transport driver to an NDIS_WAN_PACKET and passes the reformatted packet to an underlying WAN miniport driver. NDISWAN supports both connectionless and connection-oriented miniports.

When functioning in a connection-oriented environment, NDISWAN acts as a connection-oriented client with respect to the TAPI proxy driver, which presents a call manager interface to NDISWAN.

WAN miniport
A WAN miniport calls many of the same NDIS functions and supplies many of the same handlers as does a non-WAN NDIS miniport. A WAN miniport, however, calls special WAN-related NDIS functions when sending packets and when indicating receive packets to overlying protocols. WAN miniports also use an NDIS_WAN_PACKET structure instead of an NDIS_PACKET structure. In addition, WAN miniports maintain WAN-specific information and respond to WAN-specific queries of this information. A WAN miniport can support connectionless or connection-oriented media.

Serial driver
The serial driver is a standard device driver for internal serial ports or multiport serial cards. The built-in asynchronous WAN miniport for Windows 2000 uses the internal serial driver for modem communications.

NDISTAPI
NDISTAPI is a kernel-mode component that exposes connectionless miniports to the TAPI device space. NDISTAPI accepts call setup and teardown requests from the TAPI service provider and directs such requests through NDISWAN to the correct miniport to set up, monitor, and tear down lines and calls.

NDPROXY
The TAPI proxy is a kernel-mode component that exposes connection-oriented miniports to the TAPI device space. NDPROXY serves as a call manager to NDISWAN and as a connection-oriented client to connection-oriented miniports. (For more information on the connection-oriented network environment, see Section 2.4.2.)

Figure 2.9 Windows 2000 WAN Environment

The WAN environment includes the following components:

Remote Access Service (RAS)
RAS allows user-mode applications to make dial-up connections. After a RAS connection has been established, a user application can connect to network services through a standard network interface, such as Windows Sockets, NetBIOS, Named Pipes, or RPC.

TAPI service provider
The TAPI service provider is a user-mode component that accepts call setup and teardown requests from RAS clients and from TAPI-aware applications through the Service Provider Interface (SPI). The TAPI service provider converts such SPI requests to TAPI requests and sends the requests to NDISTAPI if the call is over connectionless media or to TAPI Proxy if the call is over connection-oriented media.

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.

For more information on connection-oriented drivers, see Part 4 of the Network Drivers Design Guide in the Windows 2000 DDK.

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.

Figure 2.7 Connection-Oriented Environment with a Call Manager

Figure 2.8 shows a configuration of connection-oriented clients and an MCM driver.



Figure 2.8 Connection-Oriented Environment with an MCM

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.

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.

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.

More than one call manager and/or MCM can coexist in the same environment. Also, each call manager or MCM can support more than one signaling protocol.

2.4.2 Connection-Oriented Environment for Network Drivers
NDIS supports the following connection-oriented drivers:

Connection-oriented miniports
Connection-oriented clients
Call managers
Integrated miniport call managers (MCM)
Figure 2.7 shows a configuration of connection-oriented clients, a call manager, and a connection-oriented miniport.

2.4.1 Connectionless Environment for Network Drivers
Figure 2.6 shows the NDIS environment for connectionless network drivers:



Figure 2.6 Connectionless Network Driver Environment

The connectionless environment is the standard network driver environment for connectionless media, such as Ethernet and Token Ring. See Section 2 for a description of the drivers in this environment.

Built on Wednesday, June 28, 2000

This section describes the Microsoft? Windows? 2000 network environments for the following types of kernel-mode network drivers:

Connectionless drivers
Connection-oriented drivers
WAN drivers

TDI clients, which are kernel-mode drivers such as Redirector and Server, interface with such transports through TDI. TDI simplifies the task of developing transport drivers in that only the TDI interface needs to be coded. It also simplifies the task of developing clients by minimizing the amount of transport-specific code that must be written.

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.

For increased performance, the TCP/IP and IPX/SPX transport drivers are implemented as native TDI transport drivers.

The Transport Driver Interface (TDI) defines a kernel-mode network interface that is exposed at the upper edge of transport protocol stacks (see Figure 2.5).



Figure 2.5 TDI Clients and Transports

2.2.3 NDIS Protocol Drivers
A network protocol, which is the highest driver in the NDIS hierarchy of drivers, is 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. A transport protocol driver allocates packets, copies data from the sending application into the packet, and sends these packets to the lower level driver by calling NDIS functions. A protocol driver also provides a protocol interface to receive incoming packets from the next lower-level driver. A transport protocol driver transfers received data to the appropriate client application.

At its lower edge, a protocol driver interfaces with intermediate network drivers and miniport NIC drivers. The protocol driver calls NdisXxx functions to send packets, read and set information maintained by lower-level drivers, and use operating system services. The protocol driver also exports a set of entry points (ProtocolXxx 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, and to otherwise communicate with the protocol driver.

At its upper edge, a transport protocol driver has a private interface to a higher-level driver in the protocol stack.

Built on Wednesday, June 28, 2000

Intermediate drivers are typically used in the following ways:

To translate between different network media
For example, the function of an intermediate driver layered between Ethernet and Token Ring transports and an ATM miniport is to map Ethernet and Token Ring packets to ATM packets and vice versa.

To filter packets
A packet scheduler is an example of an intermediate driver used as a filter driver. A packet scheduler reads priority information in each send packet passed down by a transport for transmission and each receive packet indicated up by a miniport. The packet scheduler then schedules each packet for transmission or reception based on its priority.

To balance packet transmission across more than one NIC
A load balancing driver exposes one virtual adapter to overlying transport protocols but distributes send packets across more than one NIC.

Built on Wednesday, June 28, 2000

Although it exports a subset of the MiniportXxx functions at its upper edge, an intermediate driver does not actually manage a physical NIC. Instead, it exports one or more virtual adapters, to which overlying protocols can bind. To a protocol driver, a virtual adapter exported by an intermediate driver appears to be a physical NIC. When a protocol driver sends packets or requests to a virtual adapter, the intermediate driver propagates these packets and requests to the underlying miniport. When the underlying miniport indicates up receives packets, responds to a protocol\'s requests for information, or indicates status, the intermediate driver propagates such packets, responses, and status up to the protocol drivers that are bound to the virtual adapter.

看不懂的，更加心情不好了！！！ :D :D :D

Figure 2.4 Intermediate Driver Layered Between Miniport Driver and Transport Driver

Because of its intermediate position in the driver hierarchy, an intermediate driver must communicate with both overlying protocol drivers and underlying miniport drivers:

At its lower edge, an intermediate driver exposes protocol entry points (ProtocolXxx functions), which NDIS calls to communicate requests from underlying miniports. To an underlying miniport driver, an intermediate driver thus appears to be a protocol driver
At its upper edge, an intermediate driver exposes miniport entry points (MiniportXxx functions), which NDIS calls to communicate the requests of one or more overlying protocol drivers. To an overlying protocol driver, an intermediate driver thus appears to be a miniport driver.

2.2.2 NDIS Intermediate Drivers
As Figure 2.4 illustrates, intermediate drivers are typically layered between miniport drivers and transport protocol drivers.