You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
A test script is running on the host, sending bytes of data over vsock. Another application that has developed with a wrapper for working with vsock receives this data on Windows guest.
The problem is that vsok on the WIndows side reads randomly more or less data than was sent from the Linux side.
Additional context
The problem disappears (for the current test) if you increase the buffer. But this approach to solving the problem does not seem right to me
The text was updated successfully, but these errors were encountered:
IMHO this is a feature, not a bug. The socket is of the SOCK_STREAM; type which means that data are being sent and received as a stream of bytes. Thus, sending **N** bytes in one sendcall does not imply their reception in onerecv` call. It depends on how quickly the data are transferred between the host and the VM.
You would need a datagram (message-based) socket, however, I do not think such sockets are supported by the Socket driver at the moment.
Describe the bug
A test script is running on the host, sending bytes of data over vsock. Another application that has developed with a wrapper for working with vsock receives this data on Windows guest.
The problem is that vsok on the WIndows side reads randomly more or less data than was sent from the Linux side.
TraceView logs:
LogSession0.txt
To Reproduce
On Linux host run this:
vsock_test.txt
On Windows guest run this:
client_test.txt
With this imported vsock wrapper:
winSock.txt
Expected behavior
Well, I kind of expect WIndows to receive exactly as many bytes over vsock as it is sent)
Screenshots
From Linux host:
![Linux host terminal screanshoot](https://private-user-images.githubusercontent.com/84802550/299376257-86efb789-a0e2-4dc3-8b32-3bcd7dfdf393.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQ1MzkwNDMsIm5iZiI6MTcyNDUzODc0MywicGF0aCI6Ii84NDgwMjU1MC8yOTkzNzYyNTctODZlZmI3ODktYTBlMi00ZGMzLThiMzItM2JjZDdkZmRmMzkzLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA4MjQlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwODI0VDIyMzIyM1omWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWY3MWM5MDZjMjJmNjZjODJlNTE4ZGFkNTJkNTZmZGI4ZDQzZGM3ODlkMGI5MGIxMjIyMzdkZDVmMjM2MDExYWEmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.GN_CjTxpF5Y1BABPRWIYR_NzcELOgcfZ6F7-9ZCVrOc)
From Windows guest:
![cmd](https://private-user-images.githubusercontent.com/84802550/299376717-c29f59ad-3763-4513-91c5-9bf7fad89bf5.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQ1MzkwNDMsIm5iZiI6MTcyNDUzODc0MywicGF0aCI6Ii84NDgwMjU1MC8yOTkzNzY3MTctYzI5ZjU5YWQtMzc2My00NTEzLTkxYzUtOWJmN2ZhZDg5YmY1LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA4MjQlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwODI0VDIyMzIyM1omWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWQxYjVjZDE3Yjc5ZjA0NjhjZjIxMmI4YWYyNWNkY2YzNWNhNDhiMGNmNzdjNGU4YmFkMDczZmZkMDczZTNmNjAmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.mG-ccXY9p_xtxQcYJMCUUlj0S9kieRfdUNflLb8-HH4)
Host:
qemu-system-x86_64
will be good)windows10.txt
VM:
Additional context
The problem disappears (for the current test) if you increase the buffer. But this approach to solving the problem does not seem right to me
The text was updated successfully, but these errors were encountered: