Comment 16 for bug 1362333

Ok fuller debug indeed confirms that the client reads the type of the message (ANSWER), and then attempts to read the size of the said answer. That is not yet present, so it gets EAGAIN because this is a NONBLOCKing socket. This is does not like and aborts the connection in failure, leading the server to report connection loss.

In short we are hitting normal behaviour, multiple writes and multiple reads can occur in any order. The correct fix is for the consumer to buffer the partial data, and to continue when the full data is available, this is non-trivial because the data we are trying to buffer as different form depending on type. Ideally we would start each message with a length, such that we could buffer it before introspecting it.

For now we can also avoid this by ensuring the server write is performed as a single operation. As long as we are below the buffering limits we will guarentee to only see the initial command type byte if the answer is also present.