Client Initialization and Get Nearest Server

(Last modified: 25Nov2002)

This document (10022605) is provided subject to the disclaimer at the end of this document.

goal

fact

Novell NetWare 4.11

Novell NetWare 5.0

Novell clients

Formerly TID# 2905539

fix

Below are the descriptions for clients and GNS.

NetX Client

When netx is loaded the client requests a Get Nearest Server of type 4. If there is no response after twenty attempts netx fails with the error file server not found.

If there is a Preferred Server specified in the NET.CFG then the client attempts two Get Nearest Server requests. If there is no reply it then does a General Service Query. All Servers and Routers reply to the General Service Query. The set parameter reply to get nearest server=off doesn't apply to the General Service Query.

VLM Client

With VLMs the client requests in the following order until it receives a response:

Number of Attempts
Type 278 Service Request
Get Nearest Server 2
General Service Query 2
Type 4 Service Request
Get Nearest Server 2
General Service Query 2

If there is a preferred server and NO preferred tree specified in the NET.CFG:

Number of Attempts

Type 4 Service Request
Get Nearest Server 2
General Service Query 2

A Preferred Tree overrides a Preferred Server when both are listed in the NET.CFG. With a Preferred Tree in the NET.CFG it works the same as the default (first example). By default the VLMs use service type 278 before service type 4. To change the service type sequence to 4 then 278 add NETWARE PROTOCOL = BIND NDS to the NET.CFG. (Do not have a Preferred Tree in the NET.CFG.)

Associated Issues:

A workstation gets its initial attachment to a server on the same segment as the workstations, even though the file server has set reply to get nearest server turned off. IPXRTR when loaded with advanced IPX enabled will reply to get nearest server of type 278 (tree type) but not respond to get nearest server of type 4 (file server type). VLMs try a get nearest server of type 278 first by default. If IPXRTR isn't loaded, the 4.10 server does not respond to get nearest server of either type. IPXRTR was fixed May, 1995, it will not respond to get nearest server of type 4 or 278.

Client32

The Client32 first determines what frame types are available on the network by using Get Nearest Server requests on all frame types. To establish the server connection it will send out additional Get Nearest Server requests using the default frame type specified in the NET.CFG. If there is no default specified it will use the first available frame type.

For now we are assuming that the Get Nearest Requests to establish the server connection are handled the same as the VLMs. This is true for Client 32 versions prior to v2.20.

The intraNetWare Client for Windows 95 and DOS/Windows v2.20 (CLIENT32.NLM) has been enhanced to support new SAP extensions which include a new SAP request (request type 14). SAP request type 14 is a "get specific" SAP request with which the client can perform a SAP request for a specific Server or Tree name. With the 2.20 Client, if both Preferred Tree (PT) and Preferred Server (PS) are specified, the Client will send a SAP request type 14 to try to locate the PS. If the PS supports the new SAP request type 14 and responds, the client will create a connection with the PS and determine whether or not the PS is in the PT (it uses a "Ping for NDS" to do this). If the PS is in the PT, then the connection with the PS maintained, at least until login is run. If the PS is not in the PT, then the connection with the PS is destroyed, and the client sends a SAP request type 14 to try to locate the PT. A connection is created with the first server to respond to this request. Note: Currently, the intraNetWare Client 4.11 for Windows NT does not support this new functionality (and will not support it until post-NetWare 5).

Service Advertising Protocol (SAP)

SAP allows service-providing nodes such as file servers, print servers, and gateway servers to advertise their services and addresses. SAP makes the process of adding and removing services on an internetwork dynamic. As servers are booted up, they advertise their services using SAP; when they are brought down, they use SAP to indicate that their services are no longer available.

The primary users of all this information are servers, which store the data in the bindery for easy access. The server creates a bindery object using the advertised name and type for each advertising entity not residing on the server. The object created is dynamic, and is deleted when the file server is brought down. Every dynamic object created by SAP has a single property, NET_ADDRESS, which contains the full IPX internet address (net, node, and socket) of the advertising server.

With NetWare 4, this information is stored in the dynamic bindery partition. These are the bindery objects seen when a user runs a utility such as SYSCON, SLIST, NLIST /b, or PCONSOLE to look at the list of known services.

Through SAP, clients on the network can determine what services are available on the network and obtain the internetwork address of the nodes (servers) where they can access those services. This is an important function, because a workstation cannot initiate a session with a file server without first having that server's address.

By default, all servers advertising with SAP (file servers, print servers, and SAA gateway servers, for example) broadcast a SAP packet every 60 seconds onto the network segment it is connected to. The SAP agent in each router on that segment copies the information contained in the SAP packet into an internal table called the Server Information table.

Because the SAP agent in each router keeps up-to-date information about available servers, a client wanting to locate an SAA gateway server can access a nearby router for the correct internetwork address of the gateway server.

Service Advertising Broadcasts

Using SAP, servers on a NetWare network can advertise their services and addresses. The information that these servers broadcast is not used directly by clients, but is instead collected by a SAP agent within each NetWare router on the server's segment. The SAP agents store this information in a Server Information table and, if they reside within a server, in their server's bindery. The clients can then contact the nearest SAP agent or file server for server information.
The SAP broadcasts that servers perform are local broadcasts and, therefore, are only received by SAP agents on their connected segments. Consequently, SAP agents periodically broadcast their server information so that all SAP agents on the internetwork have information about all servers that are active on the internetwork. This is the same broadcast method used by routers to distribute and exchange network number (RIP) information.

SAP Packet Structure

The Operation field defines the operation that the packet is performing. The packet can perform four different operations:

A Get Nearest Server Request for the name and address of the nearest server of a certain type (this is represented by a Get Nearest Server entry on a TRACK ON screen).

A General Service Request for the names and addresses of either all the servers or all the servers of a certain type on the internetwork (represented by a Send All Server Info entry on the TRACK ON screen).

A Get Nearest Server Response (represented by a Give Nearest Server entry on TRACK ON screen).

A General Service Response.

A General Service Response includes, periodic broadcasts by servers and routers, changed service information broadcasts and responses to general service queries

Following the Operation field are one or more sets of fields. Each set includes Service Type, Server Name, Network Address, Node Address, Socket Address, and Hops to Server fields. If the packet contains information about more than one service, it contains more than one set of fields (n sets of fields). Each SAP packet can contain information about up to seven services.

With NetWare 4, the number of SAP entries per packet can be adjusted. In addition, NetWare 4 allows the periodic broadcast interval to be adjusted from the default of every 60 seconds. These periodic broadcasts keep all routers on the internetwork synchronized and provide a means of "aging" (removing after a certain timeout) those services that might become inaccessible because of a router or server failure. Service names are typically aged from the routing database in three minutes following the last receipt of an advertisement for that service name. .

document

Document Title:	Client Initialization and Get Nearest Server
Document ID:	10022605
Solution ID:	1.0.41900875.2434166
Creation Date:	02Dec1999
Modified Date:	25Nov2002
Novell Product Class:	NetWare

disclaimer

The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information.
Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.