Service Location Protocol Administration Guide

Modifying Timeouts on SLP Discovery Requests

There are two general situations where timeouts on SLP discovery requests might need to be modified:

If the SLP agents are separated by multiple subnets, dial-up lines, or other WANs, the network latency can be high enough that the default timeouts are insufficient for a request or registration to complete. Conversely, if your network is low latency, performance can be improved by decreasing the timeouts.
In a network with much traffic or a high collision rate, the maximum period that SAs and UAs need to wait before sending a message might be insufficient to assure collision-free transactions.

Changing Default Timeouts

High network latency can cause UAs and SAs to time out in making their requests and registrations before a response returns. Latency can be a problem if a UA is separated from an SA, or both a UA and SA are separated from a DA, either by multiple subnets, a dial-up line, or a WAN. You can determine whether latency is a problem by checking whether UAs and SAs are timing out on requests and registrations and their SLP requests are failing, or by using ping to measure the actual latency.

The sets of configuration properties that control timeouts:

The net.slp.multicastTimeouts, net.slp.DADiscoveryTimeouts, and net.slp.datagramTimeouts. These properties control the list of timeouts used for repeated multicast and unicast UDP message transmissions, before a message transmission is abandoned.
The net.slp.multicastMaximumWait. This property controls the maximum amount of time a multicast message is retransmitted before it is abandoned.

If frequent timeouts are occurring during multicast service discovery or DA discovery, the net.slp.multicastMaximumWait property should be increased from its default value of 15000 milliseconds (15 seconds). Increasing the maximum wait period allows more time for requests on high latency networks to complete. After this property is increased, you should also modify the net.slp.multicastTimeouts and net.slp.DADiscoveryTimeouts lists so that the sum of the integer timeout values in the lists equals the net.slp.multicastMaximumWait value.

As an example, suppose you have determined that multicast requests require 20 seconds (20000 milliseconds) instead of 15 seconds to complete. The following property configurations change the maximum wait time and the list of multicast timeouts:

net.slp.multicastMaximumWait=20000
net.slp.multicastTimeouts=2000,5000,6000,7000
net.slp.DADiscoveryTimeouts=3000,3000,6000,8000

If your network has low latency, you can reduce the net.slp.multicastMaximumWait configuration value and the values in the two multicast timeout lists to reduce waiting time.

A similar procedure works for the timeouts involved in sending a UDP datagram to a DA, except the upper bound on the DA timeout is determined by the sum of the elements in the net.slp.datagramTimeouts list and not a separate property. A UDP datagram is repeatedly sent to a DA until a response is received or the timeout bound is reached. If frequent timeouts occur, the values in the list can be increased.

For example, suppose, as above, you need to increase the datagram timeout bound to 20000 milliseconds to avoid frequent timeouts. The following configuration will achieve that:

net.slp.datagramTimeouts=2000,5000,6000,7000

In high performance networks, you can perform this procedure in reverse to reduce the timeout bound for multicast and unicast UDP datagram transmission. This will reduce the amount of latency in satisfying SLP requests.

Configuring the Random Wait Bound

In networks with heavy traffic or a high collision rate, communication with a DA might be affected. When collision rates are high, the sending agent must retransmit the UDP datagram. You can determine if retransmission is occurring by using snoop to monitor traffic in a network of hosts running slpd as an SA server and a host running slpd as a DA. If multiple service registration messages for the same service from the host running slpd as an SA server are appearing in the snoop trace, then you might have a problem with collisions.

Collisions can be a particular problem at boot time. When a DA is first coming up, it sends out unsolicited advertisements and the SAs respond with their registrations. SLP requires the SAs to wait for a random amount of time after receiving a DA advertisement before responding. The random wait bound is uniformly distributed with a maximum value controlled by the net.slp.randomWaitBound. The default random wait bound is 1000 milliseconds (1 second).

You can lengthen the maximum wait by configuring the property. For example:

net.slp.randomWaitBound=5000

This example lengthens the random wait to 5000 milliseconds (5 seconds).

Lengthening the random wait bound causes longer delay in registration with the DA, so SAs can complete registrations with newly discovered DAs more slowly, thereby avoiding collisions and timeouts.