[Spread-users] New to spread, some questions

Ryan Caudy rcaudy at gmail.com
Sat Feb 5 22:15:52 EST 2005


I can't speak for any of the other Spread developers.  I don't have a
long to-do list for Spread development these days -- I'm employed
elsewhere full-time, and so I've mostly been concerned with a few
correctness concerns I have.  However, I've put a little bit of
thought into it in the past, simply because it would be nice to have.

I don't think there are any important research issues, if all that's
desired is a simple, insecure protocol that only supports insertions,
and not ordering-changes or deletions.  There are, however, concerns
from a software engineering point of view.

A simple protocol would have membership representatives exchange
configurations when negotiating network merges, and then, provided
that there were no conflicts, install new configurations as part of
the membership protocol.

One potential performance enhancement to the simple protocol is an
exchange of hashes of configuration data, to detect the common case
when a merge only includes daemons with the same configuration.

An audit would need to be done, however, to determine the feasibility
of changes to Spread to support this.  The main concern is that Spread
relies on the immutability of configurations for sanity checks, and
for efficient, deterministic decision making.

Cheers,
Ryan

On Sat, 5 Feb 2005 21:21:41 -0500, Scott Barvick
<sbarvick at revasystems.com> wrote:
> Ryan,
> 
> I've seen the issue of resetting all of the daemons when you want to add a new one come up before.  We are also interested in having this be more dynamic.  Is it on anyone's list to do or any idea of the amout of work it would take to do it?
> 
> Thanks,
> Scott
> 
> 
> -----Original Message-----
> From: spread-users-bounces at lists.spread.org on behalf of Ryan Caudy
> Sent: Thu 2/3/2005 9:59 PM
> To: pedro smith
> Cc: spread-users at lists.spread.org
> Subject: Re: [Spread-users] New to spread, some questions
> 
> You seem to understand this correctly.  The set of spread daemons
> (identified by hostname/ip address) must be known when the daemons are
> started.  The limit of 128 spread daemons (#define'd as
> MAX_PROCS_RING) is fixed at compile-time -- you might be able to make
> some changes to this, but I'm not sure if anyone has done so, and
> there may be complications that I can't think of off the top of my
> head.  As far as I know, there aren't currently plans to change
> Spread's functionality in these respects.
> 
> One thing to consider is that the 128 limit is a limit of the number
> of daemons -- the number of clients is a large multiple of this.
> Also, you can run more than one Spread network on an overlapping set
> of machines -- they simply must use different ports, or different
> multicast/broadcast addresses.
> 
> Cheers,
> Ryan
> 
> On Thu, 3 Feb 2005 18:46:54 -0800 (PST), pedro smith <und_pep at yahoo.com> wrote:
> > Hi there,
> >
> > I just found Spread and I am very interested in learning more about its
> > capabilities. I am considering using something like spread in a financial
> > system. However I am worried about two issues. First, it seems that the list
> > of machines participating in a spread segment must be know at system boot
> > time. Is this right? Would I have to reinitialize every spread daemon in the
> > system to add a new machine? Second, do I understand correctly that there is
> > a hard limit of 128 machines in a spread network? If so, are there any ways
> > around this limit, perhaps by bridging separate networks?
> >
> > Thanks in advance for any help,
> >
> > -pp
> >
> >
> >  ________________________________
> > Do you Yahoo!?
> >  Yahoo! Search presents - Jib Jab's 'Second Term'
> >
> >
> > _______________________________________________
> > Spread-users mailing list
> > Spread-users at lists.spread.org
> > http://lists.spread.org/mailman/listinfo/spread-users
> >
> >
> >
> 
> _______________________________________________
> Spread-users mailing list
> Spread-users at lists.spread.org
> http://lists.spread.org/mailman/listinfo/spread-users
> 
> 
>




More information about the Spread-users mailing list