[Spread-users] Connecting spread daemons with different segment configurations
John Lane Schultz
jschultz at spreadconcepts.com
Thu Jan 29 11:46:41 EST 2015
If you want to interconnect lots of machines over a highly unstable network (e.g. - any machine disconnects or reconnects to the network more than once a minute [or faster with lower Spread membership timeouts]), then the membership and message delivery semantics Spread tries to provide may be too strong for what you want.
In particular, when Spread is reforming its membership, it has to stall the system for a period of time to close out its previous membership(s) while meeting its stringent semantics. Such pausing may make the system impractical for such an unstable environment.
Cheers!
-----
John Lane Schultz
Spread Concepts LLC
Cell: 443 838 2200
On Jan 29, 2015, at 11:02 AM, Timo Korthals <tkorthals at cit-ec.uni-bielefeld.de> wrote:
Hi Yair, hi Ed,
this membership setup seems nice.
But Yair, what du you mean with "relatively" stable?
In fact, we have a high unstable wifi network, so it seems to me that
membershipping is not a good solution?
Greetings,
Timo
On 29.01.2015 13:54, Yair Amir wrote:
> Good point Ed.
>
> What I propose has an advantage still if we are highly interested to avoid
> connectivity effects of server 2 from affecting server 3
> in the case of a flaky wireless network where server 2 and server 3 frequently disconnect from the network.
>
> If the network if relatively stable, the solution you propose of just using different groups
> with a single configuration of all three daemons is better of course and I stay corrected.
>
> Best,
>
> :) Yair.
>
> On 1/29/15 7:44 AM, Ed Holyat wrote:
>> Seems to me you're trying to segment the network through daemon configuration when you should me segmenting the network through group membership
>>
>>
>>> On Jan 29, 2015, at 7:40 AM, Yair Amir <yairamir at cs.jhu.edu> wrote:
>>>
>>> I am not sure what you are trying to achieve.
>>> But if clients on 2 are not allowed to talk with clients on 3,
>>> then perhaps what you are after can be solved with 2 Spread configurations
>>> with 2 different daemons running on server 1 (on two different ports).
>>>
>>> This way, clients on server 1 can just connect to the 2 daemons on server 1
>>> and join the same groups on both.
>>>
>>> Clients on each of server 2 and server 3 will connect to their local
>>> daemon and then will never be able to see clients on the other server (of 2 and 3).
>>>
>>> How about that?
>>>
>>> :) Yair.
>>>
>>>
>>>
>>>> On 1/29/15 7:25 AM, Timo Korthals wrote:
>>>> Hi Yair,
>>>>
>>>> thanks for the answer, but I think that your case does not meet my
>>>> requirements if I understand your setup in the right way.
>>>> If there is just one daemon on 1. running, the spread clients on 2. and
>>>> 3. are able to talk to each other.
>>>> The other point why I want to use this multi daemon setup, is that the
>>>> daemons on 2. and 3. can handle the breakaway of the connection in a
>>>> wifi scenario with bad quality.
>>>> In your case the clients needs to handle faulty connections on their own.
>>>>
>>>> Kind regards,
>>>> Timo
>>>>
>>>>
>>>> Timo Korthals, M.Sc.
>>>> Universität Bielefeld
>>>> AG Kognitronik & Sensorik
>>>> Exzellenzcluster Cognitive Interaction Technology (CITEC)
>>>> Inspiration 1 (Zehlendorfer Damm 199)
>>>> 33619 Bielefeld - Germany
>>>>
>>>> Office : 3.037
>>>> Phone : +49 521 106-67368
>>>> eMail : tkorthals at cit-ec.uni-bielefeld.de
>>>> Internet: http://www.ks.cit-ec.uni-bielefeld.de/
>>>>
>>>>> On 29.01.2015 13:06, Yair Amir wrote:
>>>>> Dear Timo,
>>>>>
>>>>> To implement your scenario, what you want is to just have a single
>>>>> Spread daemon in your
>>>>> configuration - just have server 1.
>>>>>
>>>>> The other two should just connect as clients. This seems exactly what
>>>>> you want.
>>>>>
>>>>> Let me know if you think I misunderstood something.
>>>>>
>>>>> Best,
>>>>>
>>>>> :) Yair.
>>>>>
>>>>>> On 1/29/15 5:20 AM, Timo Korthals 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
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Timo Korthals, M.Sc.
>>>>>> Universität Bielefeld
>>>>>> AG Kognitronik & Sensorik
>>>>>> Exzellenzcluster Cognitive Interaction Technology (CITEC)
>>>>>> Inspiration 1 (Zehlendorfer Damm 199)
>>>>>> 33619 Bielefeld - Germany
>>>>>>
>>>>>> Office : 3.037
>>>>>> Phone : +49 521 106-67368
>>>>>> eMail :tkorthals at cit-ec.uni-bielefeld.de
>>>>>> Internet:http://www.ks.cit-ec.uni-bielefeld.de/
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Spread-users mailing list
>>>>>> Spread-users at lists.spread.org
>>>>>> http://lists.spread.org/mailman/listinfo/spread-users
>>>>
>>>> _______________________________________________
>>>> Spread-users mailing list
>>>> Spread-users at lists.spread.org
>>>> http://lists.spread.org/mailman/listinfo/spread-users
>>> _______________________________________________
>>> Spread-users mailing list
>>> Spread-users at lists.spread.org
>>> http://lists.spread.org/mailman/listinfo/spread-users
>> _______________________________________________
>> Spread-users mailing list
>> Spread-users at lists.spread.org
>> http://lists.spread.org/mailman/listinfo/spread-users
>>
> _______________________________________________
> Spread-users mailing list
> Spread-users at lists.spread.org
> http://lists.spread.org/mailman/listinfo/spread-users
_______________________________________________
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