[
https://issues.apache.org/jira/browse/ZOOKEEPER-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13619826#comment-13619826
]
Alexander Shraer commented on ZOOKEEPER-1633:
---------------------------------------------
Hi Ted,
Thanks for the comments. In this specific patch I was trying to solve the
following problem: currently the first thing a server
wants to hear from another server connecting to it is a long, which is the id
of the connecting server. Once the connection is
established, and a leader is elected, they start sending protobufs. For ZK-107
an id was not enough - I also needed to send the leader election address and
port (a string) of the connecting server, which may be new. We needed a way for
an old 3.4 server
to understand that the connecting server is sending id + string/protobuf and
not just id, and at least remove the string/protobuf from the stream, even if
it only ends up using the id from this message. This is why in the latter case
we're sending a negative number followed by an id, followed by the length of
the remaining message, and the 3.4 server can realize that this is not just
"id", remove the remaining message from the stream, and move on.
So while I agree with you that it would be nicer if that first message is a
protobuf and not just a long as in 3.4, I don't see how this would help us
solve the backward compatibility issue that this current patch is trying to
address.
Thanks,
Alex
> 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
