分享
 
 
 

不得不看Microsoft.Press.Microsoft.Windows.Internals.Fourth.Edition.Dec.2004.internal.eBook

王朝system·作者佚名  2006-04-18
窄屏简体版  字體: |||超大  

http://book.itzero.com/read/microsoft/0507/Microsoft.Press.Microsoft.Windows.Internals.Fourth.Edition.Dec.2004.internal.eBook-DDU_html/0735619174/toc.html

Process Internals

This section describes the key Windows process data structures. Also listed are key kernel variables, performance counters, and functions and tools that relate to processes.

Data Structures

Each Windows process is represented by an executive process (EPROCESS) block. Besides containing many attributes relating to a process, an EPROCESS block contains and points to a number of other related data structures. For example, each process has one or more threads represented by executive thread (ETHREAD) blocks. (Thread data structures are explained in the section "Thread Internals" later in this chapter.) The EPROCESS block and its related data structures exist in system space, with the exception of the process environment block (PEB), which exists in the process address space (because it contains information that is modified by user-mode code).

In addition to the EPROCESS block, the Windows subsystem process (Csrss) maintains a parallel structure for each Windows process that executes a Windows program. Also, the kernelmode part of the Windows subsystem (Win32k.sys) has a per-process data structure that is created the first time a thread calls a Windows USER or GDI function that is implemented in kernel mode.

Figure 6-1 is a simplified diagram of the process and thread data structures. Each data structure shown in the figure is described in detail in this chapter.

Figure 6-1. Data structures associated with processes and threads

First let's focus on the process block. (We'll get to the thread block in the section "Thread Internals" later in the chapter.) Figure 6-2 shows the key fields in an EPROCESS block.

Figure 6-2. Structure of an executive process block

Chapter 1 for more information on the kernel debugger and how to perform kernel debugging on the local system.) The output (truncated for the sake of space) looks like this:

lkd> dt _eprocess

nt!_EPROCESS

+0x000Pcb : _KPROCESS

+0x06cProcessLock : _EX_PUSH_LOCK

+0x070CreateTime : _LARGE_INTEGER

+0x078ExitTime : _LARGE_INTEGER

+0x080RundownProtect : _EX_RUNDOWN_REF

+0x084UniqueProcessId : Ptr32Void

+0x088ActiveProcessLinks : _LIST_ENTRY

+0x090QuotaUsage : [3] Uint4B

+0x09cQuotaPeak : [3] Uint4B

+0x0a8CommitCharge : Uint4B

+0x0acPeakVirtualSize : Uint4B

+0x0b0VirtualSize : Uint4B

+0x0b4SessionProcessLinks : _LIST_ENTRY

+0x0bcDebugPort : Ptr32Void

+0x0c0ExceptionPort : Ptr32Void

+0x0c4ObjectTable : Ptr32_HANDLE_TABLE

+0x0c8Token : _EX_FAST_REF

+0x0ccWorkingSetLock : _FAST_MUTEX

+0x0ecWorkingSetPage : Uint4B

+0x0f0AddressCreationLock : _FAST_MUTEX

+0x110HyperSpaceLock : Uint4B

+0x114ForkInProgress : Ptr32_ETHREAD

+0x118HardwareTrigger : Uint4B

Note that the first field (Pcb) is actually a substructure, the kernel process block (KPROCESS), which is where scheduling-related information is stored. To display the format of the kernel process block, type dt_kprocess:

lkd>dt _kprocess

nt!_KPROCESS

+0x000Header : _DISPATCHER_HEADER

+0x010ProfileListHead : _LIST_ENTRY

+0x018DirectoryTableBase : [2]Uint4B

+0x020LdtDescriptor : _KGDTENTRY

+0x028Int21Descriptor : _KIDTENTRY

+0x030IopmOffset : Uint2B

+0x032Iopl : UChar

+0x033Unused : UChar

+0x034ActiveProcessors : Uint4B

+0x038KernelTime : Uint4B

+0x03cUserTime : Uint4B

+0x040ReadyListHead : _LIST_ENTRY

+0x048SwapListEntry : _SINGLE_LIST_ENTRY

+0x04cVdmTrapcHandler : Ptr32Void

