[Spread-users] Spread 3.17.2 release
jonathan at cnds.jhu.edu
Wed Apr 14 15:53:39 EDT 2004
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
17) Update of email addresses in copyright statements and headers.
18) Windows binary libraries are now built as libspread and libtspread like
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.
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