Re: [Omaha.pm] IO::Multiplex + IO::Socket::SSL ?

[Jay Hannah <jay@jays.net>]

Here was Steffen's response. No response from Rob... I don't think my 
company wants me to spend the time it would take to get into the guts of 
this, so I think maybe I'm SOL... Ugly work-around time...?

j



From: Steffen Ullrich [mailto:Steffen_Ullrich@genua.de]
Sent: Tuesday, July 24, 2007 6:53 AM
To: Jay Hannah
Cc: bbb@cpan.org; omaha-pm@pm.org
Subject: Re: IO::Multiplex + IO::Socket::SSL ?

Hi,

Looks like IO::Multiplex assumes that an accept(2) either fails permanently
or succeeds immediatly, which is usually the case, because the kernel
already established the connection and just needs to give a new file
descriptor to user space.

But with an SSL socket it is different, because accept not only needs to
establish the TCP connection but it also does the SSL handshake.

With the "old" IO::Socket::SSL ( <= version 0.97 ) accept would block 
for the
handshake, even if the socket was set to non-blocking. With the newer 
version
accept returns EAGAIN and should be called again later. Depending on the
value of $SSL_ERROR it should be called again when the fd gets readable
(SSL_WANT_READ) or writable (SSL_WANT_WRITE).
But the best thing would be to call accept only on the underlying
IO::Socket::INET object and then upgrade the result with accept_SSL,
because only in this case one could handle multiple accepts in parallel.

But even then I have doubts, that IO::Multiplex works fine with
IO::Socket::SSL. It uses POSIX::read and POSIX::write to write directly
to the file descriptors instead of using sysread und syswrite, which
wrap around SSL_read and SSL_write from openssl. So it would maybe
establish an SSL connection but then write unencrypted data to it which
the peer does not expect.

Regards,
Steffen