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 client requests to follower -> leader #2

Open
jcrugzz opened this issue Nov 19, 2014 · 2 comments
Open

forwarding client requests to follower -> leader #2

jcrugzz opened this issue Nov 19, 2014 · 2 comments

Comments

@jcrugzz
Copy link
Contributor

jcrugzz commented Nov 19, 2014

So we have no predefined way of how we are receiving data with the transport being agnostic but I was thinking it could be useful to have a hook in here to allow for proper forwarding of any CLIENT requests to the leader. Having the ability to have any client send a request to any node in a cluster and have it properly handled by raft seems relevant for the availability scenario as a client may not know which one is the leader.

@3rd-Eden this is an optimization but thought it was worth writing down since i had the thought.

@3rd-Eden
Copy link
Member

@jcrugzz That's correct, we don't have any forwarding in place yet. But the messaging to actually send messages to the leader was finished this week. There are a few ways that we can solve this:

  1. We can have the node that we randomly connected to forward payload to it's currently assigned leader.
  2. We can reply back with the address of the leader and disgard the payload
  3. We add a special command / packet type which returns the node's current leader and have a client request that before sending data.
  4. 1+2. We forward the payload to the leader, with the returned reply we add details of the leader process so the next message is send to the correct leader. Only problem here is that sending 2 rapid messages will cause both messages to be re-routed as the reply to the first message has not been answered yet.

@jcrugzz
Copy link
Contributor Author

jcrugzz commented Nov 20, 2014

@3rd-Eden I think 1 is the right way to do it to keep it simple. If the extra latency ends up being a problem in other situations we can revisit adding in 2 but to start thats unnecessary complexity.

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

No branches or pull requests

2 participants