On Tue, Jun 27, 2000 at 02:54:04PM -0400, Bill Rebey wrote:
> The product is a poor man's software VPN. A Server (the thing I'm writing)
> accepts local, clear connections, consults a routing table that is part of
> that Server's configuration, sets up an SSL connection with another Server
> as indicated in the routing table, and requests that the Remote server
> connect to a target application at the other end. Data is then allowed to
> flow from an application at one end, through the pair of Servers via SSL,
> and out to the application at the other end.
>
> Each server has two threads per connection, one doing a blocking read on the
> local port, the other doing a blocking read on the SSL port. When data
> shows up at one, it is written to the other. It's very efficient and very
> compact, involves no polling, maximizes throughput, and very CPU friendly.
You don't need polling (i.e. busy waiting) when multiplexing in a
single thread per connection, either; the obvious method is to use
non-blocking I/O and to select() according to the combined results
of SSL_get_error and the I/O operations on the other connection.
(A difficulty is that if you use both SSL_read and SSL_write
in the same iteration of the main loop, then you don't know
if the SSL_get_error result of the first call is still valid
after the second one. But if you retry both when one
of their SSL_get_error conditions is true (SSL_ERROR_WANT_READ
or SSL_ERROR_WANT_WRITE if both occured), then you won't end
up busy waiting.)
> Apparently, though, OpenSSL won't allow the thread that
> "reads-clear-and-writes-SSL" to write on the SSL that the other thread is in
> a blocking SSL_read on. I don't know why, but supposedly that limitation is
> real.
>
> Any ideas?
>
> More importantly, do you know why this limitation exists at all? I would
> rather fix the problem than run from it.
The problem is handshakes. Each side of the SSL connection may
request a new handshake whenever it feels like it. Thus both
SSL_read and SSL_write may have to continue a handshake,
so they are not independent of each other even if the initial
handshake is over.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
