Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Forwarding commands to the leader #190

Closed
NorbertHeusser opened this issue Aug 22, 2024 · 2 comments
Closed

Forwarding commands to the leader #190

NorbertHeusser opened this issue Aug 22, 2024 · 2 comments

Comments

@NorbertHeusser
Copy link
Contributor

NorbertHeusser commented Aug 22, 2024

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
Copy link
Member

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
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants