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

1 files changed, 14 insertions, 2 deletions

diff --git a/sbin/hastd/proto_common.c b/sbin/hastd/proto_common.c
index 183b4e4..1f541da 100644
--- a/sbin/hastd/proto_common.c
+++ b/sbin/hastd/proto_common.c
@@ -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) {