On Mon, 21 Dec 2009 21:44:00 +0800, Craig Ringer
<craig@postnewspapers.com.au> wrote:
> (Re-sent, this time to the list)
>
> On 21/12/2009 9:13 PM, rsmogura@softperience.pl wrote:
>
>> I haven't seen 1.4.2 JDK for ages :), but there is method
>> javax.net.ssl.SSLSocketFactory.createSocket that takes as the 1st
>> argument
>> plain socket, there is no need to "forgot" plain socket (and it can be
>> used, actually it's used for SSL communication with lazy handshake
>> FTPS/SMTPS...).
>
> That's how the PgJDBC driver works - it wraps an existing socket in an
> SSLSocket when SSL negotiation begins. Pg always begins with a plain
> text connection - it doesn't have a separate SSL port - so it has to
> begin with a plaintext connection and then request SSL negotiation using
> a plaintext message.
But I think we can leave plain socket somewhere to call available().
>> Unfortunatly plainSocket can have some available bytes, but
sslsoket.read
>> can return EOF. But this was i saw on SUN JDK is that read(new byte[0])
>> on
>> SSL socket causes process plain data.
>
> I'm pretty sure it also blocks if there's nothing to read. You'd have to
> run that in a background thread to force processing of any pending data
> by the SSL engine. If you're going to do that, you may as well just have
> a dedicated background thread to do all the reading from the socket...
It's not block, I tested on HTTPS.
I think the background thread, especially timer thread is better solution
then sending data to server.