Possible option to call transport layer from user software to avoid problems with non-blocking reads

Michael Eisele r6502a at gmail.com
Tue Apr 5 21:15:36 CEST 2022


Hi all,

I'm a new libssh2 user, using it on Windows with my own Qt-based terminal
emulation.

In my software I use the SSH socket in non-blocking mode, utilizing
WaitForMultipleObjects() to wait for socket data and some other events.

The software reads the SSH channels until LIBSSH2_ERROR_EAGAIN is received.
When EAGAIN is returned it again starts waiting for new socket data to
arrive.

This works quite well as long as only one SSH channel is in use (the PTY
channel).

But when there is more than one channel open (X11 forwarding) then I have a
problem: My software calls  libssh2_channel_read_ex() for each channel to
get new data.

The function calls _libssh2_channel_read() which calls
_libssh2_transport_read() which might  read new socket data (SSH packets)
by calling LIBSSH2_RECV().

The problem now is, that there might be new packets for any other open SSH
channel. So each call to libssh2_channel_read_ex() might invalidate the
 EAGAIN result of any other SSH channel read done before.

This behavior makes it more or less impossible to read all SSH channels
until EAGAIN is returned for all channels and there is no more pending
channel data before entering wait again.

I found two possible workarounds:

1) calling libssh2_channel_window_read_ex() to check each channel for
pending data

2) using the RECV-callback to ensure that there is only one single read for
new socket data after WaitForMultipleObjects() has returned.

At the moment I use option 2) so it's now working fine.

I assume that other users might run into similar problems. A possible
solution/improvement might be to add an option to call the transport layer
_libssh2_transport_read() directly from application and disable reading
from socket on channel read.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.haxx.se/pipermail/libssh2-devel/attachments/20220405/d0a12ab7/attachment.htm>


More information about the libssh2-devel mailing list