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 reasons:
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 nsopenssl.so itself. https.tcl will be replaced with nshttps.so.
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 connections.
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 own.
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 itself.
I have already gutted nsopenssl and I will be releasing the slimmed down, tighter version of nsopenssl first. nshttps will follow.
/s.
On Monday, September 29, 2003, at 09:28 PM, Bart Teeuwisse wrote:
Thanks for explaining the nsopenssl config section Scott. Let me give you 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 are 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: : nsopenssl: error creating sslconn->ssl structure
The server subsequently hangs and doesn't respond to requests anymore.
/Bart
-- AOLserver - http://www.aolserver.com/
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 - http://www.aolserver.com/
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.
