Comments on the patch of 8 Jan 2010:
I think you should rename SslIoShim/ClientSslIoShim/ServerSslIoShim to reflect that these are actually all AsynchIO implementations:
So maybe use names: SslAsynchIO/ClientSslAsynchIO etc.
I like the implementation in SslProtocolFactory except separating the Client and Server IO is somewhat clunky.
I really don't like the way that SslConnector works though, there's a lot of code just to put in place a few necessary interceptions. Also the Connectors were never intended to be inherited from just to implement an interface.
I think this could be handled better by modifying TCPConnector to take an abstract factory that knows how to create AsynchIO/AsyncConnector objects that are relevant for the protocol. Then I'd say it'd be better to recast some of the logic in SslConnector as an implementation of AsynchConnector. Does that make sense? Of course this does mean a change in the protocol plugin API, but an improvement I think.
Long term I'd like to eliminate the distinction between the ..Connector and ..ProtocolFactory plugins and be able to use just one for both client and server - this would likely be descended from the server code which already does both server and client ends.
AsyncIOBufferBase::squish() this could be better named? And as you've added it, perhaps you could make the logic in AsynchIO::unread() use it?
In the windows code: It is the general code convention that all system calls are explicitly called out by being explicitly in the global namespace, viz ::InitializeSecurityContext() to give the first example I came across.
Personally I'd put both the Client "shim" and the Server "shim" code in the same implementation file (but that's mostly a my own preference)