Joshua Kramer wrote:
Andrew Stitcher wrote:
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
Andrew,
I've attached a starting point for SSLIOPlugin.cpp. So far I have the
init routines done, and I'm working on the socket routines next.
Let me know if I'm on the right track!
Thanks,
-J
looks like you are going in the right direction
Carl.
