On Mon, Jan 30, 2017 at 9:13 AM, Sandeep More <[email protected]> wrote:
> 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 > > > For #3 the problem is a digest is not easy. The reason is that hosts communicate through each other. If there were three nodes A, B, and C, and a message was sent from A -> B and then the message was sent from B -> C. Node B would be able to change the data and the digest. What I want to do is be able to ensure that the data is verified by A. This would be something like a PGP email. I want to verify that the message is unaltered and that it is from a specific sender. "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." I am unclear about what you are saying here. We can already gossip arbitrary data between nodes. https://github.com/apache/incubator-gossip/blob/master/src/test/java/org/apache/gossip/DataTest.java Thanks, Edward
