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

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.

-- 
Bela Ban
Lead JGroups / Clustering Team
JBoss

------------------------------------------------------------------------------
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