Protocol Manager Can Stay Resident After Binding Occurs (62556)
The information in this article applies to:
- Microsoft LAN Manager 2.0, when used with:
- the operating system: MS-DOS
- Microsoft LAN Manager 2.1, when used with:
- the operating system: MS-DOS
- Microsoft LAN Manager 2.1a, when used with:
- the operating system: MS-DOS
- Microsoft LAN Manager 2.2, when used with:
- the operating system: MS-DOS
This article was previously published under Q62556 SUMMARY
The following information applies to Microsoft LAN Manager versions
2.0, 2.1, 2.1a, and 2.2 for MS-DOS and OS/2.
The NDIS Specification describes the Protocol Manager's role in
initializing the Protocol and MAC (media access control) drivers. The
following is additional information about the conditions under which
the Protocol Manager will stay resident after initialization and
provide other services to network drivers.
MORE INFORMATION
If your workstation is using only ONE protocol driver (for example,
NETBEUI) and one MAC driver, the Protocol Manager does not remain
resident after the binding process takes place.
If, however, you are using multiple protocol drivers (for example,
NETBEUI and TCP/IP) and/or multiple MAC drivers, the Protocol Manager
remains resident and installs a multiplexing module called VECTOR. The
Protocol Manager substitutes VECTOR's entry points for the existing
entry points in each device driver's characteristics table. VECTOR can
then multiplex and de-multiplex calls and packets transparently,
relieving the MAC driver of this task.
If one MAC driver is installed with several protocol drivers, one
VECTOR module is installed to handle the multiple protocol drivers. If
more than one MAC driver binds to multiple protocol drivers, a VECTOR
module is installed for each MAC driver.
The following diagram depicts two resident MAC drivers, each with its
own VECTOR module interface to the multiple protocol drivers:
__________ __________ __________ __________ __________
|Protocol| |Protocol| |Protocol| |Protocol| |Protocol|
| driver | | driver | | driver | | driver | | driver |
---------- ---------- ---------- ---------- ----------
| ^ | ^ | ^ | ^ | ^
\ \ | | / / \ \ / /
v | v | v | v | v |
_____________________________________ _______________________
| VECTOR module | | VECTOR module |
------------------------------------- -----------------------
| ^ | ^
| | | |
v | v |
___________ ___________
| MAC | | MAC |
| driver | | driver |
----------- -----------
If your configuration implements "dynamic binding," the VECTOR
function is always installed at startup time, and thus the Protocol
Manager remains resident.
Dynamic binding is [as in the case of 3Com's DPA (Demand Protocol
Architecture)] implemented to allow loading of a secondary protocol(s)
"on demand." For example, in 3Com's DPA (in MS-DOS), once the Protocol
Manager has installed the VECTOR function, an MS-DOS command such as
TCPON or XNSON is issued to "demand load" a secondary TCP/IP or XNS
protocol. Corresponding MS-DOS commands such as TCPOFF and XNSOFF are
issued to dynamically unload the secondary protocol. These commands
may be issued as standard MS-DOS commands (from the command line, a
batch file, or programmatically).
REFERENCES
"Microsoft/3Com LAN Manager Network Driver Interface Specification"
(public domain available from Microsoft)
"Microsoft LAN Manager Network Device Driver Guide" (included in the
LAN Manager kit)
| Modification Type: | Major | Last Reviewed: | 10/23/2003 |
|---|
| Keywords: | KB62556 |
|---|
|