[Spread-users] Spread on the wide area response

[Yair Amir]

Hi,

Not that I advocate the Spread open source version for scalable wide
area group communication, but I would mention that recent experiments
by BBN with the open source version over six sites ranging from Hawaii in the
west to Virginia and Massachusetts in the east, reported successful
operation of the system (actually that was even for Secure Spread).

It really depends on how many wide area sites you need, what kind
of traffic you have, and the quality of the network.

We did not see a common large need for scalable wide area group
communication, at least not yet. The few that are interested in that
capability today are usually interested in more than a tar download,
and are able to pay - they usually contact Spread Concepts.

We are also interested in knowing about these problem domains and,
unfortunately, the only way for that to happen is by not releasing
that version as open source. With thousands of downloads for the open
source version (over 5000), we get very little feedback from people that
use it.

If you have a specific interesting need for scalable wide area capability
and doing this for an interesting cause - e-mail us. We are happy to
work with such people when we can and provide free licenses when it is
appropriate.

            Cheers,

            :) Yair.  http://www.cs.jhu.edu/~yairamir
            
Joshua> On Tue, Mar 04, 2003 at 05:29:11PM -0800, Michael Fair wrote:
>> I'm new to Spread so please forgive my ignorance.
>> 
>> I'm interested in using Spread as the backbone of
>> an IRC server network (perhaps even extending it
>> to clients).

Joshua> The open-licensed version of Spread won't perform too well in this
Joshua> scenario, because it doesn't include the wide-area communication
Joshua> protocol AFAIK; I doubt that the broadcast protocol will be adequate
Joshua> over multicast tunnels, unless your IRC network is very closely
Joshua> coupled and using untunneled multicast.

Joshua> The IRC server protocol itself tries to form a nondirected acyclic
Joshua> graph over a mesh of possible connections, and the message transport
Joshua> is then a pruned flood-fill over this graph.  This will not sit
Joshua> well with Spread; I have in the past considered writing an adapter
Joshua> daemon that speaks both IRC and some reliable, multipath meshed
Joshua> multicast protocol, to act as a proxy for the IRC server.

Joshua> Ordering is not an issue in IRC, which reduces actual need to that
Joshua> of a meshable, reliable multicast transport that can cope with
Joshua> ad-hoc changes in wide-area architecture without restart.

Joshua> Spread (at least, the open-source Spread) seems to me a poor fit
Joshua> for those requirements, or I'd have already done this.  In fact
Joshua> these requirements are closer to the problem of reliable multicast
Joshua> in a wireless environment.  There are many such experimental
Joshua> protocols: CAMP, AMRis, AMRoute, ODMRP, GAMER, MAODV come to mind;
Joshua> they are time-consuming to evaluate.

Joshua> I suspect that the military have an interest in ad-hoc battlefield
Joshua> group communication that will keep research in this direction
Joshua> well-funded.


>> Has SASL been considered for use as the authentication
>> and security communication layer between Spread clients
>> and Servers?

Joshua> One could embed it in the protocol.  I have a rough decode
Joshua> of the binary client-server protocol at
Joshua> http://www.roughtrade.net/spread/spread-client-proto.txt

>> I also thought that if SASL could be incorporated
>> into the server, then a more dynamic configuration
>> could be made possible by having Spread daemons
>> authenticate themselves to each other and request
>> inclusion into the network (this would of course be
>> bi-directional to ensure no one is taking advantage
>> of the opportunity to present a "man in the middle"
>> attack during a net partition).

Joshua> The Spread interdaemon protocol is not connection-based,
Joshua> which would make SASL a hard call.  Have you looked at
Joshua> Secure/Flush Spread, which could give you relatively
Joshua> strong levels of encryption and membership?

Joshua> Joshua.