[Spread-users] connect to client in group
jesus at omniti.com
Fri Feb 22 08:37:28 EST 2008
On Feb 22, 2008, at 8:03 AM, Andrew Holt wrote:
> Thank you for the suggestions.
> If a client joins group logger as logger the other(s) detect this
> and re-connect as the random ids.
You don't join groups "as someone." you just join as "you." Spread
has open group semantics, so you can publish to the logger group
without being a member.
1. A2 joins "logger_ctl" and sees he is only member, he joins "logger"
2. C1 sends -> "logger" -> A2 -> recvs
3. A1 joins "logger_ctl" and sees he is the leader, he joins "logger"
4. C2 sends -> "logger" -> A2 -> recvs
5. A2 and A1 notice A1's join of "logger", A2 leaves "logger"
6. C1 sends -> "logger" -> A1 -> recvs
This accomplishes the paradigm you described. There is an opportunity
for loss here. There is time between when A1 starts to join "logger"
and when he successfully joins it. In the above example, that is step
4 and A2 continues to recv log messages and journal them during that
window. However, if A2 crashes while he is the leader, all messages
to logger will be lost between his crash notice (leaving of
"logger_ctl") and the next leader's successful join of "logger"). If
this is what you expect -- then fine.
Like I said before. Ideally, all A's are in the logger group and recv
log messages and you simply use the most recent membership message
received to determine how's the master. (using AGREED messages) and
assuming you always have more than two participants you ensure no
messages are dropped.
> Thanks again,
> On 22 Feb 2008, at 12:55, Theo Schlossnagle wrote:
>> Since you are doing a cooperative setup, you are already prone to
>> being "messed with" by nodes that join (I can join as logger and do
>> Groups are ordered by Spread. Everyone sees the group membership
>> in the same order, so you can count on that to electing leader.
>> have all members join group "logger_ctl"
>> On each membership change, if leader will join the "logger" group,
>> On membership changes in the "logger" group, if you are not the
>> leader of the "logger_ctl" group, leave the "logger" group.
>> This isn't ideal, but is a workable implementation of what you
>> describe below.
>> You should just join a group call logger, have all member receive
>> all messages and log the messages if you are the leader. This
>> method doesn't drop logs between the membership change that the
>> success of the join of "logger" that the first method does.
>> On Feb 22, 2008, at 7:18 AM, Andrew Holt wrote:
>>> I wonder if this is possible, or easily implemented, first let me
>>> set the scene:
>>> I have a logging client running on machine A. It joins the group
>>> (imaginatively named) logger, with a random (e.g.tmp_1234)
>>> connection name.
>>> It looks at the membership list and if there is no other client
>>> named logger it reconnects as logger.
>>> A second client, running on machine B. joins , finds there is
>>> already a logger running and stays connected using it's random name.
>>> If the first client disconnects, or the machine hosting it dies,
>>> the second gets the message and re-connects as logger.
>>> This gives me a simple fail-over mechanism.
>>> Now to the question.
>>> I want to be able to send a message to the client logger in the
>>> group logger irrespective of the machine that its is connecting
>>> So instead of #logger#machinea something like #logger#logger.
>>> Any suggestions ?
>>> Spread-users mailing list
>>> Spread-users at lists.spread.org
>> Theo Schlossnagle
>> OmniTI Computer Consulting, Inc.
>> W: http://omniti.com
>> P: +1.443.325.1357 x201
>> F: +1.410.872.4911
OmniTI Computer Consulting, Inc.
P: +1.443.325.1357 x201
More information about the Spread-users