Re: [jgroups-dev] Mesh networking

That sounds great.  I hope to start work on this in JGroups ether later 
today, or Monday  (assuming not too much comes up). 

I will probably look for feedback when I am into it about the code 
structure.  Right now here is what I am considering:
create a new package in protocol called "mesh" (although i will spend 
some time to try and think of a better name)
in that package it will have the protocols that handle:
Group Membership/Connection structures (which will have multiple files 
associated with it):
    * Actual protocol file, which will handle the logic and actual actions
    * A model file, that manages and maintains the internal 
representation of the mesh
    * I have lots more division in my current prototypes, but I am not 
sure right now how this will most naturally translate to JGroups
Failure Detection/Merging (although merging is somewhat dependent on the 
above protocol, so I am not sure how this will look yet)

As I said, I will look for feedback once I know more how I think it 
should look.  But I want to stay within the current JGroups paradigm.

Bela Ban wrote:
>
>
> 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...
>
>
>
>


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