The documentation in IO::Socket::SSL shows how to use sysread in conjunction with it in the section "Using Non-Blocking Sockets". I found that section by searching the documentation for "sysread".

$client_sock is the file handle you are looking for.

Also, you are doing the recv against the listen socket, that is wrong, it should have been $client_sock.

> How to I get a file handle from an IO::Socket::SSL object?

IO::Socket::SSL is both an object and a file handle, similar to IO::Socket::INET, IO::Handle, IO::File etc. This means you can use it as sysread($sock,...) but also $sock->sysread(...).

O.k., boys and girls,

Your contributions made things clearer.

I am not very familiar with SSL, it is not the main task in my project, nevertheless I have to get an SSL-socket to run in non-blocking way.

So, I studied the cited documentation on it and found the following (in the example code):

# with SSL a call for reading n bytes does not result in reading of n
        # bytes from the socket, but instead it must read at least one
+ full SSL
        # frame. If the socket has no new bytes, but there are unproce
+ssed data
        # from the SSL frame can_read will block!

        # wait for data on socket
        $sel->can_read();
[download]

I am a little bit confused. My app must not block, so, if I would integrate the sample code or similar into my while-loop, I COULD run into problems due to a blocking can_read()?

Or am I wrong?

And: If am right, how could I workaround this problem?

Could You please explain the cited text of the documentation in the context of my problem.

Cheers

Bloehdian

If you are using non-blocking sockets you usually have some kind of event loop, i.e. read on the socket only if your event loop triggered the event that the socket is readable. Such an event loop is done by $sel->can_read in case you are using IO::Select. But if you use other event loops like for example kqueue, EV ... the exact syntax of getting the "socket readable" from the event loop differs.

The important difference between a normal socket and a SSL socket is that for a normal socket data availability is handled fully inside the OS kernel and the event loop will thus return the data available event if and only if data are available (or socket closed).

With SSL sockets instead a large part is handled in user space and due to the SSL framing of data it can happen, that a data available is shown by the OS socket based event loop even though a sysread will not result in any data. This is the case if for example 1500 bytes could be read from the socket but the SSL frame had a size of 6000 bytes, i.e. more data are needed to decrypt the SSL frame and return the data inside sysread. It could also happen, that the event loop does not signal data availability but a sysread would actually return data. This happens for example if you do a sysread of 500 bytes but the SSL frame containing these 500 bytes had actually 1000 bytes in it. In this case the 500 bytes are returned inside the sysread and the rest is kept inside the SSL object in user space. A check against the kernel socket will not show that there are still data available but a check with $ssl->pending will show that there are still data pending inside the SSL object for another sysread.

A ->can_read(0) does not block, but only do the read if it returns your read filehandle.