Enable decoupling of acceptClientConnection and delegate.onAccept

[djones6]

Description

I have introduced an optional parameter invokeDelegate to acceptClientConnection(), that can be used to defer the invocation of delegate?.onAccept(socket).

A new function, invokeDelegateOnAccept(socket) is introduced to perform the call to the delegate, which will either be called by acceptClientConnection(invokeDelegate: true) (equivalent to the previous behaviour), or by the application directly following a call to acceptClientConnection(invokeDelegate: false).

Motivation and Context

The delegate.onAccept() function may block until the client transmits the SSL handshake. In the case of a badly behaved client (trivially, telnet localhost <ssl port>), this could be indefinite.

Since the only way for the application to know whether an incoming connection is available to be accepted is to block on acceptClientConnection(), this effectively leads to preventing any further connections from being accepted when a badly behaved client connects.

By decoupling the accept and the SSL_accept parts of the process, there is an opportunity to perform the latter on a separate thread, to avoid blocking the main listener thread, which can continue to loop around acceptClientConnection().

Resolves Kitura/BlueSSLService#40

How Has This Been Tested?

I ran the Socket tests and they passed.

I tested with a Kitura-based application which uses SSLService, driven under load (50 concurrent clients from wrk) and the application functioned correctly. I tested on both Linux and Mac.

I also verified (with an appropriate change to Kitura-net) that, when creating a bad connection (as described above), the listener was no longer prevented from accepting further well-behaved connections.

Checklist:

• I have submitted a CLA form
• If applicable, I have updated the documentation accordingly.
• If applicable, I have added tests to cover my changes.