Recently, we enhanced our server implementation that used ACE_SOCK_Acceptor to also support SSL by using the ACE_SSL_SOCK_Acceptor, and have it working well with one exception. I wanted to describe the limitation I encountered with the ACE_SSL_SOCK_
Acceptor, and ask if any consideration can be given to addressing it.

Our implementation provides for multiple server processes that load-balance the number of connected clients per process by exchanging the "listener" FD between those processes via Unix IPC sendmsg() and ioctl(). That FD is picked up by the server process'
ACE_SOCK_Acceptor by calling set_handle(FD), which then allows for its use by that ACE_SOCK_Acceptor.accept(). This all works fine using ACE_SOCK_Acceptor, but it doesn't work with ACE_SSL_SOCK_Acceptor. The problem appears to be that our set_handle()
call only updates the ACE_SSL_SOCK_Acceptor so its accept() method uses that FD for its SSL_accept() call that it makes. However, its accept() method first invokes its own 'private' ACE_SOCK_Acceptor.accept(), and that object has not been updated with
that same FD as it needs to be.

It seems that a solution could be to enhance the ACE_SSL_SOCK_Acceptor class to provide an 'override' of the set_handle() method that also calls set_handle() on its 'private' ACE_SOCK_Acceptor instance as well as updating its own ACE_Handle.

Comments?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)