To improve load-balance for smaller networks, the original paper proposes implementing virtual nodes. These are multiple Chord services on a single server, so that each server effectively manages multiple ranges. While this sounds neat, the paper also warns that finding the optimal number of virtual nodes per host is hard since it depends on the size of the network. I still think this is something we want to support.
I see two ways forward with this:
- Allow passing a
Transport in the concord.Config; multiple Concord instances can run multiplexed on the same server. This implementation additionally synergizes well with a future feature which would be to allow replacing the gRPC transport with something else. However, using virtual nodes would mean more management from the user.
- Implement hidden virtual nodes inside a single
Concord instance. This would add a configuration NumVirtualNodes to concord.Config, and would automatically create and track virtual nodes inside the implementation. One drawback from this is that the API would become more complex. Successor() would no longer be a single list (it would be one list per virtual node), and similarily affect Range(), Predecessor(), and the range callback.
To successfully implement this well without making the API too complex, more consideration needs to be made.
To improve load-balance for smaller networks, the original paper proposes implementing virtual nodes. These are multiple Chord services on a single server, so that each server effectively manages multiple ranges. While this sounds neat, the paper also warns that finding the optimal number of virtual nodes per host is hard since it depends on the size of the network. I still think this is something we want to support.
I see two ways forward with this:
Transportin theconcord.Config; multipleConcordinstances can run multiplexed on the same server. This implementation additionally synergizes well with a future feature which would be to allow replacing the gRPC transport with something else. However, using virtual nodes would mean more management from the user.Concordinstance. This would add a configurationNumVirtualNodestoconcord.Config, and would automatically create and track virtual nodes inside the implementation. One drawback from this is that the API would become more complex.Successor()would no longer be a single list (it would be one list per virtual node), and similarily affectRange(),Predecessor(), and the range callback.To successfully implement this well without making the API too complex, more consideration needs to be made.