Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#8 Incompatible client and server list detection

3.0.0
closed
fpj
None
5
2008-06-10
2008-04-07
Benjamin Reed
No

Bad things may happen if the lists of hosts that make up ZooKeeper at the client doesn't match the actual servers that make up ZooKeeper particularly when the client's list includes servers from different ZooKeeper instances. The ZooKeeper server should validate the clients list when the clients connect to ZooKeeper.

Discussion

1 2 > >> (Page 1 of 2)
  • Benjamin Reed
    Benjamin Reed
    2008-05-12

    • milestone: --> 838741
    • assigned_to: nobody --> phunt
     
  • Patrick Hunt
    Patrick Hunt
    2008-05-14

    Logged In: YES
    user_id=12853
    Originator: NO

    Are you saying that the client should pass the list of addresses to the Server? and the server should verify this list against the quorum members? I don't see this in the current code - what would have to change, the protocol and client initialization (server connect)?

    Seems like comparing ip addresses could be an issue since the ip seen by the client could differ from the ips used by the servers. Comparing host names seems like it could also have issues...

    What happens if a quorum member is temporarily offline (not active member, say network went down temporarily) and a client connects?

    Also -- seems like the host:port would need to be compared, not just host, correct? (multiple zk clusters running on a single host).

     
  • Benjamin Reed
    Benjamin Reed
    2008-05-20

    Logged In: YES
    user_id=154690
    Originator: YES

    I think it should be IP address/port pairs that are compared. It is possible that there could be a backend network used by the servers for the quorum protocols and a frontend network used to talk to clients. In that case we should be able to specify those address/port pairs, but for now lets just assume they are the same. (It's a valid assumption in all our current deployments.) You get extra credit for supporting both IPV4 and V6 addresses :)

     
  • fpj
    fpj
    2008-05-27

    • assigned_to: phunt --> fpj
     
  • fpj
    fpj
    2008-05-28

    Logged In: YES
    user_id=1926444
    Originator: NO

    My plan is to add a check on the server side to NIOServerCNXN.readRequest() similar to the one for OpCode.auth. I would then add a new OpCode "chkservers" and a new packet "ChkServersPacket". Another way would be to piggyback this information on some other message, but I find such things confusing when trying to understand the code later.

     
  • fpj
    fpj
    2008-05-29

    Logged In: YES
    user_id=1926444
    Originator: NO

    File Added: patch-srv-chk.txt

     
  • fpj
    fpj
    2008-05-31

    Logged In: YES
    user_id=1926444
    Originator: NO

    I have moved this request to the patches queue as I'm proposing a patch. The patch attached creates a new jute packet type, called ChkServersPacket, that clients send to servers and servers recognize as containing the list of ZK servers the client is aware of.

    The main files affected are ClientCnxn.java and NIOServerCnxn.java. This patch thus not implement a modification to the C interface. A modification to the C client is necessary with the modifications to the server in the current patch as the server drops the connection to the client if the list doesn't match, and it doesn't accept the client coonection if the client doesn't send a list of servers.

    It is a possibility (not implemented in this patch, though) to enable and disable the check through a configuration flag.

    -Flavio
    File Added: patch-chkservers.txt

     
  • fpj
    fpj
    2008-05-31

    • milestone: 838741 --> 836618
    • labels: 1037121 -->
     
  • fpj
    fpj
    2008-05-31

    Patch

     
    Attachments
  • fpj
    fpj
    2008-05-31

    Logged In: YES
    user_id=1926444
    Originator: NO

    Sorry, this is what I should have said... =)

    I have moved this request to the patches queue as I'm proposing a patch.
    The patch attached creates a new jute packet type, called ChkServersPacket,
    that clients send to servers and servers recognize as containing the list
    of ZK servers the client is aware of. Note that jute has a bug that does not allowed me to create a vector<int> field, so I had to add a new type called Port. This is basically a hack to bypass the jute bug.

    The main files affected are ClientCnxn.java and NIOServerCnxn.java. This
    patch does not implement a modification to the C interface. A modification
    to the C client is necessary with the modifications to the server in the
    current patch as the server drops the connection to the client if the list
    doesn't match, and it doesn't accept the client connection if the client
    doesn't send a list of servers.

    It is a possibility (not implemented in this patch, though) to enable and
    disable the check through a configuration flag.

    -Flavio

     
1 2 > >> (Page 1 of 2)