qus...@gmail.com wrote: >> If the problem is the message framing issue over TCP I talked about then >> it's really a bug in the application client program or server. > > So it's only a matter of coincidence that the problem doesn't exist in > ssh and tunnelier?
Maybe, maybe not. It's also possible that they have taken extra measures to try to avoid the problem. It might make sense for libssh2 to also do this, but I agree with Henrik that the real problem is in the application that is being forwarded. I'll try to explain with an example. * Hypothesis: RDP is made up of frames with fixed or variable size * RDP client sends one frame to the socket that is being forwarded using write(socket, frame_buffer, frame_buffer_length). Ie. it gives the operating system network stack the complete frame and asks that all of the frame be sent at once. + Here is the first bug. write() is never required to accept the complete data it is given. The OS may only be able to accept five out of 4096 bytes and will then only take five bytes, and the application must then send the remaining 4091 bytes later. If the bug is what Henrik describes then RDP would not tolerate this. That actually makes me somehow suspect that the problem lies elsewhere, because this is such a serious bug. * Operating system accepts entire frame of bytes and sends it to your libssh2 application, which libssh2_write()s it to the direct-tcpip channel. * The server is waiting for the server OS to receive data, the RDP server has called read(socket, frame_buffer, frame_length) and what Henrik means is that the RDP server depends on always receiving one complete frame here. + Here is the second bug. read() is exactly like write() and nothing can be assumed about the number of bytes that will be returned, the only thing you can be sure of with TCP is that the order of bytes will be the same as on the sender, and that no bytes will have been lost. Both sender and receiver operating systems and hardware and any number of network equipment between sender and receiver can cause asymmetry between number of bytes in write() and read() in this example. This is a hard fact of using TCP. * Now, since the socket is not a direct connection but going through an ssh channel the one write has become two writes within the ssh layer, in order to fit ssh protocol requirements. * The RDP server receives only half the frame from it's read() and starts processing it directly, without waiting for the second half of the frame to arrive, which it would do in a subsequent call to read(). This type of problem demonstrates fundamental lack of understanding of TCP, and although Microsoft are not the most technically bright I don't think they've made a mistake like this. It would be good for you to do more tests with open source software. In particular I suggest running an open source RDP client such as http://www.rdesktop.org/ to get another data point and to be able to do more in-depth debugging. I suggest you also run wireshark on both sides of the tunnel to investigate what goes in and comes out of the tunnel, and then compare this with a straight RDP connection not using a tunnel. //Peter _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
