Good news: I have verified that the loopback address was used properly. It
turned out to be a late-night copy/paste error of some gettimeofday code on
my side, which would explain the timeouts :)
I've checked in the code, since basic functionality with slptool seems to
work on windows and linux. Please make sure it still works to your
satisfaction on your side. Most of the changes are "build-cosmetic", but
you never know..
--Nick
On Mon, Oct 20, 2008 at 2:59 AM, Morrell Richard <
[EMAIL PROTECTED]> wrote:
> Hi Nick,
>
> Thanks for checking out the changes in Windows. Sorry they're causing
> problems.
>
> The KnownDASpanningListFromCache code does not treat the loopback address
> as special - it just scans the cache of known DAs, and adds DAs to its list
> until all the requested scopes have been satisfied. If it can't find a list
> of DAs that together cover all its scopes, it uses the previous mechanism,
> calling NetworkConnectToDA, and then falling back to multicast if
> necessary. Note that the stale DA detection change means that the cache in
> the library no longer has a fixed order, but follows the order of the cache
> in the daemon, which can change when a DAAdvert is received. However, if
> your local daemon is a DA, then the first entry returned when finding scopes
> is always the local DA with a local address, so the loopback address should
> always be found first when querying your local scope.
>
> If you had a stale DA (no longer responding, but no shutdown message
> received for it) in the cache with the same scope as your local DA, then
> that might explain your (sometimes) getting network error -19, depending
> on the ordering of the cached list when scanned. However, if your local
> daemon is a DA, I wouldn't expect to see this for the reason given above
> (local DA should always be found first). Did you have a chance to
> capture the network traffic when the error occurred ?
>
>
> -----Original Message-----
> *From:* Nick Wagner [mailto:[EMAIL PROTECTED]
> *Sent:* 18 October 2008 01:19
> *To:* Morrell Richard
> *Cc:* openslp-devel@lists.sourceforge.net
> *Subject:* Re: [Openslp-devel] Proposed updates for release 2.0.0
>
> Unfortunately, these changes have broken the Windows build. I took some
> time today to get it compiling again but I'm not sure when I'll really have
> time for testing (which is why I haven't checked it in).
>
> With the new code, I've noticed a slow-down during a slptool findsrvs -- in
> my testing on a machine running a DA, slptool will often return -19 (network
> timed out). When I comment out the new KnownDASapnningListFromCache /
> NetworkMultiUcastRqstRply code, everything goes back to normal. The
> existing NetworkConnectToDA functionality makes use of the fact that slpd
> always returns the loopback address to any local directory agent queries,
> which makes querying very fast. Is there a potential for the new code to
> ignore the loopback even if the scopes match? Otherwise it's something in
> my compile changes, but nothing jumped out as possibly being a culprit.
>
> --Nick
>
>
> On Wed, Oct 1, 2008 at 3:44 AM, Morrell Richard <
> [EMAIL PROTECTED]> wrote:
>
>> Hi John,
>>
>> I've checked our changes into the trunk, and rebuilt and tested the
>> updates.
>> I'm happy that the new code is working as expected (subject to the
>> limitations of our system setup).
>>
>> Regards,
>> Richard
>>
>> -----Original Message-----
>> From: John Calcote [mailto:[EMAIL PROTECTED]
>> Sent: 23 September 2008 17:17
>> To: Morrell Richard
>> Subject: Re: [Openslp-devel] Proposed updates for release 2.0.0
>>
>>
>> Hi Richard,
>>
>> I'll hold off as long as you'd like. I'm really in no hurry. Please
>> check your changes in, and ensure they build on whatever platforms you
>> have available for testing. Keep me posted, and -- as always -- feel
>> free to use me as a sounding board if you wish.
>>
>> Regards,
>> John
>>
>> Morrell Richard wrote:
>> > Hi.
>> >
>> > We've been working on some updates to OpenSLP over the past year or so
>> > for our work here in Thales, using Linux, and we've allocated some
>> > time to feed these back into the project. If possible, we'd like to
>> > get them into the formal 2.0 release, but we realise this is imminent,
>> > so the first question is, when is this likely to occur ? And, are our
>> > updates likely to be accepted for this release ?
>> >
>> > We have the following changes, which we have tested & deployed in
>> > working systems. Note: we only use OpenSLP on Linux with IPv4, and we
>> > don't use SLP security - our testing is limited to this setup.
>> >
>> > 1. "Multi-unicast" (IPv4 only)
>> > The current code will only use unicast if it can find a single DA that
>> > supports all the scopes, otherwise it will use multicast. As our
>> > systems use multiple DAs with distinct scopes, this meant we were
>> > always using multicast convergence. Our update finds a spanning list
>> > of DAs that, together, support all the scopes, and searches all of
>> > them by unicast in parallel. This gives a quicker response than
>> > multicast convergence.
>> >
>> > 2. Stale DAs
>> > Our DAs represent independent processing hardware, and uncontrolled
>> > crashes or network faults leave stale entries in the known DA list
>> > which will always timeout (in unicast searches), reducing
>> > performance. Our update adds an option to the SLP configuration
>> > whereby all DAs can be configured to regularly broadcast their
>> > presence (DA Advert) at a settable rate (dependent on the daemon's
>> > timer), and all DAs & SAs so configured will monitor the broadcasts,
>> > and remove a DA from the list of known DAs if three consecutive
>> > broadcasts are missed. This reduces the number of occasions on which
>> > timeouts occur due to this problem to an acceptable level. As part of
>> > this change, we also had to change the cacheing code in the library to
>> > allow for scopes to disappear.
>> >
>> > 3. Local registrations are aged
>> > This is a bugfix for SA registrations with maximum lifetime - they
>> > were being aged, so we lost our registrations after about 18 hours.
>> > This is a difference between release 1.2.1 and the pre-2.0 code, and
>> > is not desired behaviour for us (all our registrations have maximum
>> > lifetime). We couldn't see a reason for it, so assume it was a bug
>> > rather than a deliberate change.
>> >
>> > 4. Error handling bug
>> > There is a path though the code that can lead to a null pointer
>> > segmentation violation. We only came across this when using jSLP in a
>> > java app, which managed to set the multicast flag in a unicast
>> > request, but it could potentially occur in other error situations.
>> >
>> > 5. Multicast convergence fixes
>> > A minor performance fix to the multicast convergence code - the RFC
>> > says convergence will stop when no replies are received in a
>> > convergence interval, but the code always went to the timeout, so our
>> > update implements this (subject to a minimum of two iterations).
>> > The TCP retry code within a multicast request uses the same timeval
>> > structure as the multicast loop, and thus corrupts the multicast
>> timeout.
>> >
>> > *Richard Morrell*
>> >
>>
>
> 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 SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Openslp-devel mailing list
Openslp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openslp-devel
