Re: [jgroups-dev] Mesh networking

Mike Jensen wrote:
>
>> * 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?

Sure it can, but then if you cannot replace the failure detection logic. 
I try to separate concerns (aspects) whenever possible, e.g. 
fragmentation is an aspect that's different from retransmission. I've 
made only a few exceptions in JGroups, e.g. retransmission and ordering 
are combined in both UNICAST and NAKACK. This was done to improve 
performance, but in general each aspect is implemented in a different 
protocol.

> 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 guess this can be mitigated by providing default configurations, e.g. 
mesh.xml, which should be used as starting points for customizations. 
This is how it is done in JGroups today: not many folks configure their 
own stack from scratch !

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

Yes, see above. The modularity is one of the key advantages of JGroups. 
This is how projects like Popeye (MANET), or JGroups-lc were able to 
provide different stack setups without having to modify JGroups itself.


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

I recommend doing this in a separate protocol, it'll save you some 
headaches later on...


>> * 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).

I guess your first prototype will be based on TCP, and since reliability 
/ ordering is not a top design goal for the type of applications you 
envisage to run on top of the mesh, I guess this can take a back seat 
for now...


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


Good question... :-) An ideal word X should have the following qualities:

    * Googling for "X" should return 0 hits
    * X is not trademarked
    * X.com / X.org are not taken



Very difficult...




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