[Spread-users] Spread Configuration

[John Lane Schultz]

Wangbong Lee wrote:
> Thanks for your reply. 
> 
> Here is sample configuration with 3 nodes(A,B,C) in same network domain (not
> through router).
> With your comments, as I understood, possible one configuration is;
> A "local" daemon and a "remote" daemon can run node A, and a "local" daemon
> can run each B and C. 

I assume you mean (A,B,C) are machines that are in the same network domain (e.g. 
- a LAN).  In a typical deployment of Spread, you usually only run a single 
daemon on each physical machine.

Client processes connect to these daemons to get Spread's services.  How a 
client connects to its Spread daemon defines whether or not that client-daemon 
*connection* is "local" or "remote."  Speaking of a "local daemon" or a "remote 
daemon" only makes sense in the context of some particular client -- is the 
client process on the same (local) or a different (remote) machine as the Spread 
daemon?

 > In your comments, the daemons in each nodes can communicate each other. I
 > wonder, what information
 > is delivered among them?

The daemons have their own control traffic, but their primary purpose is to 
deliver user generated messages to the appropriate client processes.  The 
daemons also report group membership information to clients in response to 
asynchronous changes (e.g. - network partitions/heals, a client 
joins/leaves/crashes, etc.).

> Other question is about "no network bandwidth is consumed in local
> communication".  
> In your words, if the client's connection is local, then the client-daemon
> communication remains
>  within the machine -- no network bandwidth is consumed. However, when I
> tested local messaging 
> within the machine, those messages are out to physical interface. (I
> tcpdumped those packets.)
> Thus, meaning of "no network bandwidth is consumed" is not clear.  Could you
> tell me about that more?
> 

How you connect to your daemon and your OS determines how the client-daemon 
communication works.  When a client calls SP_connect, it passes a daemon 
connection string either of the form "<daemon_port>" (e.g. - "4803") or 
"<daemon_port>@<host_name>" (e.g. - "4803 at www.spreadconcepts.com").

If your client and daemon are both running on the same Unix / Linux / etc. 
machine, then if you simply specify the Spread daemon's port (e.g. - "4803"), 
then the client-daemon communication will use pipes, a form of Unix Inter 
Process Communication (IPC), that consumes no network bandwidth.

In the same scenario, if you used the host_name form instead (e.g. - 
"4803 at localhost"), then the communication will use TCP/IP, which has higher 
overhead.  However, I would expect that such a connection's traffic would not 
actually go out onto the network.  The connection should be recognized as local 
within the machine's TCP/IP stack and contained within platform.  Therefore, it 
*should* consume no network bandwidth if the OS is smart.

Obviously, if your client and deamon are not on the same machine, then you must 
use the host_name form and your communication will consume network bandwidth.

On windows, clients must use the host_name form and TCP/IP is the only available 
client-daemon communication type.  Again though, if they are on the same 
physical machine, then I would expect the communication to be contained within 
the machine.

I strongly recommend that you read Spread's provided documentation, which 
explains many of these concepts and their particulars:

http://www.spread.org/docspread.html

Cheers!

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