The issue here is that slpd doesn't treat the configured DA (either with
properties or DHCP) as a permanent fixture, rather it uses DA as a
jump-start for the system. Therefore, if the request fails, the DA is
removed and is dependent upon a new discovery of the DA (via multicast). If
the failure mechanism didn't exist, you could have the problem of invalid
DAs filling up your database over time -- and slpd may not revert to
multicast requests, as it thinks DAs are still available.
I can see arguments for forcing configured DAs to stay around (although that
would block multicast), but this seems like a group decision. At any rate,
if you wanted to play with this on your own, I would suggest starting with
the following changes in slpd_knownda.c:
1) have a SLPDatabase or linked list named G_SlpdConfiguredDAs that
SLPDKnownDAFromDHCP and SLPKnownDAFromProperties use to store the configured
DA addresses.
2) Change SLPDKnownDARemove to only remove the addr if it is not in
G_SlpdConfiguredDAs.
You will still have the "removed from list" error message (maybe a return
from SLPDKnownDARemove could block the message), and I don't know offhand
what other side effects would occur.
--Nick
On 8/23/07, Johannes Gutleber <[EMAIL PROTECTED]> wrote:
>
> 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
