[Spread-users] Spread 3.17.2 release

Jonathan Stanton jonathan at cnds.jhu.edu
Wed Apr 14 15:53:39 EDT 2004


Hi everyone,

Spread Concepts LLC and Johns Hopkins Center for Networking and Distributed
System are happy to announce the release of a new stable version, 3.17.2,
of the Spread toolkit. 

You can download the release from http://www.spread.org/

This release includes a number of bugfixes, including some that fix
daemon crashes, a decrease in message token overhead, and some small cleanups 
and stability improvements. So we highly encourage everyone to 
upgrade to this release. 

The 3.17.2 release has no new features or external api changes.

One thing to note is the parsing of the spread.conf file has become more strict, 
and some config files that would parse without error will now cause Spread to 
fail to start and report a configuration file error. Since all of these cases 
could cause the daemon to misbehave or crash at runtime (but not at startup) 
this change increases stability by checking for misconfigured setups before they 
cause unpredictable behavior.

The list of bugfixes is:

1) Fix daemon quit when multiple interfaces are configured as "D" daemon 
   interfaces in the spread.conf file. Bug reported by Orit Wasserman.
2) Updated url for Java 'ant' build system. Patch by Daniel Rall.
3) Fix group_id bug that causes incorrect vs_sets. Patch by Ryan Caudy.
4) Fix spread.conf parser so it validates the machine names in segments
   and forces them to be less then MAX_PROC_NAME. Patch by Mikhail Terekhov.
5) Minor fix to Mac OS X compilation so library softlinks do not fail the 
   second time make is run.
6) Alarm() changes to support priority levels on each Alarm() call. 
7) Fix crash by improving packet accounting when a client connected to a 
   singleton daemon sends a large broadcast. Reported by David Shaw.
8) Fix bus errors on Sparc & Alpha for message buffer integer assignment. 
   Reported by Greg Shebert; tested and patched Mikhail Terekhov.
9) Verify daemon names in spread.conf are unique. If non-unique names are
   provided in spread.conf, configuration will be rejected and daemon will 
   not start. Suggested by Tim Peters. 
10) Zero buffer in c library before sending multicast. 
    Reported by Panagiotis Kougiouris. 
11) Send fewer lookup probe messages when only a single segment is configured.
12) Remove extra token rotations when no messages are sent. Will decrease
    network packet overhead. 
13) Make mailbox and service in sp.h a typedef instead of a #define. Suggested
    and patched by Steven Dake. 
14) Fix small endianness error in sp.c where the mess_type field may not be
    correctly converted for different endian platforms when the SP_*_recv calls
    return a BUFFER_TOO_SHORT or GROUPS_TOO_SHORT error.
15) Change alarm tag for security prints from SEC to SECURITY because of conflict
    with sys/time.h header.
16) Documentation fix to SP_receive man page to correct fields for self-leave
    membership messages.
17) Update of email addresses in copyright statements and headers.
18) Windows binary libraries are now built as libspread and libtspread like
    other platforms.

Spread is a toolkit that provides a high performance messaging service 
that is resilient to faults across external or internal networks. Spread 
functions as a unified message bus for distributed applications, and 
provides highly tuned application-level multicast and group communication 
support. Spread services range from reliable message passing to fully 
ordered messages with delivery guarantees, even in case of computer 
failures and network partitions.

Spread is designed to encapsulate the challenging aspects of asynchronous 
networks and enable the construction of scalable distributed applications, 
allowing application builders to focus on the differentiating components 
of their application.

With the Spread Open Source License, the toolkit may be freely 
used under some conditions.  For example, the license includes the 
requirement that all advertising materials (including web pages) 
mentioning software that uses Spread display a specific acknowledgement. 
Please review the license agreement for more details.
http://www.spread.org/license/

Other commercial licenses or other licensing arrangements are available. 
Please contact michal at spreadconcepts.com. We are looking for partners 
interested in using group communication and/or replication to solve 
demanding, real-world problems.

-- 
-------------------------------------------------------
Jonathan R. Stanton         jonathan at cs.jhu.edu
Dept. of Computer Science   
Johns Hopkins University    
-------------------------------------------------------




More information about the Spread-users mailing list