Ticket #161 (new enhancement)

Opened 2 years ago

Last modified 2 years ago

Create API for socket I/O in application

Reported by: stuge Owned by:
Priority: normal Milestone:
Component: API Version: 1.1
Keywords: blocking non-blocking timeout hang select proxy Cc:
Blocked By: Blocks:

Description

libssh2 always uses non-blocking I/O and creates blocking semantics internally, but it doesn't always work.

#123, #160 and possibly also #159 are effects of this and examples/direct_tcpip.c is also affected; it only works correctly because it uses libssh2 in non-blocking mode, thus bypassing the internal blocking in the library, but it must still wake up every 100ms and do polling, which is pretty ugly.

This is an unfortunate problem, since select() could have been used to successfully handle all file descriptors if libssh2 relied on the operating system to operate correctly in blocking mode.

I want an API that works with both blocking modes, meaning we either fix the current implementation to block according to operating system settings for the underlying socket, or create a new API that is blocking agnostic by definition.

This ticket suggests an API that moves socket I/O out of libssh2 and lets applications give and get bytes for the sshd connection using new library functions. This shifts more work onto apps, but on the other hand it greatly simplifies proxying of SSH connections in direct-tcpip channels, since libssh2 currently requires a file descriptor for each sshd connection and a direct-tcpip connection only gets us a LIBSSH2_CHANNEL. (This can not be worked around in a portable manner using pipes, so portable apps must currently use a very inconvenient loopback TCP socket.)

There could be helper functions in libssh2 to make the API as easy as possible to use in typical scenarios. It could even enable easy multihop proxying.

Change History

comment:1 Changed 2 years ago by stuge

  • Keywords blocking non-blocking timeout hang select proxy added

comment:2 Changed 2 years ago by bagder

Just let me clarify that libssh2 always had this problem, even before when it didn't use the non-blocking approach with an internal wait, although then it was due to multiple socket-operations within libssh2 but it would/could lead to more or less the same effect.

comment:3 Changed 2 years ago by bagder

I'd like to mention that my suggested API enhancement is an alternative solution to the problem referred to in this ticket. My post is here:

http://www.libssh2.org/mail/libssh2-devel-archive-2010-06/0040.shtml

Note: See TracTickets for help on using tickets.