This is exciting ! #3, #2 and #1 especially look a great value add.
On #3 I think signing the digest would be easier in short run, encrypting will mean involving complex keystore/truststore setup. May be you already covered this in Recipes or elsewhere but still putting it here: It would be really cool if one could choose a custom data (like a String/Long value), I understand that this could be misused and misinterpreted as datastorage so may be there can be stricter limits on the size of the custom payload. This might help Apps to integrate Gossip better. Just a thought ! Best, Sandeep On Sun, Jan 29, 2017 at 10:25 PM, Edward Capriolo <[email protected]> wrote: > We currently have almost 10 open tickets for features / improvements to > gossip, many are slated for the next release and we are on our way to be > ahead of schedule with that. > > I wanted to pick everyone's brain as to where we should aim for. > > I think some larger general directions are below: > > 1) SWIM. https://www.cs.cornell.edu/~asdas/research/dsn02-swim.pdf > > This is a fairly large undertaking in terms of codifying the protocol and > keeping the project elegant with two Failure Detectors > > 2) HTTP as transport > > Having two transports in the codebase is simple. I think this will go well > HTTP clients do all the session/persistence. Transplanting Gossip to live > in a webapp wont be too bad but it might involve re-orging the project a > bit into a multi-module maven project. I see a lot of upside here > > 3) Signed messages (https://issues.apache.org/jira/browse/GOSSIP-47) > > While I am not a super expert in keystores and such this strikes me as > interesting idea. Mostly because it allows peers to share info but also be > able to sign/verify/encrypt info as it moves between peers. I have never > seen something quite like this so I think it is novel. > > 4) Recipes > > Building things like Ephemeral Nodes or Leader Election seem to be a good > fit. Gossip should not be a database so this is a hard line to draw. This > will take some research and expertise to implement correctly. > > 5) Second implementation > > Originally I planned to build out a second implementation in c, node, or > python. This seems less appealing to me at the moment, but if Gossip Java > gets too large/complex we will likely miss out window to do this. > > 6) something massive to spin up N instances in amazon and do testing > > This is something that needs to happen, maybe in two parts. > > 7) Other ideas? Let them fly. > > Thanks, > Edward >
