CVS update: JGroups/doc/design RELAY.fig RELAY.txt RELAY.png

  User: belaban 
  Date: 10/11/08 14:04:36

  Modified:    doc/design RELAY.fig RELAY.txt RELAY.png
  Log:
  new design
  
  Revision  Changes    Path
  1.2       +3 -1      JGroups/doc/design/RELAY.fig
  
  Index: RELAY.fig
  ===================================================================
  RCS file: /cvsroot/javagroups/JGroups/doc/design/RELAY.fig,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- RELAY.fig	8 Nov 2010 12:02:45 -0000	1.1
  +++ RELAY.fig	8 Nov 2010 14:04:36 -0000	1.2
  @@ -62,7 +62,7 @@
   	1 1 4.00 60.00 120.00
   	 5475 5175 7425 5175
   2 4 0 3 0 7 50 -1 -1 0.000 0 0 7 0 0 5
  -	 9450 2775 3525 2775 3525 1800 9450 1800 9450 2775
  +	 9525 2925 3600 2925 3600 1950 9525 1950 9525 2925
   4 0 0 50 -1 18 18 0.0000 4 225 2445 1800 600 Data Center NYC\001
   4 0 0 50 -1 18 18 0.0000 4 225 2415 8775 525 Data Center SFO\001
   4 0 0 50 -1 16 16 0.0000 4 195 990 7350 9300 Network\001
  @@ -70,3 +70,5 @@
   4 0 0 50 -1 16 16 0.0000 4 240 1320 4875 3900 Application\001
   4 0 0 50 -1 16 16 0.0000 4 210 360 6300 2325 tcp\001
   4 0 0 50 -1 16 16 0.0000 4 240 450 9750 4050 udp\001
  +4 0 0 50 -1 2 18 0.0000 4 195 225 3975 2850 X\001
  +4 0 0 50 -1 2 18 0.0000 4 195 225 8925 2850 Y\001
  
  
  
  1.2       +32 -16    JGroups/doc/design/RELAY.txt
  
  Index: RELAY.txt
  ===================================================================
  RCS file: /cvsroot/javagroups/JGroups/doc/design/RELAY.txt,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- RELAY.txt	8 Nov 2010 12:02:45 -0000	1.1
  +++ RELAY.txt	8 Nov 2010 14:04:36 -0000	1.2
  @@ -3,7 +3,7 @@
   ========================================
   
   Author: Bela Ban
  -Version: $Id: RELAY.txt,v 1.1 2010/11/08 12:02:45 belaban Exp $
  +Version: $Id: RELAY.txt,v 1.2 2010/11/08 14:04:36 belaban Exp $
   
   This is an enhanced version of DataCenterReplication.txt with the ability to send unicast messages and to provide views
   to the application, which list members of all local clusters.
  @@ -23,7 +23,7 @@
   TCP based stack, see figure RELAY.png.
   
   There is a local cluster, based on UDP, at each site and one global cluster, based on TCP, which connects the
  -two sites. Each coordinator of the local cluster is also a member of the global cluster, e.g. member E in NYC
  +two sites. Each coordinator of the local cluster is also a member of the global cluster, e.g. member A in NYC
   (assuming it is the coordinator) is also member X of the TCP cluster. This is called a *relay* member. A relay
   member is always member of the local and global cluster.
   
  @@ -31,12 +31,14 @@
   of the figure). RELAY has a JChannel which connects to the TCP group, but *only* when it is (or becomes) coordinator
   of the local cluster. The configuration of the TCP channel is done via a property in RELAY.
   
  -Any *multicast* message (we don't relay unicast messages) that is received by RELAY traveling
  -up the stack is sent via the TCP channel to the other site. When received there, the corresponding RELAY
  -protocol changes the destination of the message to null (those are multicast messages after all) and leaves
  -the src (which might point to X if sent from NYC), then it sends the message down the stack, where it will get
  -multicast to all members of the local cluster (including the sender). When a response is received which
  -points to any non-local address (e.g. X), RELAY simply drops it.
  +A multicast message received by RELAY traveling up the stack is wrapped and sent via the TCP channel to the
  +other site. When received there, the corresponding RELAY protocol unwraps the original message and changes the sender
  +of the message to a ProxyUUID, which wraps the original sender and the local sender.
  +
  +A ProxyUUID extends UUID and behaves like a normal UUID, but it also contains the original sender.
  +
  +A unicast message received by RELAY traveling down the stack is forwarded to the current relay if the destination is
  +a ProxyUUID. The relay will then wrap the message and forward it to the other site via TCP.
   
   When forwarding a message to the local cluster, RELAY adds a header. When it receives the multicast message it
   forwarded itself, and a header is present, it does *not* relay it back to the other site but simply drops it.
  @@ -61,16 +63,30 @@
   
   Example walkthrough
   -------------------
  -- C (in the NYC cluster, with coordinator E) multicasts a message
  -- A, B, C, D and E receive the multicast
  -- D (second-in-line) buffer the message (bounded buffer)
  -- E is the relay. The byte buffer is extracted and a new message M is created. M's source is C, the dest is null
  +
  +Multicasting a message:
  +
  +- C (in the NYC cluster, with coordinator A) multicasts a message
  +- A, B and C receive the multicast
  +- A is the relay. The byte buffer is extracted and a new message M is created. M's source is C, the dest is null
     (= send to all). Note that the original headers are *not* sent with M. If this is needed, we need to revisit.
  +- A then wraps M into a message sent from X to Y
   - X receives M, drops it (because it is the sender, determined by the header).
  -- Y receives M, adds a RELAY header and sends it down the stack
  -- T, U, V, W and S receive M and deliver it
  -- Y does not relay M because M has a header
  -- Should some member reply (to X), then RELAY at Y will drop the message
  +- Y receives M, and unwraps it.
  +- Y replaces the sender (C) with a ProxyUUID(D,C) (D is the sender and C the origial sender), adds a RelayHeader and
  +  sends it down its local cluster
  +- D, E and F receive M and deliver it
  +- D does not relay M because M has a header
  +
  +Sending a unicast reply:
  +
  +- When F receives the multicast message M, it sends a unicast reply message R
  +- R.dest=ProxyUUID(D,C) and R.src=F
  +- RELAY.down() sees that R.dest is a ProxyUUID and therefore forwards R to the current relay (which is D)
  +- D sets the destination of R to C, wraps the message and sends it to X (via the TCP cluster)
  +- Y receive R and replaces R.src with a ProxyUUID(C,F)
  +- Y puts R on the local channel where it is sent to C
  +
   
   
   Issues
  
  
  
  1.2       +22 -13    JGroups/doc/design/RELAY.png
  
  	<<Binary file>>
  
  

------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a 
Billion" shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev