mgodave
Provide a way to plug custom communication layer
Currently barge is tightly coupled with its communication layer based on protocol buffers and netty, with its own server port and protocol. In order to make barge integration easier in various settings, it would be great to decouple the core Raft protocol from the communication medium it uses.
Personally, I am aiming at integrating barge as part of a another piece of software which communicates throught HTTP REST-style interface so I would like to ensure the barge part also uses this transport mechanism.
I'm curious, more for my own edification, what exactly is the use case you are looking at. Why must you use HTTP? Is is a port issue? Is it personal preference? I wouldn't mind breaking out the communication medium I would just like a clearer story for why this is important so I can take it into account in the future.
That being said, you could probably start by plugging in a new protocol behind o.r.b.rpc.Client and it's associated classes. Some refactoring would clearly have to be done. The Guice module in the rpc package would take, as an argument, the implementation. You would also have to abstract out the server portion in o.r.b.RaftService. Instead of passing in an RpcServer you can abstract that away and pass in a NetworkServer (or whatever you call it). This would be a pretty big refactor and there are currently two of us working on it. If you decide to take on this work please keep the issue updated.
As said I am planning to integrate barge in a system whose purpose is to be distributed across nodes to supervise another system. This system is made of instances of server, exposing a REST interface through HTTP on the various nodes and I plan to use barge to distribute the configuration of these instances in a safe way. I work in a setting (IT for banks and corporate finance) where opening a port on a machine for an alien protocol is a lengthy, bureaucratic and ultimately random process that can fail. So I would rather like to integrate barge as a library with communication going through the existing REST interfaces.
Moreover, in the general case having the ability to select the right transport for your system is always a good option. And a nice thing with using HTTP is that you can have security and proxying for free (using HTTPS). Given that I do not expect raft to be used for performance sensitive stuff, eg. massive low-latency messaging, going through something like HTTP which obviously does not have the raw performances of Netty is not an issue.
Regarding the refactoring itself: I have already implemented it so I will send a pull request and see if you can accept it.
@abailly thanks for the info and the work. I'll take a look at the PR when I get a chance, perhaps this evening after work.