This sounds like a pretty radical change. How about we all discuss further during the Thursday AOLserver chat?
Scott Goodwin wrote on 9/29/03, 10:32 PM: > 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. > -- 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.
