Hello Nick, I have a followup to our e-mail exchange from last month:
On Jul 31, 2007, at 16:54 , Nick Wagner wrote: > I've attached my DA slpd.conf. It's unaltered, so you'll note that > the scope is something other than what you want to use. The basic > scenario is that everything passively detects DAs, and actively > detects them when coming on-line and at a relatively long period. > DAs announce themselves at a relatively short period, so the > passive listeners can pick up the new guy quickly. Since there is > usually an order of magnitude smaller DAs on the network, this > should create less network traffic than if everyone was actively > discovering on a short period. > <slp.conf> I am using your DA configuration file adapter to my environment. Now I can run the DA and the slpd daemons on all other machines detect services also through our intermediate switched. If I kill the DA, the other machines seem to fall back to local multicast (ok for me). If the DA is restarted, it seems that somehow all other slpd daemons get an invalidation message (I can't figure out how that is possible, since there's no multicast, but it happens somehow) and I can find no services anymore. Once I republish all services I am back int the original state. Up to this point the behaviour is acceptable for me. Now comes my still unresolved problem: When slpd daemons that are not DAs are started and the DA is not running, the demons try 3 times to discover the DA and then they remove its IP from its internal list (there's a log written to slpd.log: SLPD: Didn't receive response from DA at 10.176.29.112, removing it from list.) Now if I start the DA, nothing seems to happen. Also paying with the configuration value net.slp.DAActiveDiscoveryInterval = 3 doesn't seem to have any effect. Could you help us figuring out, how to configure the "client" slpd daemons such that they can attach to an DA that is coming up later without multicast? Naively I thought the DiscoveryInterval setting should do that for us, but it doesn't seem to do that. Also forcing a rediscovery with slptool findsrvs service:directory-agent yields no result. We still seem to miss some bit. Kind regards Johannes ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Openslp-users mailing list Openslp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openslp-users