+0x050ThreadListHead : _LIST_ENTRY

+0x058ProcessLock : Uint4B

+0x05cAffinity : Uint4B

+0x060StackCount : Uint2B

+0x062BasePriority : Char

+0x063ThreadQuantum : Char

+0x064AutoAlignment : UChar

+0x065State : UChar

+0x066ThreadSeed : UChar

+0x067DisableBoost : UChar

+0x068PowerState : UChar

+0x069DisableQuantum : UChar

+0x06aIdealNode : UChar

+0x06bSpare : UChar

An alternate way to see the KPROCESS (and other substructures in the EPROCESS) is to use the recursion (-r) switch of the dt command. For example, typing dt _eprocess – r1 will recurse and display all substructures one level deep.

The dt command shows the format of a process block, not its contents. To show an instance of an actual process, you can specify the address of an EPROCESS structure as an argument to the dt command. You can get the address of all the EPROCESS blocks in the system by using the !process 0 0 command. An annotated example of the output from this command is included later in this chapter.

Table 6-1 explains some of the fields in the preceding experiment in more detail and includes references to other places in the book where you can find more information about them. As we've said before and will no doubt say again, processes and threads are such an integral part of Windows that it's impossible to talk about them without referring to many other parts of the system. To keep the length of this chapter manageable, however, we've covered those related subjects (such as memory management, security, objects, and handles) elsewhere.

Table 6-1. Contents of the EPROCESS Block

Element

Purpose

Additional Reference

Kernel process (KPROCESS) block

Common dispatcher object header, pointer to the process page directory, list of kernel thread (KTHREAD) blocks belonging to the process, default base priority, quantum, affinity mask, and total kernel and user time for the threads in the process.

Thread Scheduling (Chapter 6)

Process identification

Unique process ID, creating process ID, name of image being run, window station process is running on.

Quota block

Limits on nonpaged pool, paged pool, and page file usage plus current and peak process nonpaged and paged pool usage. (Note: Several processes can share this structure: all the system processes point to the single systemwide default quota block; all the processes in the interactive session share a single quota block that Winlogon sets up.)

Virtual address descriptors (VADs)

Series of data structures that describes the status of the portions of the address space that exist in the process.

Virtual Address Descriptors (Chapter 7)

Working set information

Pointer to working set list (MMWSL structure); current, peak, minimum, and maximum working set size; last trim time; page fault count; memory priority; outswap flags; page fault history.

Working Sets (Chapter 7)

Virtual memory information

Current and peak virtual size, page file usage, hardware page table entry for process page directory.

Chapter 7

Exception local procedure call (LPC) port

Interprocess communication channel to which the process manager sends a message when one of the process's threads causes an exception.

Exception Dispatching (Chapter 3)

Debugging LPC port

Interprocess communication channel to which the process manager sends a message when one of the process's threads causes a debug event.

Local Procedure Calls (LPCs) (Chapter 3)

Access token (ACCESS_TOKEN)

Executive object describing the security profile of this process.

Chapter 8

Handle table

Address of per-process handle table.

Object Handles and the Process Handle Table (Chapter 3)

Device map

Address of object directory to resolve device name references in (supports multiple users).

Object Names (Chapter 3)

Process environment block (PEB)

Image information (base address, version numbers, module list), process heap information, and threadlocal storage utilization. (Note: The pointers to the process heaps start at the first byte after the PEB.)

Chapter 6

Windows subsystem process block (W32PROCESS)

Process details needed by the kernel-mode component of the Windows subsystem.

The kernel process (KPROCESS) block, which is part of the EPROCESS block, and the process environment block (PEB), which is pointed to by the EPROCESS block, contain additional details about the process object. The KPROCESS block (which is sometimes called the PCB, or process control block) is illustrated in Figure 6-3. It contains the basic information that the Windows kernel needs to schedule threads. (Page directories are covered in Chapter 7, and kernel thread blocks are described in more detail later in this chapter.)

Figure 6-3. Structure of the executive process block

The PEB, which lives in the user process address space, contains information needed by the image loader, the heap manager, and other Windows system DLLs that need to modify it from user mode. (The EPROCESS and KPROCESS blocks are accessible only from kernel mode.) The basic structure of the PEB is illustrated in Figure 6-4 and is explained in more detail later in this chapter.

