[Spread-users] Connecting spread daemons with different segment configurations

John Lane Schultz jschultz at spreadconcepts.com
Thu Jan 29 11:55:57 EST 2015


It depends on how you use the dual systems and how the load would be split across them versus a single configuration system.  The best test is to try it out and not assume.

A correction to my earlier emails.  Wherever I said exponential, I actually meant N^2, not exponential.

Cheers!

-----
John Lane Schultz
Spread Concepts LLC
Cell: 443 838 2200

On Jan 29, 2015, at 11:07 AM, Timo Korthals <tkorthals at cit-ec.uni-bielefeld.de> wrote:

Hi John,

in fact, this configuration works.
But as mentioned before, having multiply spread daemons running looks a 
bit overkill to me (or is it common practice?).
Unfortunately, we are not able to use multicast, due to our network setup.

Greetings,
Timo

On 29.01.2015 16:03, John Lane Schultz wrote:
> It depends on what you after but it sounds like you want two different systems: one connecting one-two and another connecting one-three.
> 
> So two’s configuration could look like:
> 
> Spread_Segment  192.168.0.255:5000 {
>         one               192.168.0.1
> }
> Spread_Segment  192.168.0.255:5000 {
>         two               192.168.0.2
> }
> 
> Three’s could look like:
> 
> Spread_Segment  192.168.0.255:6000 {
>         one               192.168.0.1
> }
> Spread_Segment  192.168.0.255:6000 {
>         three               192.168.0.3
> }
> 
> And one could run two different daemons with configurations respectively like:
> 
> Spread_Segment  192.168.0.255:5000 {
>         one               192.168.0.1
> }
> Spread_Segment  192.168.0.255:5000 {
>         two               192.168.0.2
> }
> 
> and
> 
> Spread_Segment  192.168.0.255:6000 {
>         one               192.168.0.1
> }
> Spread_Segment  192.168.0.255:6000 {
>         three               192.168.0.3
> }
> 
> This achieves the effect that both two and three can talk to one (on different Spread systems though), but two and three cannot talk to each other and will not see nor be affected by each other.
> 
> You also might want to consider multicast addresses instead of broadcast addresses if multicast support is available.
> 
> Cheers!
> 
> -----
> John Lane Schultz
> Spread Concepts LLC
> Cell: 443 838 2200
> 
> On Jan 29, 2015, at 5:20 AM, Timo Korthals <tkorthals at cit-ec.uni-bielefeld.de> wrote:
> 
> Dear Spread users,
> 
> we are using spread daemons for our distributed robot network.
> We know already, that each device needs exact the same configuration regarding the segments, otherwise the spread daemons wont connect to each other.
> But is there a way to not have the same segment configurations?
> So lets assume the following scenario of three participants {1,2,3}.
> 
> 1. is a server, which knows the participants 2 and 3
> spreadOne.conf:
> Spread_Segment  192.168.0.255:4803 {
>         one               192.168.0.1
> }
> Spread_Segment  192.168.0.255:4803 {
>         two               192.168.0.2
> }
> Spread_Segment  192.168.0.255:4803 {
>         three               192.168.0.3
> }
> 
> 2. and 3. are just clients, which are allowed to talk with the server, but not with each other
> spreadTwo.conf:
> Spread_Segment  192.168.0.255:4803 {
>         one               192.168.0.1
> }
> Spread_Segment  192.168.0.255:4803 {
>         two               192.168.0.2
> }
> 
> spreadThree.conf:
> Spread_Segment  192.168.0.255:4803 {
>         one               192.168.0.1
> }
> Spread_Segment  192.168.0.255:4803 {
>         three               192.168.0.3
> }
> 
> 
> Obviously this does not work with spread, am I right?
> But if so, how can I make it work?
> Is spread just comparing the hashes of the configs, and refusing connections, if hashes mismatch?
> What happens if I remove the checks regarding the configuration check?
> Has anyone done this before?
> 
> Greetings,
> Timo
> 


_______________________________________________
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