Rationale for the change in revision 1597: Our system uses a large number of independent DAs (with their own unique scope), we search the whole system (all DAs) for services, and prior to this change, the library would only use unicast when it could find a single DA that supported all scopes.
This meant that, in our system, the library would always use multicast, and there would always be a minimum delay in getting results, even if all the DAs responded quickly. This change meant that the search terminated as soon as the last DA responded, minimising the delay. This code is only used when IPv4 is enabled, so you should be able to check whether it is causing the problem by running the same test with IPv4 disabled. Note that at the time I made this change, having IPv4 enabled meant that IPv6 was not enabled. I assume you are running with both enabled - if not, then this code does not come into play with IPv6 enabled. I don't believe openslp-2.0.0-beta1 supported simultaneous IPv4 and IPv6 operation either. Regards, Richard -----Original Message----- From: Varun Chandramohan [mailto:var...@linux.vnet.ibm.com] Sent: 29 July 2010 06:22 To: Morrell Richard (external) Subject: Re: Possible Bug! Suggestions! Hi Richard, I hope you had a good vacation. I have been just browsing around the logs to find the changes that started this new scenario. The team here reported that openslp-2.0-beta1 available on website does not show this behavior. Merely based on logs i assume commit #1597 made by you might have changed this behavior. I did not fully understand the reason for this change. Can you please explain? Regards, Varun On Wednesday, July 28, 2010 03:22:20 pm you wrote: > Hi Folks, > > The test team here have reposted with a bug. Here is the transcript. > > I have two systems set up with a: > > ipv4 address > link local ipv6 address > global ipv6 address > > I will set up a service - say using: > > slptool register service:myserve.xxx://192.168.3.110 "(attr1=1),(attr2=2)" > slptool register service:myserve.xxx://2002:2001::xxxx:xxxx:xxxx:xxxx/64 "(attr3=3),(attr4=4)" (xxxx denotes values) > > If I do a slptool findattrs service:myserve.xxx://2002:2001::xxxx:xxxx:xxxx:xxxx I receive back: > > >>> 41 lines of the following > > (attr3=3),(attr4=4) > > ============================================================= > > Using only one ipv6 link local and one ipv6 global address with no ipv4 address defined, I got 42 lines of attributes with the following command: > > slptool findattrs service:myserv.xxx > > > Is there a way to minimize the number of returns for a query? That amount of return information seems excessive and will break applications. > > Unicast seems ok and I only receive 2 lines of info. for findsrvs and 1 line of information for attributes. > > > I too have observed it...is this expected behavior? Any suggestions/solutions? > > Regards, > Varun > 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. ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm _______________________________________________ Openslp-devel mailing list Openslp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openslp-devel