Figure 6-4. Fields of the process environment block

!process command as follows:

lkd> !process

PROCESS 8575f030 SessionId: 0 Cid: 08d0 Peb: 7ffdf000 ParentCid: 0360

DirBase: 1a81b000 ObjectTable: e12bd418 HandleCount: 66.

Image: windbg.exe

Then specify that address to the !peb command as follows:

lkd> !peb7ffdf000

PEB at 7ffdf000

InheritedAddressSpace: No

ReadImageFileExecOptions: No

BeingDebugged: No

ImageBaseAddress: 01000000

Ldr 00181e90

Ldr.Initialized: Yes

Ldr.InInitializationOrderModuleList: 00181f28 . 00183188

Ldr.InLoadOrderModuleList: 00181ec0 . 00183178

Ldr.InMemoryOrderModuleList: 00181ec8 . 00183180

BaseTimeStamp Module

1000000 40478dbd Mar 04 15:12:45 2004 C:\Program Files

\DebuggingToolsfor

Windows\windbg.exe

77f500003eb1b41a May01 19:56:10 2003 C:\WINDOWS

\System32\ntdll.dll

77e600003d6dfa28 Aug29 06:40:40 2002 C:\WINDOWS

\system32\kernel32.dll

200000040476db2 Mar04 12:56:02 2004 C:\Program Files

\DebuggingToolsfor

Windows\dbgeng.dll

.

SubSystemData: 00000000

ProcessHeap: 00080000

ProcessParameters: 00020000

WindowTitle: 'C:\Documents and Settings\AllUsers\Start

Menu\Programs\Debugging

Tools for Windows\WinDbg.lnk'

ImageFile: 'C:\ProgramFiles\DebuggingTools forWindows

\windbg.exe'

CommandLine: '"C:\Program Files\Debugging Toolsfor

Windows\windbg.exe" '

DllPath: 'C:\ProgramFiles\DebuggingToolsforWindows;C:

\WINDOWS\System32;C:

\WINDOWS\system;C:\WINDOWS;.;C:\Program Files\Windows

ResourceKits\Tools\;C:\WINDOWS

system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\ProgramFiles

\SupportTools\;c:\sysint

;C:\ProgramFiles\ATI Technologies\ATIControl Panel;C:

\ProgramFiles\Resource Kit\;C:

\PROGRA~1\CA\Common\SCANEN~1;C:\PROGRA~1\CA\eTrust\ANTIVI~1;C:

\ProgramFiles\Common

Files\RoxioShared\DLLShared;C:\SFU\common\'

Environment: 00010000

=::=::

ALLUSERSPROFILE=C:\Documents andSettings\All Users

APPDATA=C:\Documents and Settings\dsolomon\ApplicationData

Kernel Variables

A few key kernel global variables that relate to processes are listed in Table 6-2. These variables are referred to later in the chapter, when the steps in creating a process are described.

Table 6-2. Process-Related Kernel Variables

Variable

Type

Description

PsActiveProcessHead

Queue header

List head of process blocks

PsIdleProcess

EPROCESS

Idle process block

PsInitialSystemProcess

Pointer to EPROCESS

Pointer to the process block of the initial system process that contains the system threads

PspCreateProcessNotifyRoutine

Array of pointers

Array of pointers to routines to be called on process creation and deletion (maximum of eight)

PspCreateProcessNotifyRoutineCount

DWORD

Count of registered process notification routines

PspLoadImageNotifyRoutine

Array of pointers

Array of pointers to routines to be called on image load

PspLoadImageNotifyRoutineCount

DWORD

Count of registered imageload notification routines

PspCidTable

Pointer to HANDLE_TABLE

Handle table for process and thread client IDs

Performance Counters

Windows maintains a number of counters with which you can track the processes running on your system; you can retrieve these counters programmatically or view them with the Performance tool. Table 6-3 lists the performance counters relevant to processes (except for memory management and I/O-related counters, which are described in Chapters 7 and 9, respectively).

Table 6-3. Process-Related Performance Counters

Object: Counter

Function

Process: % Privileged Time

