search

cowsql / raft

Asynchronous C implementation of the Raft consensus protocol
https://raft.readthedocs.io
Other
45 stars 6 forks source link

Forwarding commands to the leader #190

Closed NorbertHeusser closed 3 weeks ago

NorbertHeusser commented 3 weeks ago

Right now we are using the library with great success. For our next extension we would need to be able to initiate log changes from any cluster member. Our idea would be to forward the change from the node to the leader and the leader would append it to the end of the log.

Are there already some design thoughts, how we might implement this ?

E.g. does it make sense to define an additional event_type ?

freeekanayaka commented 3 weeks ago

Hey, glad to hear the library is working for you!

I don't have any strong idea about this, but I would say that forwarding to the leader could be something that applications can implement outside this library.

Typically applications consuming this library already implement some application-specific protocol, where they open a network port on every node for communicating with clients (or they proxy the raft-specific port). A non-leader node would accept changes, forward them to the leader via the application-specific protocol, wait for the leader to notify the commitment and then reply to the client.

This might also be implemented in the library itself, but I feel it's something that every one might want to implement slightly differently. Not sure.

NorbertHeusser commented 3 weeks ago

I totally get the idea to keep the raft library simple and focus on the core functionality. There are other libraries, which have implemented something like this. But this might be a risk depending on the use case. The non-leader node forwarding a change cannot be sure, when his change will be added to the log. And depending on the use case this might be a bigger problem with conflicting changes.

So I am fine to keep this kind of forwarding in the application layer. The only issue I have to keep this in application layer is the idea to implement a different communication between the node (for the forwarding). But we anyway think about extending the transport layer to allow custom data to make use of the existing transport layer. But as this is a totally different topic I filed a different issue and close this one.