Re: [jgroups-dev] Question about recent RELAY commit in CVS

<snip>
> That way if the coordinator changed, it would not
> cause a view change on the remote group. And instead we could keep
> communicating with the same member that represents this relay.
 > Not sure I understand, can you elaborate more ?

It may not be a valid recommendation if your planning on having both 
clusters be seen as one large group.  This was with the thoughts that 
you were closer to done than I realized.  Basically the idea was just to 
allow communications to a remote cluster, without caring who the 
coordinator was.  I had mentioned earlier that the remote coordinator 
should be listed in the view of both sides (so that messages can be sent 
specifically to the remote cluster).  What I was trying to say here, was 
a further improvement on that idea.  Instead of listing the coordinator 
in the view, just list a generic remote relay node.  That way if the 
coordinator changes, you can still send messages to this psedo node.  
The closest analogy I can think of would be a symbolic link on a file 
system.  This node would be a symbolic link, and it would point to who 
ever was acting as the relay coordinator at the time for the remote 
cluster.

But again, if the end goal is to merge the views into one large cluster, 
I don't know if there is any benefit in this.

Bela Ban wrote:
>
>
> Mike Jensen wrote:
>> I was looking at the relay implementation. I am curious about some of 
>> the ideas being it.
>
> Ha ha, you detected it ! :-)
>
> I haven't publicised it yet, because this is just an experimental 
> implementation of a relaying messages between networks, that could 
> serve as basis for failover between data centers.
>
> In this prototype, I'm implementing step #1, which is simply relaying 
> multicast messages (dest=null) between 2 *independent* clusters. When 
> we have clusters {A,B,C} and {X,Y,Z}, and B multicasts a message m1, 
> then it will get multicast to A,B,C.
>
> Since A is the coordinator of {A,B,C, it'll also join a cluster 
> "bridge-cluster", possibly over TCP, which X (as coord of {X,Y,Z} also 
> joins.
>
> When A receives m1, it'll also forward it over the bridge cluster, so 
> X receives it. X now multicasts m1 on its own cluster as well, 
> however, the sender will be X, *not* B !
>
> Therefore, there is no way that a receipient of m1 can send back a 
> response to the *original* sender of m1 (B), but a response would be 
> sent to X, which is useless.
>
> So step #1 implements simple multicast relaying, but I'm not done yet. 
> I've been side tracked with improvements to flow control (FC), but 
> I'll get back to RELAY next week...
>
>
> In step #2, I'll look at how we could implement one large virtual 
> cluster, consisting of subclusters {A,B,C} and {X,Y,Z}. I still want 
> to have 2 separate and *independent* clusters, so flow control and 
> stability don't have to span the 2 clusters, but convey the illusion 
> of 1 large virtual cluster to developers.
>
> Step #2 should allow for communication between subclusters, e.g. B 
> multicasting m1 and Y replying to it. The idea I have for this is 
> similar to NATs: keep a NAT-like table and convert incoming and 
> outgoing addresses to addresses 'known' to the other subcluster.
>
> I also want to provide membership that's consistent across both 
> subclusters.
>
> This requires more thought though...
>
> Comments inline
>
>> So as currently implemented, would the only messages that get sent
>> between two relay's are messages that have been broadcast to the entire
>> group?
>
> Yes
>
>> Is there any way to send a message directly to the remote relay node?
>
> No, not yet (see above)
>
>> I am not sure how realistic this is with the current group management
>> but, a possible solution I see is:
>> In groups {A, B, C} and {X, Y, Z} where A and X are the
>> coordinators....we could include A in the X, Y, Z membership (hopefully
>> with some flag to indicate that it is a relay?). And include X in {A,
>> B, C}....That is the simplest way I can see to do it.
>
> Yes, this is similar to what I have in mind (plus the NAT translation 
> tables).
>
>> But a better solution IMO would be to have the relay link be a group 
>> member in itself. 
>
> It is already a member (A). So the coordinator which acts as relay is 
> a member of 2 clusters: the local one and the bridge cluster.
>
>
>> That way if the coordinator changed, it would not
>> cause a view change on the remote group. And instead we could keep
>> communicating with the same member that represents this relay.
>
> Not sure I understand, can you elaborate more ?
>
>> Either way it is implemented in the view, I kind of think that there
>> still needs to be some sort of change to the message your sending the
>> relay node. Meaning, so you have directed a message to a remote group,
>> now what does it do when it arrives? I think there should be a flag to
>> indicate if the message is intended for just the relay node
>> (coordinator), or if this message should then be sent to all remote
>> group members.
>
> Currently a multicast message received over the bridge cluster will 
> get multicast again in the local cluster. A header tucked onto the 
> relayed message prevents it getting relayed again (circles).
>
>> Of course, if the message only arrived at the relay
>> node, it _could_ be the application layers responsibility to handle if
>> this should be broadcast to all other group members or not. But I think
>> it is more eloquent to put it in the JGroups level.
>
> I consider the decision as to whether to relay or not one made at the 
> relay node. So, if A receives a multicast, it is up to A to decide 
> whether to relay or not. This could be done via property files, 
> programmatically, and so on.
>


------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Javagroups-development mailing list