(Return to web page)

Post Comments

Comment Guidelines

All comments are moderated. The goal is not simply to eliminate obnoxious stuff, but to only allow useful on-topic discussions -- it's not a place to hang out. Moderation time is expected to be a day or two in most cases, but I do take vacations.

Your comments will be read by me, but they may not be posted. In particular, saying thanks or "you rock" or whatever is certainly appreciated, but I won't add it to the public comments unless there's useful information there for others. Comments that say "you suck" are much more likely to be posted, as long as a reason is given that's somewhat productive. Posting a comment is not a promise to keep it here forever, I may remove any or all comments at any time.

I may edit postings for simple and obvious errors, and I may remove profanity. Only listed HTML terms are allowed in messages. Name and email address will be fully stripped or quoted to prevent HTML tag usage and other possible abuses.

You can provide either a public or a private email address, or none at all. Private addresses are good if you want a personal response from me. I do not provide any automatic notification of new comments.

There is no re-editing after posting, however you can simply post again, and hopefully I'll notice this in moderating, and will post the latest version. If your post is already up, just add another post with any corrections, and in most cases I'll pub up both posts, rather than hand- correcting the original.

*Email addresses are scrambled and encoded in a non-mailto URL. People with javascript see a normal working email link, but robots (and people) without javascript see a URL with gibberish in it. This link is a sample with working javascript (clicking should bring up a mailer), and this link is appoximately how it looks without javascript (click to see how your address will look to people without javascript). If you view the source, you'll see they're all gibberish.

6 comments:

At 2008/12/20 13:23
Scott Gifford wrote:

Have you tried making the sockets nonblocking, like this:

$sock->blocking(0);

For me at least, that seems to give the effect you're looking for.

At 2008/12/20 13:34
wrote:

Yes, I've tried that. It sort of works, but the behaviour is subtly different. Standard socket reading behaviour is to block until it reads something. The bad behavior I was getting was to block until it reads everything that was requested. With your non-blocking suggestion, it's possible to return after reading nothing.
A select() would in theory eliminate this issue, but when I tried non-blocking, I wasn't getting correct behavior from the select() -- it would come up in the select() when nothing was there to be read; though admittedly I didn't try to thoroughly debug that issue.
tom

At 2008/12/20 13:59
Scott Gifford wrote:

Ah, I see. Select and SSL don't always mix well, but I have had pretty good luck using nonblocking sockets with select() and sysread(), just ignoring errors EAGAIN and EINTR returned by sysread().

At 2010/01/09 20:04
Leif Pedersen wrote:

I'm navigating this chaos, and it seems that select() with SSL is supported (you would think Lighttpd proves that!). Anyway, you have to avoid some assumptions. Do not assume a read call only reads or a write call only writes. Do not assume reading zero bytes means EOF. A read may return zero if it only processed the beginning of a header but no application data, for example. A read call may need to write, and a write call may need to read because either side may initiate a new handshake midstream. So be sure to set O_NONBLOCK so that you don't accidentally block for write when you call read. Also pay attention to the error codes, which will indicate whether it needs to read or write next, and update select()'s fdset to watch for what SSL needs. Many iterations may be necessary before the application's data stream progresses.

I found this in docs about the underlying C libraries: http://www.openssl.org/support/faq.html#PROG10 and http://www.openssl.org/docs/ssl/SSL_get_error.html

That said, I haven't actually gotten anything cobbled together yet. I'm writing something that is a single thread and is absolutely never allowed to block unless there's actually nothing to do. I'm trying to stick with the lowest-level libraries I can because the more wrappers there are the more likely it is that I'll trip over some bug or limitation. Often those wrappers are far more complicated than necessary, but sometimes they really do a lot of necessary work for you.

Have you had any more recent findings?

At 2010/01/10 19:03
Leif Pedersen wrote:

I finally finished putting the pieces together, and wrote up my solution in a longer article. Thanks for sharing your findings, they saved me some time. Here are my findings: http://devpit.org/wiki/OpenSSL_with_nonblocking_sockets_(in_Perl)

At 2012/02/14 10:52
wrote:

How do you use IO::Socket::SSL in a client software to connect to a server through a proxy? Searching through the web, I read somewhere that NET::SSL provides the support for proxy, but not IO::Socket::SSL. Do you know or had any experience on this? Thanks,

End Comments

Return to web page.

At 2008/12/20 13:23 Scott Gifford wrote:	Have you tried making the sockets nonblocking, like this: $sock->blocking(0); For me at least, that seems to give the effect you're looking for.
At 2008/12/20 13:34 wrote:	Yes, I've tried that. It sort of works, but the behaviour is subtly different. Standard socket reading behaviour is to block until it reads something. The bad behavior I was getting was to block until it reads everything that was requested. With your non-blocking suggestion, it's possible to return after reading nothing. A select() would in theory eliminate this issue, but when I tried non-blocking, I wasn't getting correct behavior from the select() -- it would come up in the select() when nothing was there to be read; though admittedly I didn't try to thoroughly debug that issue. tom
At 2008/12/20 13:59 Scott Gifford wrote:	Ah, I see. Select and SSL don't always mix well, but I have had pretty good luck using nonblocking sockets with select() and sysread(), just ignoring errors EAGAIN and EINTR returned by sysread().
At 2010/01/09 20:04 Leif Pedersen wrote:	I'm navigating this chaos, and it seems that select() with SSL is supported (you would think Lighttpd proves that!). Anyway, you have to avoid some assumptions. Do not assume a read call only reads or a write call only writes. Do not assume reading zero bytes means EOF. A read may return zero if it only processed the beginning of a header but no application data, for example. A read call may need to write, and a write call may need to read because either side may initiate a new handshake midstream. So be sure to set O_NONBLOCK so that you don't accidentally block for write when you call read. Also pay attention to the error codes, which will indicate whether it needs to read or write next, and update select()'s fdset to watch for what SSL needs. Many iterations may be necessary before the application's data stream progresses. I found this in docs about the underlying C libraries: http://www.openssl.org/support/faq.html#PROG10 and http://www.openssl.org/docs/ssl/SSL_get_error.html That said, I haven't actually gotten anything cobbled together yet. I'm writing something that is a single thread and is absolutely never allowed to block unless there's actually nothing to do. I'm trying to stick with the lowest-level libraries I can because the more wrappers there are the more likely it is that I'll trip over some bug or limitation. Often those wrappers are far more complicated than necessary, but sometimes they really do a lot of necessary work for you. Have you had any more recent findings?
At 2010/01/10 19:03 Leif Pedersen wrote:	I finally finished putting the pieces together, and wrote up my solution in a longer article. Thanks for sharing your findings, they saved me some time. Here are my findings: http://devpit.org/wiki/OpenSSL_with_nonblocking_sockets_(in_Perl)
At 2012/02/14 10:52 wrote:	How do you use IO::Socket::SSL in a client software to connect to a server through a proxy? Searching through the web, I read somewhere that NET::SSL provides the support for proxy, but not IO::Socket::SSL. Do you know or had any experience on this? Thanks,