[jira] [Commented] (ZOOKEEPER-1633) Introduce a protocol version to connection initiation message

["Ted Dunning (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/ZOOKEEPER-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13619771#comment-13619771 ] 

Ted Dunning commented on ZOOKEEPER-1633:
----------------------------------------

Alex,

Sorry to come in late here.

I have a few comments.

1) is a version number really what you want here?  Shouldn't it be done more like modern protocols such as protobufs to introduce a mechanism of optional fields?  Strict versioning of protocols is very unpopular any more because of the brittleness introduced into protocols.

2) it is possible that there is an irreconciliable conflict in version between correspondents.  In such cases, it is important to signal this clearly.  As such, it is good to add not only versioning information to the original request, but a very stable reply that indicates that there is an irreconciliable version mismatch.  Is there a way that you can do this in your proposal?


                
> Introduce a protocol version to connection initiation message
> -------------------------------------------------------------
>
>                 Key: ZOOKEEPER-1633
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1633
>             Project: ZooKeeper
>          Issue Type: Bug
>          Components: server
>            Reporter: Alexander Shraer
>            Assignee: Alexander Shraer
>             Fix For: 3.4.6
>
>         Attachments: ZOOKEEPER-1633.patch, ZOOKEEPER-1633-v4.patch, ZOOKEEPER-1633-v4.patch, ZOOKEEPER-1633-ver2.patch, ZOOKEEPER-1633-ver3.patch
>
>
> Currently the first message a server sends to another server includes just one field - the server's id (long). This is in QuorumCnxManager.java. This makes changes to the information passed during this initial connection very difficult. This patch will change the first field of the message to be a protocol version (a negative number that can't be a server id). The second field will be the server id. The third field is number of bytes in the remainder of the message. A 3.4 server will read the first field as before, but if this is a negative number it will read the second field to find the server id, and then remove the remainder of the message from the stream. This will not affect 3.4 since 3.4 and earlier servers send just the server id (so the code in the patch will not run unless there is a server > 3.4 trying to connect). This will, however, provide the necessary flexibility for future releases as well as an upgrade path from 3.4

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira