CVS update: JGroups/doc/design RELAY.txt

  User: belaban 
  Date: 10/11/08 14:05:15

  Modified:    doc/design RELAY.txt
  Log:
  new design
  
  Revision  Changes    Path
  1.3       +1 -34     JGroups/doc/design/RELAY.txt
  
  Index: RELAY.txt
  ===================================================================
  RCS file: /cvsroot/javagroups/JGroups/doc/design/RELAY.txt,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- RELAY.txt	8 Nov 2010 14:04:36 -0000	1.2
  +++ RELAY.txt	8 Nov 2010 14:05:15 -0000	1.3
  @@ -3,7 +3,7 @@
   ========================================
   
   Author: Bela Ban
  -Version: $Id: RELAY.txt,v 1.2 2010/11/08 14:04:36 belaban Exp $
  +Version: $Id: RELAY.txt,v 1.3 2010/11/08 14:05:15 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.
  @@ -88,36 +88,3 @@
   - Y puts R on the local channel where it is sent to C
   
   
  -
  -Issues
  -------
  -
  -Cluster RPCs in JBossCache
  ---------------------------
  -- When we invoke a cluster RPC in JBossCache, the destination list is (for example) {A,C,D,E}
  -- This list is sent with the RPC (as a header)
  -- The receiver drops the request if its local address is not part of the destination list
  -==> This would cause all nodes in the SFO cluster to drop the cluster RPC request !
  -
  -Buddy Replication
  ------------------
  -- When we replicate from B to C, the relay (e.g. E) doesn't know about this and will not replicate !
  -- How do we determine to whom we should replicate in SFO if we use buddy replication ?
  -
  -Identity
  ---------
  -- What if we have members that have the same address in NYC and SFO ?
  -- If we use TCP plus bin_port (7800), then every member starts at 7800
  -- If we happen to use IP local addresses in both SFO and NYC (e.g. 192.168.1.1), then
  -  we run into this issue
  -
  -Reception of message sent by self
  ----------------------------------
  -- Because we relay messages only on *reception*, NOT on sending, a relay might not receive it own message
  -- This is possible when the relay (e.g. E) calls RpcDispatcher.callRemoteMethods() with a target list which excludes
  -  itself
  -==> Solution: catch the message when sending, *not* receiving !
  -
  -No, doesn't work ! The relay would have to be active on every node ! This is not feasible as this would require
  -every node to have a TCP connection to NYC ! We still need to do it on reception not sending. However, messages
  -cannot exclude the sender
  
  
  

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