--000e0cd6a95c231a370464be4f5e
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Thu, Feb 26, 2009 at 2:14 AM, Tanaka Akira <akr / fsij.org> wrote:

> Does it care the I/O buffer implemented in
> ext/openssl/lib/openssl/buffering.rb ?
>

I'm not certain.  What exactly does this do?


> What's happen if nonblocking methods and blocking methods are used both?
>

This (monkey) patch uses the core nonblocking functionality of OpenSSL, so
it should be possible to use blocking and nonblocking methods
interchangably.


> Note that IO#read_nonblock reads from IO buffer if it is not empty.
>  IO#write_nonblock flushes IO buffer.
>
> See read_nonblock implementation in
> ext/openssl/lib/openssl/buffering.rb in ruby-1.9.2dev.
>

What is the present behavior if IO#read_nonblock is called when the socket
needs writable to continue?  How are cases like SSL renegotiation presently
handled?

Different classes makes OpenSSL nonblocking methods and
> IO/Socket nonblocking methods incompatible.
>

Yes, unfortunately the concerns of nonblocking SSL are different than they
are from a standard socket.  Standard nonblocking sockets never expect the
socket need be ready for an I/O operation which wasn't requested.
Unfortunately the requirements of SSL necessitate waiting on readability or
writability regardless of which operation was requested.  The socket may
need to be writable in a case where read_nonblock was requested, and vice
versa.


> I think Errno::EWOULDBLOCK object extended by some module,
> IO::WandRead or IO::WantWrite, is better.
>

I can certainly use those exceptions instead.

-- 
Tony Arcieri
medioh.com

--000e0cd6a95c231a370464be4f5e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class="gmail_quote">On Thu, Feb 26, 2009 at 2:14 AM, Tanaka Akira <span dir="ltr">&lt;akr / fsij.org&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Does it care the I/O buffer implemented in<br>
ext/openssl/lib/openssl/buffering.rb ?<br>
</blockquote><div><br>I&#39;m not certain.What exactly does this do?<br>br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
What&#39;s happen if nonblocking methods and blocking methods are used both?<br>
</blockquote><div><br>This (monkey) patch uses the core nonblocking functionality of OpenSSL, so it should be possible to use blocking and nonblockingethods interchangably.<br>/div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Note that IO#read_nonblock reads from IO buffer if it is not empty.  ¨ÂÏ£÷òéôåßîïîâìïãë æìõóèåÉÏ âõææåò®¼âò<br>
See read_nonblock implementation in<br>
ext/openssl/lib/openssl/buffering.rb in ruby-1.9.2dev.<br>
<div class="im"></div></blockquote><div><br>What is the present behavior if IO#read_nonblock is called when the socket needs writable to continue?How are cases like SSL renegotiation presently handled?<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Different classes makes OpenSSL nonblocking methods and<br>
IO/Socket nonblocking methods incompatible.<br>
</blockquote><div><br>Yes, unfortunately the concerns of nonblocking SSL are different than they are from a standard socket.Standard nonblocking sockets never expect the socket need be ready for an I/O operation which wasn&#39;t requested.Unfortunately the requirements of SSL necessitate waiting on readability or writability regardless of which operation was requested.The socket may need to be writable in a case where read_nonblock was requested, and vice versa.<br>
/div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I think Errno::EWOULDBLOCK object extended by some module,<br>
IO::WandRead or IO::WantWrite, is better.<font color="#888888"><br>
</font></blockquote></div><br>I can certainly use those exceptions instead.<br><br>-- <br>Tony Arcieri<br>medioh.com<br>

--000e0cd6a95c231a370464be4f5e--