Describes the percentage of time that the threads in the process have run in kernel mode during a specified interval.

Process: % Processor Time

Describes the percentage of CPU time that the threads in the process have used during a specified interval. This count is the sum of % Privileged Time and % User Time.

Process: % User Time

Describes the percentage of time that the threads in the process have run in user mode during a specified interval.

Process: Elapsed Time

Describes the total elapsed time in seconds since this process was created.

Process: ID Process

Returns the process ID. This ID applies only while the process exists because process IDs are reused.

Process: Creating Process ID

Returns the process ID of the creating process. This value isn't updated if the creating process exits.

Process: Thread Count

Returns the number of threads in the process.

Process: Handle Count

Returns the number of handles open in the process.

Relevant Functions

For reference purposes, some of the Windows functions that apply to processes are described in Table 6-4. For further information, consult the Windows API documentation in the MSDN Library.

Table 6-4. Process-Related Functions

Function

Description

CreateProcess

Creates a new process and thread using the caller's security identification

CreateProcessAsUser

Creates a new process and thread with the specified alternate security token

CreateProcessWithLogonW

Creates a new process and thread to run under the credentials of the specified username and password

CreateProcessWithTokenW

Creates a new process and thread with the specified alternate security token, with additional options such as allowing the user profile to be loaded

OpenProcess

Returns a handle to the specified process object

ExitProcess

Ends a process, and notifies all attached DLLs

TerminateProcess

Ends a process without notifying the DLLs

FlushInstructionCache

Empties the specified process's instruction cache

GetProcessTimes

Obtains a process's timing information, describing how much time the process has spent in user and kernel mode

GetExitCodeProcess

Returns the exit code for a process, indicating how and why the process shut down

GetCommandLine

Returns a pointer to the command-line string passed to the current process

GetCurrentProcess

Returns a pseudo handle for the current process

GetCurrentProcessId

Returns the ID of the current process

GetProcessVersion

Returns the major and minor versions of the Windows version on which the specified process expects to run

GetStartupInfo

Returns the contents of the STARTUPINFO structure specified during CreateProcess

GetEnvironmentStrings

Returns the address of the environment block

GetEnvironmentVariable

Returns a specific environment variable

Get/SetProcessShutdownParameters

Defines the shutdown priority and number of retries for the current process

GetGuiResources

Returns a count of User and GDI handles

lkd> !process

PROCESS 8575f030 SessionId: 0 Cid: 08d0 Peb: 7ffdf000

ParentCid: 0360

DirBase: 1a81b000 ObjectTable: e12bd418 HandleCount: 65.

Image:windbg.exe

VadRoot 857f05e0 Vads 71 Clone 0 Private 1152.

Modified98. Locked 1.

DeviceMap e1e96c88

Token e1f5b8a8

ElapsedTime 1:23:06.0219

UserTime 0:00:11.0897

KernelTime 0:00:07.0450

QuotaPoolUsage[PagedPool] 38068

QuotaPoolUsage[NonPagedPool] 2840

Working Set Sizes (now,min,max) (2552, 50, 345)

(10208KB, 200KB, 1380KB)

PeakWorkingSetSize 2715

VirtualSize 41 Mb

PeakVirtualSize 41 Mb

PageFaultCount 3658

MemoryPriority BACKGROUND

BasePriority 8

CommitCharge 1566

After the basic process output comes a list of the threads in the process. That output is explained in the "Experiment: Using the Kernel Debugger !thread Command" section later in the chapter. Other commands that display process information include !handle, which dumps the process handle table (which is described in more detail in the section "Object Handles and the Process Handle Table" in Chapter 3). Process and thread security structures are described in Chapter 8.

NDIS Drivers

When a protocol driver wants to read or write messages formatted in its protocol's format from or to the network, the driver must do so using a network adapter. Because expecting protocol drivers to understand the nuances of every network adapter on the market (proprietary network adapters number in the thousands) isn't feasible, network adapter vendors provide device drivers that can take network messages and transmit them via the vendors' proprietary hardware. In 1989, Microsoft and 3Com jointly developed the Network Driver Interface Specification (NDIS), which lets protocol drivers communicate with network adapter drivers in a device-independent manner. Network adapter drivers that conform to NDIS are called NDIS drivers or NDIS miniport drivers. The version of NDIS that ships with Windows 2000 is NDIS 5, and the version that ships with Windows XP and Windows Server 2003 is NDIS 5.1.

