Aaron The remote DA countdown will not start over on it's own, if there is no refresh from the local slpd, the remote will timeout.
What do you mean by 'backup mode'? There is no backup mode I'm aware of in the OpenSLP codebase. I know the novell version has it. You can send a USR2 sig to the slpd under linux to get it to reinitialize without losing registrations. Also, I'm sure you know about the slp.reg file? If you want services to be really permanent, that's the best route. Sorry, my poor use of terminology there. When I said 'refreshed from your local DA' I meant slpd configured as SA or DA. If you restart an SA/DA cleanly, it sends out a 'I'm going' message on the mcast group to all other SA/Das, When they get that message, they should remove any services from that SA/DA so it won't be timing out. It would only timeout if the local slpd wasn't shut down cleanly. Does that make more sense? To be honest, the whole website needs overhauling and a new release creating, not just that webpage. There is more wrong with that webpage than just that, for example it says that the multicastTimeout param is ignored - that hasn't been true for years! My point really was that your configuration file is wrong. Whoever writes that file will know if the local machine is a DA and therefore will know that it needs adding to the DAAddresses field. cheers Matt -----Original Message----- From: A Burgie [mailto:dajo...@gmail.com] Sent: 16 December 2010 18:47 To: Hird Matthew Cc: openslp-devel@lists.sourceforge.net Subject: Re: [Openslp-devel] SLP service registrations with maximum lifeti me decrease in lifetime when coming from external SA 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. > > 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
