Please review: https://github.com/edwardcapriolo/incubator-gossip/tree/uri https://issues.apache.org/jira/browse/GOSSIP-2
This is half of the plumbing.The rest will be added when we actually build 2 protocols. On Sat, May 28, 2016 at 1:06 PM, Edward Capriolo <[email protected]> wrote: > I created https://issues.apache.org/jira/browse/GOSSIP-2. I am creating > the tickets in scrum style. I do not want anyone to think that this means > the issue is locked for discussion once it lands in Jira, because we still > charge course at any time. @Josh as to your point, I typically call this > 'guy who does the work choice' . During the coding the developer will be > closer to the problem and make the call that makes the most sense. I think > we should only use whatever RFC guidance is out there. 'udp' is a lower > level protocol than http, but I would be ok with either. > > On Tue, May 17, 2016 at 5:45 PM, Josh Elser <[email protected]> wrote: > >> Right, I get that. I was more pointing out why not just "udp://" >> instead of "gossip:udp://". It looks like java.net.URI can still parse >> it, just doesn't quite parse as I'd expect :). >> >> On Tue, May 17, 2016 at 1:19 PM, Edward Capriolo <[email protected]> >> wrote: >> > "At first glance, what is the leading "gossip:" buying you over a >> normally >> > parsable URI?" >> > First not everything will be http so: >> > >> > My thinking is: >> > >> > firstpart:secondpart://host:port/?params >> > >> > gossip:udp://host -> cluster using the current UDP protocol >> > >> > gossip:tcp://host -> cluster using tcp protocol >> > >> > gossip:http://host -> cluster using http over tcp >> > >> > Basically clusters would ONLY speak one protocol, and the parts of a URI >> > are a build in "configuration" system. Otherwise we need to have a >> separate >> > parameter that must be part of the gossip messages for all the options. >> > >> > >> > >> > On Tue, May 17, 2016 at 9:47 AM, Josh Elser <[email protected]> >> wrote: >> > >> >> (yay, mailing lists!) >> >> >> >> At first glance, what is the leading "gossip:" buying you over a >> >> normally parsable URI? Might it be better to embed that in the path? >> >> My thinking is that is might also make it easier to deploy this into >> >> existing web containers/appservers as well as allow you to deploy some >> >> normal informational webserver alongside the gossip "service" (e.g. >> >> /gossip is the service, while / is some metrics/monitoring service). >> >> >> >> - Josh >> >> >> >> On Mon, May 16, 2016 at 6:46 PM, Edward Capriolo < >> [email protected]> >> >> wrote: >> >> > Hello all, >> >> > >> >> > There are two connection related items in the proposal ( >> >> > https://wiki.apache.org/incubator/GossipProposal) >> >> > >> >> > - Explore HTTP transport as an alternative to UDP >> >> > - Secure communications >> >> > - Transport security using a pre-shared key >> >> > - Public Key Infrastructure >> >> > >> >> > Currently the message sent over the wire sends two connection related >> >> > parameters host and port. Each time a message is send a UDP >> connection is >> >> > established. Also one interesting bit is that the messages do not >> have an >> >> > ACK, the active gossip thread picks a partner and sends a message. >> >> > >> >> > My thinking is we would like a few things >> >> > 1) a UDP service that keeps connections alive or TCP? >> >> > 2) an http service (Ie run gossip as a tomcat/jetty webapp) >> >> > 3) Encryption >> >> > >> >> > I think an interesting way to go about this would be URI's that will >> give >> >> > us more flexibility than (host, port) >> >> > >> >> > gossip:udp://host:port >> >> > gossip:tcp://host:port >> >> > gossip:http://host:port >> >> > >> >> > I believe now that protocols like http(S) are out of favor vs start >> TLS. >> >> > >> >> > That could be something like >> >> > >> >> > gossip:http://host:port;tls=true >> >> >> > >
