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

Reply via email to