The NDIS library (\Windows\System32\Drivers\Ndis.sys) implements the NDIS boundary that exists between TDI transports (typically) and NDIS drivers. As is Tdi.sys, the NDIS library is a helper library that NDIS driver clients use to format commands they send to NDIS drivers. NDIS drivers interface with the library to receive requests and send back responses. Figure 13-18 shows the relationship between various NDIS-related components.

Figure 13-18. NDIS components

One of Microsoft's goals for its network architecture was to let network adapter vendors easily develop NDIS drivers and take driver code and move it between Consumer Windows and Windows 2000. Thus, instead of merely providing the NDIS boundary helper routines, the NDIS library provides NDIS drivers an entire execution environment. NDIS drivers aren't genuine Windows drivers because they can't function without the encapsulation the NDIS library gives them. This insulation layer wraps NDIS drivers so thoroughly that NDIS drivers don't accept and process IRPs. Rather, TDI protocol drivers call a function in the NDIS library, NdisAllocatePacket, and pass the packets to an NDIS miniport by calling an NDIS library function (NdisSend, for example). By default, NDIS drivers also don't have to worry about reentrancy, in which the NDIS library invokes an NDIS driver with a new request before the driver has finished servicing a previous request. Exemption from reentrancy means that NDIS driver writers don't need to worry about complex synchronization, which is made even more tricky because of the parallel execution possible on a multiprocessor.

Note

NdisSend, for example).

Although the NDIS library's serialization of NDIS drivers simplifies development, serialization can hamper multiprocessor scalability. Standard NDIS 4 drivers (the Windows NT 4 version of the NDIS library) don't scale well for certain operations on multiprocessors. Microsoft gave developers a deserialized operation option in NDIS 5. NDIS 5 drivers can indicate to the NDIS library that they don't want to be serialized; the NDIS library will then forward requests to the driver as fast as it receives the IRPs that describe the requests. Responsibility for queuing and managing multiple simultaneous requests falls on the NDIS driver, but deserialization confers the benefit of higher multiprocessor performance.

NDIS 5 also includes the following features:

NDIS drivers can report whether or not their network medium is active, which allows Windows to display a network connected/disconnected icon on the taskbar. This feature also allows protocols and other applications to be aware of this state and react accordingly. The TCP/IP transport, for example, will use this information to determine when it should reevaluate addressing information it receives from DHCP.

TCP/IP task offloading allows a miniport to use advanced features of a network adapter to perform operations such as packet checksums and Internet Protocol security (IPSec). This task offloading can improve system performance by relieving the CPU from these operations.

