A Connection that acts as an interceptor between an EndPoint providing SSL encrypted data and another consumer of an EndPoint (typically an {@link Connection} like HttpConnection) thatwants unencrypted data.
The connector uses an {@link EndPoint} (typically {@link SelectChannelEndPoint}) as it's source/sink of encrypted data. It then provides an endpoint via {@link #getDecryptedEndPoint()} toexpose a source/sink of unencrypted data to another connection (eg HttpConnection).
The design of this class is based on a clear separation between the passive methods, which do not block nor schedule any asynchronous callbacks, and active methods that do schedule asynchronous callbacks.
The passive methods are {@link DecryptedEndPoint#fill(ByteBuffer)} and {@link DecryptedEndPoint#flush(ByteBuffer)}. They make best effort attempts to progress the connection using only calls to the encrypted {@link EndPoint#fill(ByteBuffer)} and {@link EndPoint#flush(ByteBuffer)}methods. They will never block nor schedule any readInterest or write callbacks. If a fill/flush cannot progress either because of network congestion or waiting for an SSL handshake message, then the fill/flush will simply return with zero bytes filled/flushed. Specifically, if a flush cannot proceed because it needs to receive a handshake message, then the flush will attempt to fill bytes from the encrypted endpoint, but if insufficient bytes are read it will NOT call {@link EndPoint#fillInterested(Callback)}.
It is only the active methods : {@link DecryptedEndPoint#fillInterested(Callback)} and{@link DecryptedEndPoint#write(Callback,ByteBuffer)} that may schedule callbacks by calling the encrypted{@link EndPoint#fillInterested(Callback)} and {@link EndPoint#write(Callback,ByteBuffer)}methods. For normal data handling, the decrypted fillInterest method will result in an encrypted fillInterest and a decrypted write will result in an encrypted write. However, due to SSL handshaking requirements, it is also possible for a decrypted fill to call the encrypted write and for the decrypted flush to call the encrypted fillInterested methods.
MOST IMPORTANTLY, the encrypted callbacks from the active methods (#onFillable() and WriteFlusher#completeWrite()) do no filling or flushing themselves. Instead they simple make the callbacks to the decrypted callbacks, so that the passive encrypted fill/flush will be called again and make another best effort attempt to progress the connection.