SSLSocketChannel (for Dean & anyone else interested in the topic)

Question

In my SSLSocketChannel implementation I've come across the following problem situation that I'm not sure how to handle.
Assume we have an SSLSocketChannel which provides a write(ByteBuffer) method which both wraps and writes to the channel, much as for SSLSocket.
If data (plaintext) is wrapped into the SSLEngine's netSendBuffer (as ciphertext) and then written to the channel and a short write occurs, part of the ciphertext has been sent, and you must complete this write before any other wraps & writes, otherwise the peer will fail to decrypt the partial ciphertext received.
But, what should be returned to the application by the write which came up short?
You can't return the actual write count because that's measured in ciphertext not plaintext. You can't return zero because part of the ciphertext has been written and you don't want the application to retry the entire write, otherwise the plaintext will be repeated when recovered at the peer. You can't return a value representing the amount of plaintext that has been ciphered and written because you don't know that value, and in fact it generally doesn't really exist because the partially-written ciphertext is generally a function of the entire plaintext buffer, not just the leading piece of it.
So, I conclude that you can't really tell the application about the short write. So you have now gotten a phase behind the application - you have data left to write which it thinks you have already written. You can retry the write before the next wrap operation, and if it succeeds OK, or if it comes up short again now you can return zero (i.e. before you do the next wrap), and so on, and this actually goes on quite well - until it comes time to close the channel.
At the point of closing, you may still have unwritten ciphertext which you must write. You may be in non-blocking mode, so you really shouldn't block until it is written, and if you get a short write again what do you do now? Fail to close (throw an exception)?

Answer 1

Well, you could have close throw the exception, have isBufferEmpty() and flushBuffer() methods, and document that you should always wait until you can select for a OP_WRITE before closing unless you want to check the buffer.
Alternatively you could have a background thread that sends all the stuff in the buffers of closed SSLSocketChannels, but that doesn't seem like that good an idea.