In SERVER-81784, Mathias recommended that we optimize the sync networking path on linux by passing MSG_WAITALL at all times for sinkMessage. He also recommended this improvement for sourceMessage, which I split into this ticket because of its additional complexity:

While we are at it, we should make the sourceMessage a bit more optimal for small messages as well. Currently we do a recv of 16 bytes to read the header, then do another recv to read the rest of the message. Instead we should allocate a buffer on the stack (maybe 1, 4, or 16KB?) and do a recv into that, only looping until we have the size (in general we won't loop at all). If we got lucky and got a full message on our first try, we can just copy that into a Message and move on without doing a second syscall. If we didn't get a full message then we should to a recv(MSG_WAITALL) for the remainder.

As noted in a discussion on slack : "I think this is a 'strict win' for us - we either do a 'big read' and avoid doing the second syscall, or we have the 'normal behavior' where we read the header (and then some) in one syscall, and then do a second to get the rest."

After discussing with the team, we noted that for exhaust commands, we may run into a situation where this initial read reads in multiple messages at once. In this case, we would need to parse the contents of the buffer to return one message from sourceMessage, and stash the remaining messages to be returned on future calls to sourceMessage.