On Sun, 2008-04-20 at 01:48 -0400, Joshua Kramer wrote: > > If you have separate listening connections which are either wholly SSL > > or wholly not it makes more sense (to my mind) to keep the > > implementations separate (but possible to use inheritance if that makes > > sense) and to have a new SSL specific Acceptor to be the factory for the > > new SSL connections. > > Can you describe, a bit more, the structure of the Acceptor? It appears > (from the file TCPIOPlugin.cpp, line 72) that the Acceptor starts > listening before we tell it what port we want it to listen on. (It > actually appears that there is no 'Acceptor' that runs as itself - the > Acceptor class is used to derive the AsynchIOAcceptor.
Acceptor is an abstract class which does not have any instances of its own - it's purpose is to define an interface for starting connections. At this point the abstract class is misnamed as it is also used for making connections from the broker as well as accepting them - so this interface may well be renamed to something better fitting sometime soon. The main broker object has a list of Acceptor objects and it uses all of the Acceptor to accept connections [in Broker::accept()] this happens currently by calling by the run() method of acceptor [probably should be called accept() now]. The parameters for the acceptor have already been set by the Acceptor's constructor. The Acceptor is constructed using the plugin architecture of the broker. > > Where do we set config information, or at least pass it on to the Acceptor > and/or Socket objects? This is important, because for an SSL acceptor, we > need to set and get: > > -Permitted and preferred Cipher Algorithms > -Do we ask for client certificate? > -Do we require client certificate? > -Location of key and certificate databases > -One of US, French, or International nationality settings > -Callback functions to get passwords for certificates > -Port > -Host You can use the option processing of the broker to provide your SSLAcceptor with the parameters you require. See TCPIOPlugin::initialize() for how we get the port to listen to. In this case it seems that you'll want to add your own commend line options to be processed you can do this by implementing a getOptions() member in your xxPlugin - see ClusterPlugin.cpp for how this works. The options infrastructure uses the boost options processor and is quite comprehensive. > So far, I've added SSLAcceptor, SSLAsynchIO, and SSLSocket classes. Soon > after I have answers to the above I should have some code for you to > review. I'd guess that you don't really need to reimplement the AsynchIO code specially for SSLSockets - if they subclass Sockets correctly then the AsynchIO code should work with them as is (this may of course be subject to some bug fixes!) You will however need to implement your own SSLIOPlugin.cpp along the lines of TCPIOPlugin.cpp to register the SSL protocol capability. Looking forward to seeing your patches Andrew
