[jgroups-dev] Mesh networking

A few ideas how this could be used with JGroups:

    * Transport: you could use TCP or UDP. TCP could have connection
      reaping turned on, so idle connections are torn down and
      re-established if needed. UDP would run with ip_mcast=false
    * Discovery: we probably configure just a few starting points (IP
      addresses) for the initial lookup. We could also use
      GossipRouter(s) here. Since discovery also transfers physical
      addresses and logical names (if configured), we'd need an
      alternative to get this information
    * Failure detection (FD, FD_ALL): not feasible because these
      protocols form an overlay structure (a ring), or use
      broadcasting... Maybe a new FD protocol would be in order, which
      sends heartbeats to our 3 connected peers. Or, we omit a failure
      protocol detection entirely, and use the mesh information to
      detect crashed peers
    * MERGE2: I don't think this is needed, as a mesh automatically
      merges on a partition heal. IIUC this issue hasn't been solved
      yet, so I guess this is another new protocol
    * NAKACK / UNICAST: not needed, as we can live with message loss /
      reordering. Maybe if UDP is used, UNICAST would be a good idea
      though...
    * STABLE: not needed, as we don't use NAKACK
    * GMS: not needed, as we don't have the concept of a coordinator and
      the JOIN can be sent to *any* peer of the mesh. View can stay, but
      it is only an approximation of the membership, plus it is not
      guaranteed to be the same across all peers, so communication-less
      agreement e.g. for coordinators cannot be done. So if agreement or
      consensus are required by applications, they have to provide it
      themselves. Or we write a protocol which does this. Anyway, maybe
      this functionality is not something that's offered in a mesh
      anyway. BTW: you should come up with a better word than 'mesh',
      because a mesh is exactly what you want to avoid...)
    * Flow control: not needed in its current form, but maybe once I've
      split FC into multicast and unicast flow control, then unicast
      flow control could be used...
    * Fragmentation: could be used over UDP as transport
    * State transfer: not needed
    * FLUSH: not needed, would be problematic over a mesh


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