[
https://issues.apache.org/jira/browse/ZOOKEEPER-3426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Damien Diederen reassigned ZOOKEEPER-3426:
------------------------------------------
Assignee: Damien Diederen
Hi [~suhas.dantkale],
That is a nasty one, indeed. Have you actually experienced the problem, or did
you just spot it in the code? In any case, I agree with your analysis.
I have a proposed fix, but I still have to figure out how to include tests. (I
will submit a "pull request" once I am done.) In the meantime, here is a sneak
peek:
{code:c}
rc = zookeeper_recv(zh->fd, buff->buffer+off, buff->len-off, 0);
/* dirty hack to make new client work against old server
* old server sends 40 bytes to finish connection handshake,
* while we're expecting 41 (1 byte for read-only mode data) */
if (rc > 0 && buff == &zh->primer_buffer) {
/* primer_buffer's curr_offset starts at 4 (see prime_connection) */
int avail = buff->curr_offset - sizeof(buff->len) + rc;
/* exactly 40 bytes (out of 41 expected) collected? */
if (avail == buff->len - 1) {
int32_t reply_len;
/* extract length of ConnectResponse (+ 1-byte flag?) */
memcpy(&reply_len, buff->buffer, sizeof(reply_len));
reply_len = ntohl(reply_len);
/* if 1-byte flag was not sent, fake it (value 0) */
if ((int)(reply_len + sizeof(reply_len)) == buff->len - 1) {
++rc;
}
}
}
{code}
The gist of it is:
# We look at how much data has accumulated in the buffer (as opposed to
checking {{rc}});
# If the amount is sufficient, we look at the encoded {{length}} at offset 0.
Comments welcome!
> ZK prime_connection(the Handshake) can complete without reading all the
> payload.
> --------------------------------------------------------------------------------
>
> Key: ZOOKEEPER-3426
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3426
> Project: ZooKeeper
> Issue Type: Bug
> Components: c client
> Reporter: Suhas Dantkale
> Assignee: Damien Diederen
> Priority: Blocker
>
> /* returns:
> * -1 if recv call failed,
> * 0 if recv would block,
> * 1 if success
> */
> static int recv_buffer(zhandle_t *zh, buffer_list_t *buff)
> {
> int off = buff->curr_offset;
> int rc = 0;
> [................]
> if (buff == &zh->primer_buffer && rc == buff->len - 1) ++rc; <======
> Handshake prematurely complete.
> On non-blocking socket, it's possible that socket has exactly "buff->len - 1"
> bytes to read.
> Because of the above line, the Handshake is prematurely completed.
> What this can lead to is:
> There will be one outstanding byte left on the socket and it might go as part
> of next message which could get corrupted.
> I think this can lead to ZRUNTIMEINCONSISTENCY issues later.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
