Tunnel data corruption
jason-ni opened this issue · comments
When we download file through the remote tunneled port, we found file content hash is different with the one on the server. While the file length is correct. And the downloading complete successfully.
Then we test that if the file content is repeat of a single character, the downloaded file content hash is correct. However, if the content is repeat of "a" to "z" string set, the downloaded file content hash is wrong. Both of those files have size over several hundreds MB.
So we guess that there's offset bug. As we just fixed issue #5, we have concern that there is another bug in the same method.
The function of the "data_noqueue" method is to move data of a buffer(buf0 in the method) to the writing buffer. Before moving, we should compares with the window size to know how many bytes we can send. If we can't send all bytes of the buffer, we should return the partial sent buffer and the offset of unsent bytes. However the code is returning the length of the sent data. When the window size is not large enough, and a pending buffer comes into the data_noqueue method for the third time, the "from" parameter is wrong.
When we fixed this issue, we found that the multi-threads tokio runtime work.