Re: [jgroups-dev] Mesh networking

Thanks, this is basically what I have been thinking as well....a few 
comments inline (and a couple points to respond to)

Bela Ban wrote:
> 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
Definitely, I expect other transports to work as well (ie loopback)
>    * 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
Also agreed, currently I just provide a list of a few servers to 
bootstrap from.  But it really does not matter how we find the peer 
node, just that we can find one.
>    * 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
That's basically how I was planning on doing failure detection 
(heartbeats).  Is there any reason this can't be combined in the same 
protocol as the mesh structure logic?  It can be separated, I just don't 
see the value in separating them (worry that it will be confusing to 
users, you have to use this FD, but not this one for one stack, and vice 
versa).  I was thinking it would be easier to understand if components 
that will only work together were just kept together.  Or do you feel 
this is against your current modular model?
>    * 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
Something new will need to be done here...but I am hoping I can learn 
some secrets of the trade from the work you have already done.  I was 
also expecting that this would be included in the same protocol that 
handles the connection/structure logic.
>    * NAKACK / UNICAST: not needed, as we can live with message loss /
>      reordering. Maybe if UDP is used, UNICAST would be a good idea
>      though...
This may not be needed for my company, but if this becomes interesting 
to the community I would be willing to develop some sort of JGroups 
level reliable delivery (sure it could be useful for some).
>    * STABLE: not needed, as we don't use NAKACK
Agreed
>    * 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...)
What name would you suggest?  I have struggled to think of a name for 
this.  I been calling it a "mesh" because I think of the end network 
structure to look like a physical mesh net when drawn out. ( 
http://www.davidtorno.com/MacTex_Uploads/Net002.jpg )
>    * 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...
I agree, I don't think I would want to use any flow control that is 
dependent on ack's (as I understand that it currently is)
>    * Fragmentation: could be used over UDP as transport
I don't know fragmentation very well, I will need to look into this more
>    * State transfer: not needed
Agreed, I don't think state transfer is realistic
>    * FLUSH: not needed, would be problematic over a mesh
Also agreed, avoiding the flush has been my main goal

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