Date: Tue, 27 Jun 2000 14:54:04 -0400
From: Bill Rebey <[EMAIL PROTECTED]>
Thanks, Lenny.
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.
Ah ha...
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.
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.
This is beginning to ring vague bells about something I ran into under
HPUX (I think---mighta been Irix or Linux) wherein actually trying to
do reads & writes on the same FD tended to duplicate characters or
have a byte crosstalked from one to the other. This was not an SSL
problem at all---it was a problem in stdio or some such idiocy. It
was years ago, though, so I could easily be misremembering what the
exact problem was---I just remember having to kludge around it. There
may have been some involvement with ungetc() as well---I can't remember.
Any ideas?
Well, how about setting up -two- SSL's between each server? Use each
one half-duplex, e.g., always write to SSL channel A, and always read
from SSL channel B. If the actual thread-unsafeness has to do with
only the same SSL instance, not using multiple such instances at the
same time, then this should work, at the cost of one more FD per
channel per server. Yeah, it's gross, but so is making your own VPN
instead of just buying one. Or have I missed something here? :)
More importantly, do you know why this limitation exists at all? I would
rather fix the problem than run from it.
I don't know. I haven't looked carefully at that code, certainly not
since it was SSLeay. I presume that it's there, in part, because it's
quite difficult to write correct thread-safe code, because it's hard
to write -any- concurrent code using a language with as such poor
support for it as C provides, and that therefore the implementors just
said, "we'll deal with this later."
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
