Read from the socket using the same max buffer size as we use while

sending. What happens otherwise is that the sender splits all the
traffic into 32k chunks, while the receiver is waiting for the whole
packet. Then for a certain packet sizes, particularly 66607 bytes in
my case, the communication stucks to secondary is expecting to
read one chunk of 66607 bytes, while primary is sending two chunks
of 32768 bytes and third chunk of 1071. Probably due to TCP windowing
and buffering the final chunk gets stuck somewhere, so neither server
not client can make any progress.

This patch also protect from short reads, as according to the manual
page there are some cases when MSG_WAITALL can give less data than
expected.

MFC after:	3 days
This commit is contained in:
Maxim Sobolev 2011-06-04 16:01:30 +00:00
parent de9358edc6
commit 98453c81af
Notes: svn2git 2020-12-20 02:59:44 +00:00
svn path=/head/; revision=222688

View File

@ -194,6 +194,8 @@ int
proto_common_recv(int sock, unsigned char *data, size_t size, int *fdp)
{
ssize_t done;
size_t total_done, recvsize;
unsigned char *dp;
PJDLOG_ASSERT(sock >= 0);
@ -210,9 +212,19 @@ proto_common_recv(int sock, unsigned char *data, size_t size, int *fdp)
PJDLOG_ASSERT(data != NULL);
PJDLOG_ASSERT(size > 0);
total_done = 0;
dp = data;
do {
done = recv(sock, data, size, MSG_WAITALL);
} while (done == -1 && errno == EINTR);
recvsize = size - total_done;
recvsize = recvsize < MAX_SEND_SIZE ? recvsize : MAX_SEND_SIZE;
done = recv(sock, dp, recvsize, MSG_WAITALL);
if (done == -1 && errno == EINTR)
continue;
if (done <= 0)
break;
total_done += done;
dp += done;
} while (total_done < size);
if (done == 0) {
return (ENOTCONN);
} else if (done < 0) {