Alter MUP's behavior or NT's configuration
to avoid network access delays
Jane and Joe are eager to get working, so they log on to their Windows NT workstations. Jane decides to work on a file stored on a NetWare server, and Joe decides to print a document on a nearby NetWare printer. To Jane's and Joe's dismay, their systems freeze as they try to access those NetWare resources. After about 30 seconds, the systems grant them access and seem to run flawlessly. Then, 15 minutes later, the same delay occurs again.
If you have a mixed network with systems running the NT Client for Microsoft Networks and Novell's intraNetWare Client for Windows NT, this scenario might sound all too familiar. If you analyze your network's traffic, the analysis will likely reveal that communication difficulties between the client and server are not causing these delays. Instead, you will probably find that the delays are originating in the client system, which seems to pause for several seconds before initiating communication with the NetWare server. Because the delays occur only when users access NetWare resources, you might attribute the problem to a bug in the intraNetWare Client software. But this software is not the culprit. If you remove the NT Client for Microsoft Networks (and any other installed clients) from the system and leave only the intraNetWare Client for Windows NT installed, the delays will disappear, which means that the delays are resulting from having multiple network clients installed on the system.
So what can you do to eliminate these delays? You first need to understand how the Multiple Uniform Naming Convention Provider (MUP), NT's traffic cop, works. You then need to alter MUP's behavior or change NT's configuration.
How MUP Works
When you're working on an application in a mixed NT-NetWare network, you can open files on local drives, on NT network shares, or on NetWare server volumes. Redirectors and MUP (mup.sys) make that process possible.
Both the NT Client for Microsoft Networks and the intraNetWare Client for Windows NT include a module called a redirector. (Other clients that you install on an NT network will also have a redirector.) As the name implies, the redirector redirects a resource request from the NT workstation to the device on the network that can provide that resource.
For example, suppose you select a file from a directory on another system. NT notates that file in Uniform Naming Convention (UNC) format and passes the notation to a redirector. The redirector then transmits the UNC resource request (i.e., the file request) over the network to the system that hosts that file.
For this process to work, NT must tell the difference between UNC names that refer to NT network shares and UNC names that refer to NetWare volumes. (For more information about the differences, see the sidebar, "UNC Identifies Network Resources.") Differentiating between NT and NetWare UNC names is MUP's responsibility. MUP determines which client the system must use to access the requested UNC name and hands off the request to that client's redirector. All applications that use UNC names for their I/O requests require MUP's services. (NT's Multi-Protocol RoutingMPRhandles requests from applications that use Win32 network API calls.)
After MUP receives a UNC request from NT's I/O Manager, MUP determines which of the installed redirectors provides access to the requested resource. MUP uses a five-step trial-and-error process to make this determination:
- MUP attempts to send the request to NT's Distributed File System (DFS) to ascertain whether the system uses DFS. If the system uses DFS, DFS locates the resource. MUP then passes the request to the appropriate redirector. If the system doesn't use DFS, MUP proceeds to step 2.
- MUP determines whether the information it needs to process the request is in its internal cache. If the information is in MUP's internal cache, MUP passes the request to the appropriate redirector. If the information isn't in MUP's internal cache, MUP proceeds to step 3.
- MUP sends the request to the first client redirector and waits for a response that specifies whether that redirector can locate the resource the UNC name identifies.
- MUP then sends the same request to the system's second client redirector and waits for a response. (MUP queries any other redirectors installed on the system in the same way.)
- After MUP receives responses from all the redirectors, it evaluates those responses and sends the UNC request to the redirector that has located the resource. If more than one redirector locates the resource, the redirector with the highest priority receives the request. (You set the redirector priorities in the Network Access Order field of the Network Control Panel's Services screen. By default, the first client you install on the system receives the highest priority.)
This process has several problems that can cause network access delays. First, MUP's attempt to send the UNC request to DFS wastes valuable seconds if the network doesn't use DFS. Second, MUP sends the request to each redirector sequentially (not simultaneously), so MUP wastes time awaiting the response from one redirector before querying another. Finally, MUP wastes time waiting for the responses from all redirectors. Even if the first redirector that MUP queried will receive the request, MUP waits for responses before selecting the request recipient.
Waiting for the responses from all the redirectors is the primary source of access delays. For example, suppose the UNC request identifies a NetWare resource. MUP will always query the NT Client redirector, even if MUP queries the intraNetWare Client redirector first. MUP therefore sends the request to the NT Client redirector and waits for it to fail.
Unfortunately, the NT Client redirector diligently tries to locate the share that the UNC name specifies. It uses all the NetBIOS name resolution mechanisms at its disposal. If your NT Client system uses Windows Internet Naming Service (WINS), the NT Client redirector sequentially queries the primary and secondary WINS servers, which takes about 4 seconds. When WINS fails to resolve the UNC name (which identifies a NetWare server, not a NetBIOS name), the NT Client system resorts to broadcasting NetBIOS name query request messages. This attempt to resolve the UNC name also fails, so the system retransmits the broadcast message four times, with each message taking as long as 4 seconds to time out. Depending on your NT Client system's configuration, other name resolution procedures might add more time to the delay, bringing the total to as many as 30 seconds. (For more information about NT's name resolution processes, see Mark Minasi, "Advanced WINS Features" and "WINS Proxy Agents," September and October 1997.)
Therefore, although MUP already possesses the information it needs to pass the UNC request to the NetWare redirector, MUP remains idle, waiting for a response from the NT Client redirector. The delays occur only when users access NetWare resources, because the NT Client redirector usually locates NT resources quickly with the first WINS query or broadcast message. Thus, time isn't lost requerying WINS or retransmitting broadcast messages.
After MUP sends the request to the NetWare redirector, MUP stores the resource's location in MUP's cache, where MUP can quickly access the information to satisfy repeated requests for the same UNC name. However, every 15 minutes, MUP purges its cache. The entire process then must begin again, which explains the periodic delays.
Prev. page
[1]
2
next page 
