Repository navigation
go: client on Linux get EOF on read #55
Description
When running the sock_stress tests with the server on the host (sock_stress -v 1 -s hvsock) and the client in the Linux VM sock_stress -v 1 -c hvsock://parent the client frequently gets errors on receive, like this
2018/02/07 13:30:41 [00086] Failed to receive: EOF
2018/02/07 13:30:41 [00086] Failed to receive: EOF
2018/02/07 13:30:41 [00086] TX/RX: 49349 bytes in 36.6093 ms
2018/02/07 13:30:41 [00086] Checksums don't match
2018/02/07 13:30:41 [00087] Failed to receive: EOF
2018/02/07 13:30:41 [00087] Failed to receive: EOF
The server does not report any errors and the test works fine in the other direction.
It seems timing sensitive as some connections work fine, even with a similar amount of data transmitted.
The server (on the host) is basically performing:
con := Accept()
io.Copy(con, con)
con.Close()
The client in one go-routine is sending random data and when all data is sent calls (CloseWrite()). In another go routine is it repeatably calling io.ReadAll() of fixed sized chunks (min of buffer or data left to read). It's the io.ReadAll() which sees the EOF before all data is read.
Activity
rn commentedon Feb 8, 2018
With #57 we see a bit more:
So basically, half way through receiving 64872B from the host the read gets an EOF. The test run was donw with 8192B buffers but we see similar behaviour with the default 16kB buffers, but there it is more likely to be the last batch which fails. The individual batch failing always seems to fail with 0B read.
rn commentedon Feb 8, 2018
I get similar error when using a Win 10 Pro (Fall Creators Update) connecting to a Win 10 Pro host where the server runs:
rn commentedon Feb 9, 2018
With the C implementation in
c/hvecho.cwe see the same issue.hvechohas a server and client mode. The server:So basically, the server echo's data received back until the
recv()returns 0 indicating shutdown() and then sends a last message before closing.The client does:
ie after the it receives the echo calls
shutdown()and then expects abyemessage from the server.With the server inside a Linux VM and the client on the Windows host, this works fine.
Client output(Windows):
Server output (Linux):
Running the server on Windows and the client on Linux we see:
Client (Linux):
and on the server (windows):
Note that sometimes the Linux client does get the
byemessage but sometimes it doesn't. So we see the same timing issue we see in the go test program.rn commentedon Feb 9, 2018
I also tried to put a
syscall.FlushFileBuffers(v.fd)before callingsyscall.close()and it marginally improved thinks in that the client now sometimes seems to receive some more data, ie we now occasionally hit:Unexpected EOF after reading 4088 of 8192 bytes...rn commentedon Feb 9, 2018
I also tried turning the
WSASend()call into a non-overlapping call bysyscall.WSASend(v.fd, &b, 1, &bytes, f, nil, nil)(see here) but this has the same issue ie not all data sent by Windows is received by the client ifclose()is called on the windows host