Thanks for the feedback. I've decided to split nsopenssl into two
modules. The nsopenssl module will now be entirely focused on
AOLserver's comm-driven connections. The nshttps module will focus on
creating and using SSL connections using a Tcl API.

I've made the decision to split this effort in two for the following

1. The nsopenssl codebase is becoming unwieldy to develop and maintain.
Having three types of SSL connections, one of which is the "normal"
comm-driven type, makes the codebase rather complex.

2. The nsopenssl 2.x Tcl API supports Tcl commands that work with
comm-driven conns, but that do not work with SSL conns generated by the
nsopenssl Tcl API itself (I'm talking about ns_openssl_sockopen,
ns_openssl_sockcallback, etc.). To support non-comm-driven connections
I have to use thread-local storage to keep track of SSL conn
structures, making the code even more complicated.

3. The https.tcl module is a hack. Based on recent discussions I've
been watching here, it has problems, some of which originate with itself. https.tcl will be replaced with

4. Most people who run nsopenssl only want the ability to drive
AOLserver comm-driven connections anyway, and aren't interested in
creating their own SSL servers and clients using nsopenssl's Tcl API.

5. The configuration file is becoming too complex in order to support
SSL contexts separately from SSL drivers and connections.

6. Having nsopenssl focus on the comm-driven connections will allow me
to focus on its performance. The performance of non-comm-driven
connections is not a major issue since there are not as many of these
types of connections, and there isn't a user sitting at the other end
of them; usually you use these to connect to another SSL host.

7. Virtual servers in AOLserver 4.0 adds a lot more complexity to the
code -- virtual server state must be kept to ensure that one virtual
server cannot access another virtual server's structures and data.
Having separate code bases will allow me to focus on the security of
the comm-driven nsopenssl module much more effectively.

8. The non-comm-driven SSL connections rely on Tcl channels so that you
can use puts, gets and friends on them. The channel code adds
complexity to nsopenssl that is not required for the comm-driven

9. Testing has become a pain. Every change requires that I test both
the comm-driven connection capability and the non-comm-driven
capabilities. While much of this testing can be automated, it is
important that the comm-driven capability is extensively tested on its

The only downside to separating the two modules is that a significant
portion of the code will be duplicated. At this point I don't really
care about that and will revisit whether I want to have both modules
generated from (some) common files, or if I want to turn the common
portions of both into a loadable library on its own after we have some
experience with the modules in operation. In any case, both modules
will retain their separate identities.

For the confused, a "comm-driven" connection is one that is actually
serviced by AOLserver core, over which I overlay the SSL portion.
Non-comm-driven connections are those where the sockets and SSL
overlays are both generated and maintained by the nsopenssl module

I have already gutted nsopenssl and I will be releasing the slimmed
down, tighter version of nsopenssl first. nshttps will follow.


On Monday, September 29, 2003, at 09:28 PM, Bart Teeuwisse wrote:

Thanks for explaining the nsopenssl config section Scott. Let me give
some feedback of what I've found so far.

Nsopenssl appears to perform well for the most part. However, nsopenssl
writes several empty error messages to the log. Can't tell what they
related to.

More importantly though making a client connection using ns_httpsopen
results in the following error:

    [29/Sep/2003:18:14:58][20762.65541][-conn:demo::0] Error: :
error creating sslconn->ssl structure

The server subsequently hangs and doesn't respond to requests anymore.


-- AOLserver -

To Remove yourself from this list, simply send an email to
<[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the
Subject: field of your email blank.

AOLserver -

To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of 
your email blank.

Reply via email to