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

   _____  

                 Software Architecture & Technologies 


Tel:

+ 44 (0)161 741 3426 


Email:

[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> 


Intranet:

Website <http://uwsweb.tus.fr.thales/functions/operations/SAT/index.stm>  :
Products <http://satweb.tus.uk.thales/products.php>  : Helpdesk
<http://sat-helpdesk.tus.fr.thales/> 

THALES UNDERWATER SYSTEMS LTD 
Dolphin House, Ashurst Drive
Cheadle Heath, Stockport SK3 OXB - UK 
 <http://www.thales-naval.com/> www.thales-naval.com

                 Thales Underwater Systems Limited. Registered in England
and Wales. Registered number 3084140. 
Registered office 2 Dashwood Lang Road, The Bourne Business Park,
Addlestone, Nr. Weybridge, Surrey KT15 2NX      
 

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

Reply via email to