[Spread-users] New to spread and got some problems

John Lane Schultz jschultz at spreadconcepts.com
Thu Jan 29 11:46:13 EST 2009

Hi Tobias,

When node $x in segment $y sends a "Spread broadcast" it will first send a UDP point-to-point packet to the leaders of each of the other segments (who will then locally broad/multicast it within their segment) and then if it needs to broad/multicast within its segment it will do that too.

I would recommend that you use multicast addresses instead of broadcast addresses for your segments wherever it is available.  Broadcast incurs CPU and switch bandwidth overhead on all machines / ports within the subnet whereas multicast can only use CPU and bandwidth on the machines / ports that have joined that IP multicast group.

If you can multicast between your two datacenters, then you should put them all in the same segment.  If you can't multicast to all of them, then your .conf looks good (except you should use multicast within segments instead of broadcast).

Make sure though that every daemon can send point-to-point traffic directly to every other daemon (i.e. - two distinct private (NAT'ed) networks usually can't work well together using Spread w/o some kind of tunnelling or default routing).


John Lane Schultz
Spread Concepts LLC
Phn: 443 838 2200 
Fax: 301 560 8875

Thursday, January 29, 2009, 10:48:25 AM, you wrote:

> Out of interest, what sort of network traffic would you expect if you
> have two segments, eg:

> Spread_Segment {
>   node1
>   node2
>   node3
> }

> Spread_Segment {
>   node4
>   node5
>   node6
> }

> Would node1 broadcasting a message send packets to and
> or all of,, &
> (*)?

> I have two clusters of machines in different datacentres (<10ms) and
> currently don't link them together with spread. What level of
> unnecessary extra traffic would I see between them if I configured the
> machines in this way? If there is going to always be additional traffic,
> I'll have to look at setting up a GRE tunnel for some specific multicast
> traffic.

> -jeremy

> (*) Of course, I appreciate the real way of finding out would actually
> be 1) Read the code, 2) Try it out on unsuspecting hosts...

> _______________________________________________
> 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