Matt, Thank-you for the information. This morning, thinking as you did that the service may refresh, I queried and found that it had refreshed on the remote server so it appears that something pushed out the registration to the box after it reached zero (assuming it did not start over on its own which is what we're assuming). That is an interesting implementation of the non-expiring relevance of the 65535 number and if I may ask I have a question with this in mind.
In a normal slpd (as a DA in this case) setup when slpd is restarted all registrations are lost. The local DA loses its information and the remote DA will lose it when the timeout reaches zero, so within several hours at most. If the local DA is set to use backup mode, though, the current registrations are written to a file and reloaded when it comes back up. If this happened with a permanent registration I imagine it would come back up and still be permanent on the local DA until it was deregistered properly; however, what about the remote DA? I am under the (mistaken?) impression that the SA is what sent out the registration to both DAs, but you mentioned explicitly that "the service will be refreshed from your local DA". Do you mean the DA portion of the slpd service or just something about the machine hosting the DA will refresh the remote machine? Will the DA, if it loads this permanent registration from a backup on startup, still update remote DAs every once in a while to keep them updated? Going to your point about the DAAddresses not pointing to the local machine when isDA=true is there a better document or set of information outside of the RFCs on how OpenSLP specifically is implemented? Should I change the appropriate files in SVN to clarify the need to always point to oneself via DAAddresses when running as a DA? Thanks again for your information, Aaron On Thu, Dec 16, 2010 at 03:12, Hird Matthew <matthew.h...@uk.thalesgroup.com> wrote: > Oh and be careful with that documentation, I'm not convinced it's right for > the latest trunk version. > > > > -----Original Message----- > From: Hird Matthew [mailto:matthew.h...@uk.thalesgroup.com] > Sent: 16 December 2010 10:01 > To: 'A Burgie'; openslp-devel@lists.sourceforge.net > Subject: Re: [Openslp-devel] SLP service registrations with maximum lifeti > me decrease in lifetime when coming from external SA > > Aaron > > Are your 2 DAs sharing the same scope? Does the service ever disappear from > the remote DA? According to the RFC, the service will be refreshed from your > local DA and although it counts down in the remote DA, it shouldn't ever > disappear. It's not a bug. > > I'm not sure about your configuration. Personally I would say it was an > invalid config seeing as you're specifying your DAs in DAAddresses but then > setting up your local machine as a DA that's not in that list. I'm not sure > what slpd will do in that situation. What happens if you search for > service:directory-agent? Does your local DA appear in the list? > > cheers > Matt > > > -----Original Message----- > From: A Burgie [mailto:dajo...@gmail.com] > Sent: 16 December 2010 05:38 > To: openslp-devel@lists.sourceforge.net > Subject: [Openslp-devel] SLP service registrations with maximum lifetime > decrease in lifetime when coming from external SA > > I noticed a quirk last night which I reproduced today more fully while > working on adding a service lifetime option to the slptool command. > Specifically if I register something with slptool on a machine that is a DA > then that registration will stick with a lifetime of 65535 forever as it > should (per the RFC). What is interesting is what happens on a remote DA > specified with the DAAddresses command. My slp.conf has one isDA=true (for > this local machine) but only has DAAddresses pointing to the remote box. > Both machines, correctly or incorrectly (another, unrelated I believe, > issue), get the service registration but the remote DA starts counting down > as if 65535 were not some special value. The local DA does not count down > but keeps the registration forever. If I change the systems so that the > remote box is now the local box and point them in an opposite way the same > thing happens in reverse: the remote DA (remote from the SA) counts down > though the local DA does not. > > Register: > slptool register service:ab16serv.z://dns.is.here '(attr0=val0)' > > Check machines: > slptool unicastfindsrvs ipAddrGoesHere service:ab16serv.z > > Changing the IP address in the check above between the local and remote > systems will show the difference. I believe this is a bug and will enter it > if somebody can confirm it for me. I am using the OpenSLP 1.2.x version > that ships with Novell Open Enterprise Server > (OES) 2 SP2 (latest patches as of today). > > I'm also interested to see what others think about isDA being set to true > even though it is not in the list of DAAddresses and then both the local DA > and the DA in the DAAddresses setting getting registrations. Since the DA > and SA both seem to be within the slpd process I'm not too surprised by this > functionality but the following link seems to imply (if not state outright) > that only the configured DAAddresses values should be used if that is set, > which rules out the local DA: > > http://www.openslp.org/doc/html/UsersGuide/SlpConf.html > > Thanks, > Aaron > > ---------------------------------------------------------------------------- > -- > Lotusphere 2011 > Register now for Lotusphere 2011 and learn how to connect the dots, take > your collaborative environment to the next level, and enter the era of > Social Business. > http://p.sf.net/sfu/lotusphere-d2d > _______________________________________________ > Openslp-devel mailing list > Openslp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openslp-devel > > This email, including any attachment, is a confidential communication > intended solely for the use of the individual or entity to whom it is > addressed. It contains information which is private and may be proprietary > or covered by legal professional privilege. If you have received this email > in error, please notify the sender upon receipt, and immediately delete it > from your system. > > Anything contained in this email that is not connected with the businesses > of this company is neither endorsed by nor is the liability of this company. > > Whilst we have taken reasonable precautions to ensure that any attachment to > this email has been swept for viruses, we cannot accept liability for any > damage sustained as a result of software viruses, and would advise that you > carry out your own virus checks before opening any attachment. > > > ---------------------------------------------------------------------------- > -- > Lotusphere 2011 > Register now for Lotusphere 2011 and learn how to connect the dots, take > your collaborative environment to the next level, and enter the era of > Social Business. > http://p.sf.net/sfu/lotusphere-d2d > _______________________________________________ > Openslp-devel mailing list > Openslp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openslp-devel > > This email, including any attachment, is a confidential communication > intended solely for the use of the individual or entity to whom it is > addressed. It contains information which is private and may be proprietary > or covered by legal professional privilege. If you have received this email > in error, please notify the sender upon receipt, and immediately delete it > from your system. > > Anything contained in this email that is not connected with the businesses > of this company is neither endorsed by nor is the liability of this company. > > Whilst we have taken reasonable precautions to ensure that any attachment to > this email has been swept for viruses, we cannot accept liability for any > damage sustained as a result of software viruses, and would advise that you > carry out your own virus checks before opening any attachment. > > ------------------------------------------------------------------------------ Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d _______________________________________________ Openslp-devel mailing list Openslp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openslp-devel
