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 Novell 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 TID 10095884: 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.

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.

Neither the OpenSLP UA nor the manner in which the Novell Client 2 SP1 for Windows employs it currently supports the level of diagnostic information that SLPINFO.EXE provided. The OpenSLP project supports logging in general, but currently only supports logging in the OpenSLP DA, not the OpenSLP UA.

As such, capturing a network traffic LAN trace of a workstation's SLP interaction is usually the most effective tool for troubleshooting SLP-related actions on a Novell Client for Windows workstation or Windows 2008 server.

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 Novell Client 2 SP1 for Windows and the Novell Client for Linux) does not yet provide a solution for the issue of using a single equals character in a predicate string.