How to Change Default Timeouts
Use the following procedure to change the SLP properties that control timeouts.
Become superuser.
Stop slpd and all SLP activity on the host.
# /etc/init.d/slpd stop
Back up the default /etc/inet/slp.conf file before you change the configuration settings.
Change the net.slp.multicastMaximumWait property in the slpd.conf file:
net.slp.multicastMaximumWait=value
value
A 32-bit integer that lists the sum of the values that are set for net.slp.multicastTimeouts and net.slp.DADiscoveryTimeouts
Default Value=15000 milliseconds (15 seconds)
Range of Values=1000 to 60000 milliseconds
For example, if you determine that multicast requests require 20 seconds (20000 milliseconds), you would adjust the values that are listed for net.slp.multicastTimeouts and the net.slp.DADiscoveryTimeouts properties to equal 20000 milliseconds.
net.slp.multicastMaximumWait=20000 net.slp.multicastTimeouts=2000,5000,6000,7000 net.slp.DADiscoveryTimeouts=3000,3000,6000,8000
If necessary, change the net.slp.datagramTimeouts property in the slpd.conf file:
net.slp.datagramTimeouts=value
value
A list of 32-bit integers that specify timeouts, in milliseconds, to implement unicast datagram transmission to DAs
Default=3000,3000,3000
For example, you can increase the datagram timeout to 20000 milliseconds to avoid frequent timeouts.
net.slp.datagramTimeouts=2000,5000,6000,7000
In high-performance networks, you can reduce the time-out bound for multicast and unicast UDP datagram transmission. When you reduce the time-out bound, you decrease latency that is required to satisfy SLP requests.
Save your changes and close the file.
Restart slpd to activate your changes.
# /etc/init.d/slpd start
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 on a network of hosts that are running slpd as an SA server and a host that is running slpd as a DA. If multiple service registration messages for the same service appear in the snoop trace from the host that is running slpd as an SA server, you might have notice collisions.
Collisions can be particularly troubling at boot time. When a DA first starts, it sends unsolicited advertisements and the SAs respond with 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 that is controlled by the net.slp.randomWaitBound. The default random-wait bound is 1000 milliseconds (1 second).
How to Configure the Random-Wait Bound
Use the following procedure to change the net.slp.RandomWaitBound property in the slp.conf file.
Become superuser.
Stop slpd and all SLP activity on the host.
# /etc/init.d/slpd stop
Back up the default /etc/inet/slp.conf file before you change the configuration settings.
Change the net.slp.RandomWaitBound property in the slpd.conf file:
net.slp.RandomWaitBound=value
value
The upper bound for calculating the random-wait time before attempting to contact a DA
Default Value=1000 milliseconds (1 second)
Range of Values=1000 to 3000 milliseconds
For example, you can lengthen the maximum wait to 5000 milliseconds (5 seconds).
net.slp.randomWaitBound=5000
When you lengthen the random-wait bound, a longer delay in registration occurs. SAs can complete registrations with newly discovered DAs more slowly to avoid collisions and timeouts.
If necessary, change the net.slp.datagramTimeouts property in the slpd.conf file:
net.slp.datgramTimeouts=value
value
A list of 32-bit integers that specify timeouts, in milliseconds, to implement unicast datagram transmission to DAs
Default=3000,3000,3000
For example, you can increase the datagram timeout to 20000 milliseconds to avoid frequent timeouts.
net.slp.datagramTimeouts=2000,5000,6000,7000
In high-performance networks, you can reduce the time-out bound for multicast and unicast UDP datagram transmission. This setting reduces the amount of latency in satisfying SLP requests.
Save your changes and close the file.
Restart slpd to activate your changes.
# /etc/init.d/slpd start
Deploying Scopes
With scopes, you can provision services that depend on the logical, physical, and administrative groupings of users. You can use scopes to administer access to service advertisements.
Use the net.slp.useScopes property to create scopes. For example, in the /etc/inet/slp.conf file on a host, add a new scope, called newscope, as shown:
net.slp.useScopes=newscope |
Your organization might, for example, have an alcove of networked devices--such as printers and fax machines--at the end of the south hall on the second floor of Building 6. These devices could be used by everyone on the second floor, or you might restrict the usage to members of a certain department. Scopes provide a way for you to provision access to the service advertisements for these machines.
If the devices are dedicated to a single department, you can create a scope with the department name, for example, mktg. Devices that belong to other departments can be configured with different scope names.
In another scenario, the departments might be dispersed. For instance, the mechanical engineering and the CAD/CAM departments might be split between floors 1 and 2. However, you can provide the floor 2 machines for the hosts on both floors by assigning them to the same scope. You can deploy scopes in any manner that operates well with your network and users.
Note - UAs that have particular scope are not prevented from actually using services that are advertised in other scopes. Configuring scopes controls only which service advertisements a UA detects. The service is responsible for enforcing any access control restrictions.
When to Configure Scopes
SLP can function adequately without any scope configuration. In the Solaris operating environment, the default scope for SLP is default. If no scopes are configured, default is the scope of all SLP messages.
You can configure scopes in any of the following circumstances.
The organizations you support want to restrict service advertisement access to their own members.
The physical layout of the organization you support suggests that services in a certain area be accessed by particular users.
The service advertisements that are appropriate for specific users to see must be partitioned.
An example of the first circumstance was cited in "Configuring DA Discovery for Dial-up Networks". An example of the second is a situation in which an organization is spread between two buildings, and you want users in a building to access local services in that building. You can configure users in Building 1 with the B1 scope, while you configure users in Building 2 with the B2 scope.
Considerations When Configuring Scopes
When you modify the net.slp.useScopes property in the slpd.conf file, you configure scopes for all agents on the host. If the host is running any SAs or is acting as a DA, you must configure this property if you want to configure the SAs or DA into scopes other than default. If only UAs are running on the machine and the UAs should discover SAs and DAs supporting scopes other than default, you do not need to configure the property unless you want to restrict the scopes the UAs use. If the property is not configured, UAs can automatically discover available DAs and scopes through slpd. The SLP daemon uses active and passive DA discovery to find DAs, or it uses SA discovery if no DAs are running. Alternatively, if the property is configured, UAs use only the configured scopes and do not discard them.
If you decide to configure scopes, you should consider keeping the default scope on the list of configured scopes unless you are sure that all SAs in the network have scopes configured. If any SAs are left unconfigured, UAs with configured scopes are unable to find them. This situation occurs because the unconfigured SAs automatically have scope default, but the UAs have the configured scopes.
If you also decide to configure DAs by setting the net.slp.DAAddresses property, be sure that the scopes that are supported by the configured DAs are the same as the scopes that you have configured with the net.slp.useScopes property. If the scopes are different, slpd prints an error message when it is restarted.