Microsoft KB Archive/62556

= Protocol Manager Can Stay Resident After Binding Occurs =

Article ID: 62556

Article Last Modified on 10/23/2003

-

APPLIES TO


 * Microsoft LAN Manager 2.0 Standard Edition, when used with:
 * Microsoft MS-DOS 6.22 Standard Edition
 * Microsoft LAN Manager 2.1 Standard Edition, when used with:
 * Microsoft MS-DOS 6.22 Standard Edition
 * Microsoft LAN Manager 2.1a, when used with:
 * Microsoft MS-DOS 6.22 Standard Edition
 * Microsoft LAN Manager 2.2 Standard Edition, when used with:
 * Microsoft MS-DOS 6.22 Standard Edition

-



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 &quot;dynamic binding,&quot; 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) &quot;on demand.&quot; 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 &quot;demand load&quot; 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).

