Skip to content
This repository has been archived by the owner on Dec 19, 2017. It is now read-only.

Cluster memebers are tracked by their Address' hashCode #74

Open
bgloeckle opened this issue Dec 1, 2015 · 2 comments
Open

Cluster memebers are tracked by their Address' hashCode #74

bgloeckle opened this issue Dec 1, 2015 · 2 comments

Comments

@bgloeckle
Copy link
Contributor

ClusterState seems to track members of the cluster by their "ID" and the ID seems to be (LeaderState#join(...)) the Object#hashCode() of the address of that node.

This seems to be insecure, as two nodes with different addresses could have the same hashCode and therefore the same ID. Or am I missing something?

@kuujo
Copy link
Member

kuujo commented Dec 1, 2015

No, you're right. The hashCode thing is a trade off. It's exceedingly unlikely Address hash codes will collide since IPs are limited to a specific, comparatively small range of possibilities, and the number of servers in a cluster is also small. Even just using the string hash code makes it unlikely they'll ever collide within a single cluster.

The reason for using hash codes is to provide a space compact way to send Address in requests like AppendRequest. It's effectively a member ID. AppendRequest.leader() is a 4-byte ID rather than a 22 byte host and port. This is just a user friendly alternative to requiring the user to specify a server ID at startup.

But I think with the changes in the client transport PR (which will be merged soon) this can probably be replaced. That PR adds an extra request type for sending configurations before sending an AppendRequest. So, the leader can arbitrarily assign server IDs in its own configuration and send those IDs to followers when replicating that configuration. This wasn't possible in the past since AppendRequest was the only way the leader replicated its configuration. This would mean essentially the leader() ID sent in an AppendRequest relates to the current cluster configuration, which should be fine. Some parts of the protocol like pre-vote and vote requests would still have to serialize Address since they happen before any leader exists, but those are infrequent requests so that should be fine too.

On Dec 1, 2015, at 2:34 AM, Bastian Glöckle notifications@github.com wrote:

ClusterState seems to track members of the cluster by their "ID" and the ID seems to be (LeaderState#join(...)) the Object#hashCode() of the address of that node.

This seems to be insecure, as two nodes with different addresses could have the same hashCode and therefore the same ID. Or am I missing something?


Reply to this email directly or view it on GitHub.

@bgloeckle
Copy link
Contributor Author

Sounds great :)

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

No branches or pull requests

2 participants