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.
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.
Any ideas?
More importantly, do you know why this limitation exists at all? I would
rather fix the problem than run from it.
-----Original Message-----
From: Lenny Foner [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 27, 2000 2:43 PM
To: Bill Rebey
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Does anyone know how to fix Multithreading??
Date: Tue, 27 Jun 2000 13:47:25 -0400
From: Bill Rebey <[EMAIL PROTECTED]>
Richard,
Thanks for the reply.
If I understand you correctly, you are suggesting that I put wrappers
around
SSL_write and SSL_read that make them exclusive operations. This
effectively makes the thing single-threaded again. I need to have
blocking
[you mean, "nonblocking"?]
Reads in effect all the time on one thread while I'm writing on another.
I
can't very well single-thread the reads and writes.
Any other ideas?
What are you -really- trying to do?
In other words, what's the overall goal here? I'm trying to get you
to step back and describe the toplevel idea, and thereby see if maybe
there is a way around the problem in some way you haven't considered.
Right now, you're boxed into "I must have multithreading and must be
able to have multiple outstanding reads and writes that are pushing
data simultaneously." Maybe there's a way around this constraint, but
none of us know what you're doing.
Failing that, you may just have to implement fine-grained multithreading
support in OpenSSL. This sounds like it's more work than you're ready
for, and I don't blame you at all. But without doing that, it sounds
like your fundamental design is going to have to change, and like
maybe you should have done a quick & dirty multithreading test before
committing lots of design time (much less implementation time). Lots
of things don't handle threads correctly; a conservative design would
test a simple prototype on all the OS's you expect to deploy on, first.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
