Even if it weren't for the desire to have 1-byte id's for salting into
session id's, using IP's as the member id will be dubious when you
anticipate IPv6 addresses.
There might eventually be a need to map 128-bit IP addrs or UUIDs into a
smaller id space. It's unlikely there will ever be > 255 actual members
that need to be tracked. Each member could be tied to a UUID or IP6
address, and have the mapping to id be done internally from
configuration that's stored in the ZK tree itself. This requires an
add-member that takes the longer identity and stores the mapping.
-dB
On 12/20/2016 9:18 AM, Dan Benediktson wrote:
I'd strongly suggest you keep the actual value within the range of [0,255]
so that you can get the benefit of the fix for ZOOKEEPER-2504 whenever the
patch is accepted.
On Tue, Dec 20, 2016 at 9:11 AM, Michael Han<[email protected]> wrote:
I can not see any limitation on this myid??
There is no hard limitation in code that enforce myid is in range of
[1..255] - myid is required to be in such range because it's used as server
id which is used to generate session id. Each session id should be unique,
so this requires the higher 8 bits of the server id (myid) to be unique.
See here
<https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/
zookeeper/server/SessionTrackerImpl.java#L100>
for
code reference.
I want to use the host ip to auto generate myid (ip2long) in bash shell
