I approved the large attachments - you should be able to see them now. John
On 7/29/2010 10:52 PM, Varun Chandramohan wrote: > I had sent some logs......but the ML did not let the post through due to the > size. Richard, did you get the mail with logs? > > > On Thursday, July 29, 2010 01:22:39 pm Morrell Richard (external) wrote: >> 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 >> > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
