|
|
| [back to "Making server connections from Notes"]
How Notes Makes a Connection (sidebar)
A look at how a Notes client uses Server Connection documents in the process of making a connection points out two things that seem almost contradictory. The first is the minor role these documents play in the connection search process -- they are, after all, only one of several tools and strategies Notes uses to try to find a path to the destination server. But the second is how much these documents can do to improve the efficiency of the connection process. Looking for a Server Connection document in its own Personal Address Book is the first step the client takes. If one is found, all the other steps can be skipped, and the performance benefit can be great.
This process is probably more important -- and certainly more interesting -- to Notes administrators than it is to Notes users. It is complex (the simplified description that follows is by no means a complete listing of the steps Notes takes). But an understanding of what Notes is doing can help a user who has problems opening databases they have been sent links to, for example. And it can help an administrator configure a site so that the tools Notes uses, name services and passthru particularly, will have a higher probability of success.
To make a server connection, Notes follows a sequence of steps that can be broken down into two phases: (1) searching for a path to the destination server, and (2) making the actual connection to the server.
In the search phase, Notes considers all the possible options to determine the best path to the destination server. A path consists of the destination server name, a list of passthru servers (if necessary) to go through to reach that server, and the type of connection, port, and address needed to reach the server (or the first passthru server if one is used).
Before the Notes client begins the connection search process, it does a quick check for current connections. There are two possibilities:
The client may have already connected to the destination server during the current session. Notes caches this information in RAM for the duration of the session, so if the path to the server has been followed and cached, this is the fastest way to retrieve it.
The client may already be connected to the destination server over an X.PC (COM) port. If such a connection exists, Notes will use the same port. (This is important only for making server-to-server connections via dial-up as efficient as possible. It handles the possibility that the other server already has established a connection to the first server.)
The server search can be divided into seven major steps. If any step yields a valid path to the server, Notes skips the remaining steps and proceeds to connect. The steps in the search phase are:
1. Check for Normal-priority Server Connection documents.
2. Use the last-known address.
3. Send a name service request to the home server.
4. Try network probes.
5. Include Low-priority Server Connection documents.
6. Send a connection request to the default passthru server.
7. Try "last chance" passthru.
Here is a simplified explanation of these steps, and an examination of some of the options. (The focus here is on making connections from a PC running a Notes client to a Domino server, but the same information will generally apply to server-to-server connections, as well.)
1. Check for Server Connection documents.
The first step the client takes is to check for Server Connection documents that match the destination server name and have their priority field set to Normal. If a Connection document is found that specifies a passthru server, Notes will also look for Connection documents that match the passthru server name.
If a Server Connection document is found for the destination server and no passthru server is named in it, then this document is enough to completely specify a path, and the connection begins: The client sends a connection request to the network address the document provides.
If passthru is specified, then the process is repeated: The client checks for Server Connection documents that match the passthru server name. If a path is found to the passthru server, then the client connects to it, and the passthru server repeats the process, checking in its Public Address Book for a Server document that matches the destination server.
Notes will also match Server Connection documents with wildcards in the destination server field, such as */Acme (this wildcard feature is new in Release 4.6). In the case of multiple possible matches (separate Server Connection documents that specify */Acme and Sales/Acme, for example) the more specific Server Connection document (Sales/Acme) is used.
2. Use the last-known address.
If no Server Connection documents are found to specify a path, the client checks to see if there is a last-known address for the destination server from the current Location. This step rests on a feature of Notes that saves the address information for successful connections over the LAN. The port name and server address are saved in the Personal Address Book -- Notes stores a list of last-known addresses for each Location document. This information is erased if the Location document is changed, or if it isn't used for an extended period of time (the default is set to a month).
If an address exists, the client will try to connect to the server. If this succeeds, the path has been verified and the search is done.
If the address doesn't exist, or the connection attempt fails, the search continues with Step 3.
3. Send a name service request to the home server.
Steps 1 and 2 execute entirely on the client PC, so they can be performed very quickly. If they don't yield a path, it means the client doesn't have sufficient information to define a path to the destination server by itself, and it has to call on the home server or default passthru server for help, which can make a search take longer.
When the client exhausts its own resources, the next thing it tries is to send a name service request to the home server identified in the current Location document.
If the home server has an entry for the server for the same port the client's request came in on, it will return that address.
If the name server is not able to provide an address, the client tries a network probe.
4. Try network probes.
In this step the client probes the network for a connection -- it sends out a connection request to the destination server on each of its ports, using the server's common name as its address.
The chances of a probe succeeding depend mostly on the protocol the network is running. On LANs running the NetBIOS protocol, a probe is often sufficient to reach the server because Notes uses the common name of the server as its NetBIOS address. On LANs running the TCP protocol, on the other hand, a probe may not suffice. The TCP driver will guess at the host name of the destination server by combining the destination server's common name with the domain portion of the requesting workstation's host name. The success or failure of this guess will depend on whether the destination server belongs to the same TCP/IP domain or not. Here's how a workstation, fred.acme.com, connects to the server Sales/Acme (which would have a host name of sales.acme.com) over TCP, using its common name, Sales, as its address:
When the workstation's TCP port driver receives "Sales" as the address, the TCP port driver guesses that the full host name of Sales/Acme is sales.acme.com, based on the domain information (".acme.com") in the workstation's host name.
The TCP port driver requests the address of sales.acme.com from the TCP network's Domain Name Service (DNS).
The DNS returns the actual IP address.
Notes connects to the server using that address.
If the destination server had belonged to a TCP/IP domain different from acme.com, then the "guessed" hostname would be incorrect, and the connection attempt would fail.
5. Include Low-priority Server Connection documents.
If the client's probes fail to produce a connection, it goes back to Step 1 -- with a slight variation. It checks for Server Connection documents that match the destination server and have their priority field set to Low. This allows the client to attempt a dial-up connection to the destination server only if it isn't first found on the LAN. This behavior is important only because it preserves compatibility with releases of Notes prior to Release 4.0 for applications that depended on it, but it may also be useful in situations where you want Notes to try to make a fast connection before it settles for a slow one.
6. Use default passthru.
If the client hasn't yet found a path to the server, it is still possible that Notes can get there by using passthru. The client checks the current Location document for a default passthru server. If one is specified, Notes attempts to find a path to it using the above steps.
7. Try "last chance" passthru.
If Notes can't find a path to the default passthru server or none is specified, Notes tries one last gambit: It checks to see if the client is connected to a server via the X.PC port -- that is, if it's made a dial-up connection. If it has, Notes will select that server as the passthru server, and send a connection request.
Making the Connection
When Notes finds a valid path to a server, it will handle the authentication of the client and server and complete the connection -- and subsequent server connections along the path, if passthru is involved. Once Notes successfully connects to the server it caches the path information, so that subsequent connections to the same server do not repeat the search process, but use this saved path information. If the location is changed or edited, the saved path information is discarded.
Copyright 1998 Iris Associates, Inc. All rights reserved.
|
 | |
|