On 21/12/2009 5:41 PM, rsmogura@softperience.pl wrote:
> One of disadvantage of checking plain socket is that available or read
> uses "under" SSL Layer bytes, which include encrypted data, handshaking
> data (the SSL supports renegotiation and session changes...?), and other
> protocol specific, with no sense for application. But generally when whole
> SSL socket bytes are read, then plain socket _should_ be "empty" too.
Yes - when the plain socket is empty, the SSL socket is also empty. That
does not imply the inverse, though.
If the plain socket is NOT empty, that does not mean that the SSL socket
is also NOT empty. As you said, the plain socket underlying the SSL
socket may have bytes available() but they're just an SSL re-negotiation
request or the like. So if you try to read from the SSL socket in this
case, you will still block, even though the underlying socket did have
bytes available to read.
For available() on an ssl socket to work, you would need to implement it
by using the underlying SSL implementation to read any data buffered on
the plain socket (if any), process it, and return the amount of client
data in it if any. So if the underlying socket's available() returns 0,
your SSL available() returns 0 also. Otherwise it reads what's there,
decodes it if it can, and returns how much readable user data it got.
Unfortunately this can't be done with Java's SSLSocket, since you have
no access to the underlying SSL engine implementation. It *can* be done
with the Java 5 java.nio API and SSLEngine, possibly via a wrapper like
SSLSocketChannel, though. In fact, if you're building on java.nio and
SSLSocketChannel you can use exactly the approach described above.
Really, the requirements to make this work are:
- a non-blocking SSL socket; or
- a thread that can afford to block on the socket
--
Craig Ringer