CVS update: JGroups/doc/design RELAY.txt

  User: belaban 
  Date: 10/11/09 09:18:56

  Modified:    doc/design RELAY.txt
  Log:
  ns
  
  Revision  Changes    Path
  1.4       +21 -6     JGroups/doc/design/RELAY.txt
  
  Index: RELAY.txt
  ===================================================================
  RCS file: /cvsroot/javagroups/JGroups/doc/design/RELAY.txt,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- RELAY.txt	8 Nov 2010 14:05:15 -0000	1.3
  +++ RELAY.txt	9 Nov 2010 09:18:56 -0000	1.4
  @@ -3,12 +3,12 @@
   ========================================
   
   Author: Bela Ban
  -Version: $Id: RELAY.txt,v 1.3 2010/11/08 14:05:15 belaban Exp $
  +Version: $Id: RELAY.txt,v 1.4 2010/11/09 09:18:56 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.
   
  -We have data centers with a local cluster each in New York (NYC) and San Francisco (SFO). The idea is to relay
  +We have data centers, each with a local cluster, in New York (NYC) and San Francisco (SFO). The idea is to relay
   traffic from NYC to SFO, and vice versa.
   
   In case of a site failure of NYC, the state is available in SFO, and all clients can be switched over to SFO and
  @@ -25,7 +25,7 @@
   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 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.
  +member is always member of the local and global cluster, and therefore has 2 channels it joins.
   
   A relay member has a UDP stack which additionally contains a protocol RELAY at the top (shown in the bottom part
   of the figure). RELAY has a JChannel which connects to the TCP group, but *only* when it is (or becomes) coordinator
  @@ -40,7 +40,7 @@
   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
  +When boradcasting a relayed message on 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.
   Otherwise, we would have a cycle.
   
  @@ -83,8 +83,23 @@
   - 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)
  +- RELAY.up() in D sees that the destination is a ProxyUUID and relays the message, via Y to X
   - 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
  +- A receives R (from X) and replaces R.src with a ProxyUUID(C,F)
  +- A puts R on the local channel where it is sent to C
  +
  +
  +Implementation
  +--------------
  +
  +RELAY.up():
  +
  +
  +
  +RELAY.down():
  +
  +
  +
  +Receive message from TCP channel:
   
   
  
  
  

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