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 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