Wake-on-LAN allows a wake-on-LAN-capable network adapter to bring Windows out of a suspend power state. Events that can trigger the network adapter to signal the system include media connections (such as plugging a network cable into the adapter), the receipt of protocol-specific patterns registered by a protocol (the TCP/IP transport asks to be woken for Address Resolution Protocol [ARP] requests), and, for Ethernet adapters, the receipt of a magic packet (a network packet that contains 16 contiguous copies of the adapter's Ethernet address).

Connection-oriented NDIS allows NDIS drivers to manage connection-oriented media such as Asynchronous Transfer Mode (ATM) devices. (Connection-oriented NDIS is described in more detail shortly.)

The interfaces that the NDIS library provides for NDIS drivers to interface with network adapter hardware are available via functions that translate directly to corresponding functions in the HAL.

kd> .load ndiskd

Loaded ndiskd extension DLL

kd> !miniports

Driver verifier level: 0

Failed allocations: 0

Miniport Driver Block: 817aa610

Miniport: 817b1130 RAS Async Adapter

Miniport Driver Block: 81a1ef30

Miniport: 81a1ea70 DirectParallel

Miniport Driver Block: 81a21cd0

Miniport: 81a217f0 WAN Miniport (PPTP)

Miniport Driver Block: 81a23290

Miniport: 81a22130 WAN Miniport (L2TP)

Miniport Driver Block: 81a275f0

Miniport: 81a25130 Intel 8255x-based PCI Ethernet Adapter(10/100)

kd> !miniport 81a25130

Miniport 81a25130 : Intel 8255x-based PCI Ethernet Adapter(10/100)

Flags : 20413208

BUS_MASTER, INDICATES_PACKETS,

IGNORE_REQUEST_QUEUE

IGNORE_TOKEN_RING_ERRORS, NDIS_5_0,

RESOURCES_AVAILABLE, DESERIALIZED,

MEDIA_CONNECTED,

NOT_SUPPORTS_MEDIA_SENSE,

PnPFlags : 00010021

PM_SUPPORTED, DEVICE_POWER_ENABLED,

RECEIVED_START

CheckforHang interval: 2 seconds

CurrentTick : 0001

IntervalTicks : 0001

InternalResetCount : 0000

MiniportResetCount : 0000

References: 3

UserModeOpenReferences: 0

PnPDeviceState : PNP_DEVICE_STARTED

CurrentDevicePowerState : PowerDeviceD0

Bus PM capabilities

DeviceD1:1

DeviceD2:1

WakeFromD0:0

WakeFromD1:1

WakeFromD2:0

WakeFromD3:0

SystemStateDeviceState

PowerSystemUnspecifiedPowerDeviceUnspecified

S0D0

S1D1

S2PowerDeviceUnspecified

S3PowerDeviceUnspecified

S4D3

S5D3

SystemWake: S1

DeviceWake: D1

WakeupMethodes Enabled 6:

WAKE_UP_PATTERN_MATCH WAKE_UP_LINK_CHANGE

WakeUpCapabilities of the miniport

MinMagicPacketWakeUp: 4

MinPatternWakeUp: 4

MinLinkChangeWakeUp: 4

Current PnP and PM Settings: : 00000030

DISABLE_WAKE_UP, DISABLE_WAKE_ON_RECONNECT,

Allocated Resources:

Memory: f4100000, Length: 1000

IO Port: 1440, Length: 40

Memory: f4000000, Length: 100000

Interrupt Level: 9, Vector: 9

Translated Allocated Resources:

Memory: f4100000, Length: 1000

IO Port: 1440, Length: 40

Memory: f4000000, Length: 100000

Interrupt Level: 12, Vector: 39

MediaType : 802.3

DeviceObject : 81a25030, PhysDO : 81a93cd0 Next DO:

81a63030

MapRegisters : 819fc000

FirstPendingPkt: 0

SingleWorkItems:

[0]: 81a254e8 [1]: 81a254f4 [2]: 81a25500 [3]: 81a2550c

[4]: 81a25518 [5]: 81a25524

DriverVerifyFlags :00000000

MiniportOpen BlockQueue:

8164b888: Protocol 816524a8 = NBF, ProtocolContext 81649030

8191f628: Protocol 81928d88 = TCPIP, ProtocolContext

8191f728

Miniport Interrupt 81a00970

The Flags field for the miniport that was examined indicates that the miniport supports deserialized operation (DESERIALIZED), that the media is currently active (MEDIA_CONNECTED), and that it is an NDIS 5 miniport driver (NDIS_5_0). Also listed are the adapter's system-to-device power-state mappings and the bus resources that the Plug and Play manager assigned to the adapter. (See the section "The Power Manager" in Chapter 9 for more information on power-state mappings.)

Variations on the NDIS Miniport

The NDIS model also supports hybrid TDI transport-NDIS drivers, called NDIS intermediate drivers. These drivers lie between TDI transports and NDIS drivers. To an NDIS driver, an NDIS intermediate driver looks like a TDI transport; to a TDI transport, an NDIS intermediate driver looks like an NDIS driver. NDIS intermediate drivers can see all network traffic taking place on a system because the drivers lie between protocol drivers and network drivers. Software that provides fault tolerant and load balancing options for network adapters, such as Microsoft's Network Load Balancing Provider, are based on NDIS intermediate drivers.

Connection-Oriented NDIS

Support for connection-oriented network hardware (for example, ATM) is native in Windows, which makes connection management and establishment standard in the Windows network architecture. Connection-oriented NDIS drivers use many of the same APIs that standard NDIS drivers use; however, connection-oriented NDIS drivers send packets through established network connections rather than place them on the network medium.

In addition to miniport support for connection-oriented media, NDIS 5 includes definitions for drivers that work to support a connection-oriented miniport driver:

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.

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.

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.

Figure 13-19 shows the relationships between these components.

Figure 13-19. Connection-oriented NDIS drivers

Network Monitor also includes a number of other features, such as capture triggers and filters, that make it a powerful tool for troubleshooting network problems.

Remote NDIS

Prior to the development of Remote NDIS, a vendor that developed a USB network device, for example, had to provide a driver that interfaced with NDIS as a miniport driver as well as interfacing with a USB WDM bus driver, as shown in Figure 13-20. If the vendor's hardware supported other busses, such as IEEE 1394, they were required to implement drivers that interfaced with each specific bus type.

Figure 13-20. NDIS miniport driver for a USB network device

Remote NDIS is a specification for network devices on dynamic Plug and Play I/O buses such as USB, IEEE 1394, and Infiniband. The specification eliminates the need for a hardware vendor to write an NDIS miniport driver at all by defining bus-independent messages and the mechanism by which the messages are transmitted over various buses. Remote NDIS messages mirror the NDIS interface and include messages for initializing and resetting a device, transmitting and receiving packets, setting and querying device parameters, and indicating media link status.

The Remote NDIS architecture, in Figure 13-21, relies on a Microsoft-supplied NDIS miniport driver, \Windows\System32\Drivers\Rndismp.sys, that translates NDIS commands and forwards them to a bus transport driver for the bus on which a device is located. The architecture allows for a single NDIS miniport driver to be used for all Remote NDIS drivers and a single bus transport driver for each supported bus.

Figure 13-21. Remote NDIS architecture for USB network devices

Currently, Remote NDIS for USB devices is included on Windows XP and Windows Server 2003 and available as a download from Microsoft for Windows 2000. While Remote NDIS on IEEE 1394 is fully specified, Windows does not yet support it.

QOS

If no special measures are taken, IP traffic is delivered over a network on a first-come, firstserve basis. Applications have no control over the priority of their messages, and they can experience bursty network behavior, where they occasionally obtain high throughput and low latencies, but otherwise receive poor network performance. While this level of service is acceptable in most situations, an increasing number of network applications demand more consistent service levels, or quality of service (QOS) guarantees. Video conferencing, media streaming, and enterprise resource planning (ERP) are examples of applications that require good network performance. QOS allows an application to specify minimum bandwidth and maximum latencies, which can be satisfied only if every networking software and hardware component between a sender and receiver supports QOS standards such as IEEE 802.1P, an industry standard that specifies the format of QOS packets and how OSI layer 2 devices (switches and network adapters) respond to them.

Windows QOS support is based on a handful of Microsoft-defined Winsock APIs that allow an application to request QOS for traffic over their Winsock sockets. For example, an application uses WSCInstallQOSTemplate to install a QOS template that specifies desired bandwidth and latency. A second API, the Traffic Control (TC) API, lets an administrative application more precisely control the traffic flow over a networks attached to the computer.

The heart of the Windows QOS implementation is the Resource Reservation Protocol (RSVP) Win32 service (\Windows\System32\Rsvp.exe), as shown in Figure 13-22 The RSVP Winsock service provider (\Windows\System32\Rsvpsp.dll) communicates application QOS requests via RPC to the RSVP service. The RSVP service in turn uses the TC API to control traffic flow. The TC API, which is implemented in \Windows\System32\Traffic.dll, sends I/O control commands to the Generic Packet Classifier (GPC) driver (\Windows\System32\Msgpc.sys). The GPC driver communicates closely with the QOS packet scheduler NDIS intermediate driver (\Windows\System32\Psched.sys) to control the flow of packets to the network from the computer so that the QOS levels promised to particular applications can be met, and so that appropriate QOS headers can be placed on packets for which QOS is desired.

Figure 13-22. QOS architecture

Note

RSVP signaling functionality is removed in Windows XP and Windows Server 2003. While the RSVP service still executes, it serves only as a conduit between applications and traffic control components.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有