<div> </div>
<div>This broadcast-to-all-daemons behavior does seem a significant performance overhead specially when we we consider multiple hosts exchanging large multi-MB messages. </div>
<div> </div>
<div>I am wondering if implementing send-side-filtering is a hard problem to solve. Sounds like you'd need to track 'group membership to host mapping' in some sort of local datastructure and filter messages based on that.
</div>
<div> </div>
<div>Anyways, I appreciate your response. I will keep the suggestions in mind. </div>
<div> </div>
<div>Thanks,</div>
<div> </div>
<div>Sami<br><br> </div>
<div><span class="gmail_quote">On 4/2/07, <b class="gmail_sendername">John Lane Schultz</b> <<a href="mailto:jschultz@spreadconcepts.com">jschultz@spreadconcepts.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">My email got marked as [SPAM IP_REPEAT] somehow, I just wanted to make sure you<br>got my response.<br><br>
Cheers!<br><br>-------- Original Message --------<br>Subject: Re: [Spread-users] is spread the right choice ?<br>Date: Mon, 02 Apr 2007 12:07:19 -0400<br>From: John Lane Schultz <<a href="mailto:jschultz@spreadconcepts.com">
jschultz@spreadconcepts.com</a>><br>To: <a href="mailto:spread-users@lists.spread.org">spread-users@lists.spread.org</a><br>References: <<a href="mailto:c5eaea180703310232h213f386bk9831047f56a4663@mail.gmail.com">c5eaea180703310232h213f386bk9831047f56a4663@mail.gmail.com
</a>><br><br>Spread's design is optimized for *groups* of processes to communicate, thus the<br>name "group communication." It can certainly be used for 2 party communication<br>as well, but 2 party communication can incur unexpected overhead.
<br><br>For example, currently all data traffic is sent to and processed by *all* Spread<br>daemons. This communication pattern can cause unexpected network overhead.<br>Within a segment (LAN), all data traffic is broad/multicast to all the daemons
<br>in that segment. This can incur a lot more traffic overhead than point to point<br>traffic because your switch/router/hub has to put the traffic on every<br>(interested) port. If you have multiple segments, then Spread also sends the
<br>data to the leader of each segment (i.e. - n segments usually causes n-1<br>unicasts and 1 broad/multicast per sp_multicast, ignoring packing). So, if you<br>have two applications communicating with each other, even through the same
<br>daemon, then their conversation is actually sent to and processed by *all* the<br>daemons -- all the other daemons simply drop the data on the floor after<br>extracting the necessary meta-data. Spread could be optimized to better handle
<br>daemon interest in data (i.e. - send side filtering), but that has not yet been<br>done.<br><br>On the flip side, Spread provides a pretty simple API for message passing and<br>provides powerful ordering and reliability semantics for n-party communication,
<br>all of which can ease development of distributed applications.<br><br>I can't make the call for you, but if you really are only doing point to point<br>communication and don't expect to go to n-party communication, then the good old
<br>BSD socket client-server interface, along with select, might be your best bet.<br><br>Cheers!<br><br>Sami M wrote:<br>> OK Folks. Maybe I am on the wrong track here. We need a message passing<br>> library.<br>>
<br>> It's for a large distributed application that needs to scale on a linux<br>> cluster with possibly tens of nodes and 7/8 different type of processes<br>> [don't ask... we might be building the next google :)]. Different
<br>> processes running on seperate (or same) machines need to<br>> communicate. There is currently no need for multicast messages<br>> although any process may exchange a message with any other process<br>> (n-way connectivity). Doing that point-to-point would be overly complex
<br>> I think !?!? They need to be able to send messages that may go upwards<br>> of 100M. There is a need for java/c inter-operability as some processes<br>> are in java.<br>><br>> I have tried mpich2 & pvm so far & those libs proved to be not well
<br>> suited for this application for various reasons. Spread seemed well<br>> suited initially but has its own set of constrants with regards to<br>> message sizes & flow control. So far I have implemented message chunking
<br>> to overcome the 100K limit. It seems I will need a fix for this flow<br>> control issue.<br>><br>> Is spread the right choice for this kindof application with regards to<br>> scalability, performance, and feature requirements here. I'd prefer
<br>> using an off the shelf solution for this. What other open and/or<br>> commercial libs can I try? I am using a wrapper interface to message<br>> passing lib so I can try different solutions relatively easily.
<br>><br>> BTW... I am not a comm expert so bear with me if I am missing anything<br>> obvious. Please feel free to weight in. Any help here is appreciated.<br>><br>> Thanks,<br>><br>> Sami<br>><br>
><br>> ------------------------------------------------------------------------<br>><br>> _______________________________________________<br>> Spread-users mailing list<br>> <a href="mailto:Spread-users@lists.spread.org">
Spread-users@lists.spread.org</a><br>> <a href="http://lists.spread.org/mailman/listinfo/spread-users">http://lists.spread.org/mailman/listinfo/spread-users</a><br><br><br>--<br>John Schultz<br>Spread Concepts LLC<br>Phn: 443 838 2200
<br>Fax: 301 560 8875<br></blockquote></div><br>