1.3 How the Client for Open Enterprise Server Differs from the Novell Client for Windows XP/2003

The SRVLOC UA initiates discovery of new SLP Directory Agents (DAs) as soon as Windows provides notification that a new TCPIP network interface was created (that is, as soon as each network interface indicates it is physically connected and also has an IP address assigned to it). SRVLOC initiates a DHCP Inform request for SLP configuration information and/or a multicast query for SLP DAs at that time, as appropriate, and saves the SLP DA information learned from each interface.

Any SLP DAs that were manually configured on the workstation are considered global, and apply to all interfaces. Any SLP DAs that are learned through DHCP or by multicast are associated with the specific interface over which they were learned. When a network interface becomes disconnected, the SLP DA information associated with that interface is also removed.

When the Client issues a name resolution request through SRVLOC, all SLP scopes that the SRVLOC UA has been configured with or learned from DAs are used when making the request. For example, if a Novell Client 4.x machine knows of scopes “CORPORATE” and “PARTNER,” a name resolution request is made for both “CORPORATE” and “PARTNER” on any DAs that declared that they support these scopes.

If the SRVLOC UA was configured to support both SLP v2 and SLP v1 and the SLP v2 DAs did not return answers for a query, or the DAs did not support the scopes being queried, the SRVLOC UA issues an unscoped SLP v1 query to any SLP v1 DAs or by multicast to determine whether the service was registered in the SLP v1 unscoped scope.

The SRVLOC UA supports diagnostic and status information that can be queried programmatically. The SLPINFO.EXE tool queries and presents this information to aid in confirming and troubleshooting SLP configurations.

When unicasting directly to an SLP DA, the SRVLOC UA uses UDP datagram communication unless the answer being returned by the DA cannot fit within a UDP datagram. In such an event, a TCP connection to the SLP DA is created long enough to obtain the large result.

To work around the issue described in Novell Client is unable to communicate with OpenSLP Directory Agent over SLPv2, the SRVLOC UA allows setting a “Use SingleEquals in Where (V2)” policy to cause a single equals character to be used in predicate strings.

DHCP-based SLP configuration information is retrieved by the SRVLOC UA through the Client NWDHCP.SYS driver. DHCP-based SLP configuration can be successfully retrieved even when the Windows network adapter is not using DHCP for its IPv4 address configuration, and instead has a static IPv4 address assignment.

The OpenSLP UA does not perform “preemptive discovery” of SLP Directory Agents (DAs). Instead, the OpenSLP UA waits until there is an actual name resolution request to perform, at which point SLP DA discovery by DHCP and multicast can occur. Both DHCP Inform discovery of SLP configuration information and muticast-based discovery of DAs and services occur over all active interfaces.

The OpenSLP discovery process attempts SLP scope and DA discovery in a specific order: first, by manually configured DA and scope information; second, by DHCP-supplied DA and scope information; and finally, by DA and scope information learned from multicast. This order is important because the OpenSLP DA discovery process stops as soon as one or more DAs are successfully found.

During the DA discovery process, the OpenSLP UA intends to find and use just one DA. The OpenSLP UA looks for a DA that supports any one of the scopes the OpenSLP UA is currently configured to use. For example, if the OpenSLP UA currently knows of scopes “CORPORATE” and “PARTNER,” OpenSLP looks for any DA that supports “CORPORATE” or any DA that supports “PARTNER.”

Whichever DA the OpenSLP UA finds first is the only DA (and therefore the only scope) that the OpenSLP UA uses to obtain answers from. The OpenSLP UA does not query both the DAs serving “CORPORATE” and the DAs serving “PARTNER.” The UA queries only one or the other.

While the OpenSLP UA supports configuration with multiple scopes and DAs, the OpenSLP UA only expects to find or use one of those scopes (and therefore, only those DAs supporting that scope) within a given network environment.

There is some merit in manually configuring an OpenSLP UA workstation with a list of more than one scope and more than one DA if the workstation physically moves between networks that require one scope versus the other. DHCP-delivered SLP configuration information can achieve the same goal by delivering only the scope name and DA address information appropriate for the network environment that the DHCP server serves.

The OpenSLP UA is designed for SLP v2 operation only.

As of Novell Client 2 SP2 (IR4) and later, the Client includes an SLPINFO.EXE tool for displaying the workstation discovered SLP Directory Agents and SLP Scopes. Differences in the underlying OpenSLP LIBSLP User Agent implementation prevent the diagnostic information from being as granular as the Novell Client for Windows XP/2003 SRVLOC User Agent.

When unicasting directly to an SLP DA, the OpenSLP UA always uses TCP connections to the SLP DA. UDP is still used for multicast and broadcast discovery and queries, but DA connections are TCP-only.

The OpenSLP UA (or more specifically, the SLPNSP name service provider used by the Client for Open Enterprise Server) does not yet provide a solution for the issue of using a single equals character in a predicate string.

DHCP-based SLP configuration information is retrieved by the OpenSLP UA through the Microsoft DHCP Client Service included with the Windows operating system. The Microsoft DHCP Client Service only supports retrieving DHCP-based configuration information when the Windows network adapter itself is configured to acquire IPv4 address information via DHCP. If the Windows network adapter is configured with a static IPv4 address, the SLP DA and/or SLP scope list will need to be manually configured on the machine, as the it will not retrieve SLP configuration information via DHCP. Or the machine will need to successfully learn SLP DA and scopes via multicast every time the machine boots. For more information, see Novell Client 2 does not retrieve SLP information when using static IPv4 address.