Custom Non-Blocking BIO.
I have a custom BIO that I want to be non-blocking. Currently when calling
SSL_connect when using this BIO, it is returning -1, but
calling SSL_get_error after does not return SSL_ERROR_WANT_READ
nor SSL_ERROR_WANT_WRITE.
How does my custom BIO indicate that it supports non blocking IO?
I tried this:
long gdbio_ctrl(BIO* const b, const int cmd, const long num, void* const
ptr) {
DBGPRINTF(BIO CTRL %d:%ld\n, cmd, num);
switch(cmd) {
case BIO_C_SET_NBIO: return 1;
default: return 0;
}
}
but it does not seem to be enough.
Regards,
Keean.
Re: Custom Non-Blocking BIO.
On Sun, Mar 13, 2011, Keean Schupke wrote:
I have a custom BIO that I want to be non-blocking. Currently when calling
SSL_connect when using this BIO, it is returning -1, but
calling SSL_get_error after does not return SSL_ERROR_WANT_READ
nor SSL_ERROR_WANT_WRITE.
How does my custom BIO indicate that it supports non blocking IO?
I tried this:
long gdbio_ctrl(BIO* const b, const int cmd, const long num, void* const
ptr) {
DBGPRINTF(BIO CTRL %d:%ld\n, cmd, num);
switch(cmd) {
case BIO_C_SET_NBIO: return 1;
default: return 0;
}
}
but it does not seem to be enough.
You set the appropriate flags with BIO_set_retry_read(bio) or
BIO_set_retry_write(bio) and return -1 from the BIO read or write routine.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Non-blocking BIO and BIO_do_connect problem.
Hello,
Marek Marcola wrote:
For example:
/* check socket error state - only if val == 0 after this call
* connection is properly established.
*/
len = sizeof(int);
if (getsockopt(fd, SOL_SOCKET, SO_ERROR, (void *) state, len) 0) {
goto err;
}
if (state != 0) {
/* socket state error - setting errno */
errno = state;
goto err;
}
Or maybe I doing too much ?
Yes.
connect() will return 0 on success. From that point on you use can use
readability indication and read() to detect closed/timeout connection.
connect() will return -1/INPROGRESS when it still waiting for the
network layer to conclude the connection attempts. Right now the TCP
layer is automatically retransmissing connection requests (SYN_SENT state).
connect() will return -1 and anything else on failure. Some possible
return values maybe ETIMEDOUT, ENETDOWN, ENETUNREACH, ENETRESET, etc...
But all of these a fatal errors and mean the same thing, but can
provide a finer grained reasoning for the cause of failure.
ETIMEDOUT the connection requests just timed out after maximum retries.
ENETDOWN the local host's network interface is not operational.
ENETUNREACH a remote network returned ICMP network unreachables for the
network.
ENETRESET the request port is not available for inbound connections at
that address.
EHOSTUNREACH a remote network returned ICMP host unreachables for the
address.
I've forget to tell that i'm not doing second connect().
Just:
- connect()
- select()
- getsockopt()
Thanks for information.
Best regards,
--
Marek Marcola [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: Non-blocking BIO and BIO_do_connect problem.
--- Dr. Stephen Henson [EMAIL PROTECTED] wrote: On Sat, Jul 22, 2006, Bu Bacoo wrote: Thanks you both... after correcting my BIO_do_connect (and all read/write following it) - adding retries (as Girish pointed), it works just fine. Now I'll check the errors, mentioned by Darryl, to make it more clear, not just to retry until some counter runs out. By a strange coincidence I added some code to the ocsp application a couple of days ago that covers this situation. What you should do is call BIO_should_retry() if you get = 0 return from BIO_do_connect() in fact until it connects you'll get BIO_should_retry_special() as true. You can loop until you get an error or BIO_do_connect() succeeds but that isn't very efficient and it non portable with the current connect BIO implementation on Windows as I found out when I tried the updated ocsp application with a timeout on WIN32. That should be fixed I suppose. The efficient thing to do depends on the underlying transport. Getting the actual socket description with BIO_get_fd() then calling select() while waiting for a write condition is often done for example. I don't know what is supposed to happen in theory, but in practice I have found select() to be quite a disaster in informing me when a socket becomes writable. I have seen this on both Linux and FreeBSD. select() is very useful and an elegant solution for multiplexing sockets and doing non blocking IO. However it is useful only for getting to know when a socket becomes ready for read. I have seen code in which select() is used for getting to know pending writes. But this is only when we have written and for some reason the write operation does not write the full amount. In this case, we are interested when the socket becomes writeable bcoz we want to finish our write. But if you naively check for write condition on a socke t with select() you will find that it always returns that the socket is writeable. However a tight loop like while() is also inadvisable as it is very inefficient for BIO_do_connect(). Read the man page for SSL_read,read,write and SSL_write. It clearly gives you the particular error messages given by the socket for non blocking scenarios. EINPROGRESS and EAGAIN are errnos that come to mind. But I have always found non blocking IO to be a very advanced use of sockets and my advice will be that you should not attempt if you don't know what you are doing . And as always be creative and try out various combos and let us know what works best. There was a related thread by Darryl few weeks ago. Check in the archives. That will throw some light on how difficult this becomes. All the best! regards, Girish Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Non-blocking BIO and BIO_do_connect problem.
On Sat, Jul 22, 2006, Girish Venkatachalam wrote: --- Dr. Stephen Henson [EMAIL PROTECTED] wrote: The efficient thing to do depends on the underlying transport. Getting the actual socket description with BIO_get_fd() then calling select() while waiting for a write condition is often done for example. I don't know what is supposed to happen in theory, but in practice I have found select() to be quite a disaster in informing me when a socket becomes writable. I have seen this on both Linux and FreeBSD. Yes but this is a special case. It isn't really checking to see if the socket becomes writeable at all. If you check the manual page for connect() on many Un*x variants it will say that if it is called on a non blocking socket and indicates an operation would block (EAGAIN, EWOULDBLOCK error codes for example) then it is possible to wait on that socket for a write condition which will be satisfied when a connection is established. It isn't really a write condition in this case it is a wait until the socket connects condition. OpenSSL BIO logic doesn't indicate this condition with BIO_should_write() instead it uses BIO_should_io_special(). This is to cover the case where some TCP/IP transport implementation might want to wait for a special condition instead of using writeable for this purpose. The WIN32 manual pages are slightly different in that they don't recommend calling connect() in a loop until it completes because different error codes can occur other than WSAEWOULDBLOCK after the first call. This means that looping BIO_do_connect() on a non blocking socket will not currently work in WIN32, we should really change the state machine to cover this. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Non-blocking BIO and BIO_do_connect problem.
Girish Venkatachalam wrote: I don't know what is supposed to happen in theory, but in practice I have found select() to be quite a disaster in informing me when a socket becomes writable. I have seen this on both Linux and FreeBSD. select() is very useful and an elegant solution for multiplexing sockets and doing non blocking IO. However it is useful only for getting to know when a socket becomes ready for read. select() / poll() for writablity on a not-yet-connected socket works reliability. Once it becomes connected (or an error occured because it can't get connected) its writability will be signalled. Your application calls connect() again this time it returns 0 and you stop waiting for connection now and start using the socket to convey data. What is the problem with select() more often than not signalling writability, this is correct. You have to also test if you have data to give select too, so the idiom would be like: FD_ZERO(fdwrite); if(i_have_data_to_write) FD_SET(fd, fdwrite); If you dont have data then you don't ask select() to signal writability, because you don't care about it. I have seen code in which select() is used for getting to know pending writes. But this is only when we have written and for some reason the write operation does not write the full amount. In this case, we are interested when the socket becomes writeable bcoz we want to finish our write. The and for some reason, is because the way socket IO does resource accounting and flow control. Other stratagies like WIN32 Overlapping I/O require the application to do its own resource accounting, if it didn't it may well eat the entire RAM of the machine up if the data source (file on disk) can read data faster than the data target (other end of network connection) can sink the data. With sockets this problem doesn't exist the kernel arbitrates the flow control and resources to enforce that flow control by creating back pressure right into the application. But if you naively check for write condition on a socke t with select() you will find that it always returns that the socket is writeable. Only when (the socket is connected OR in error state) AND the kernel has the minimum low water mark of buffer space free to accept new data. These are all useful circumstances when an application would want to service the socket to do more work or be notified of an aborted connection. But I have always found non blocking IO to be a very advanced use of sockets and my advice will be that you should not attempt if you don't know what you are doing . This is a shame, they really aren't that scary. Darryl __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Non-blocking BIO and BIO_do_connect problem.
Hello,
Girish Venkatachalam wrote:
I don't know what is supposed to happen in theory, but
in practice I have found select() to be quite a
disaster in informing me when a socket becomes
writable. I have seen this on both Linux and FreeBSD.
select() is very useful and an elegant solution for
multiplexing sockets and doing non blocking IO.
However it is useful only for getting to know when a
socket becomes ready for read.
select() / poll() for writablity on a not-yet-connected socket works
reliability. Once it becomes connected (or an error occured because it
can't get connected) its writability will be signalled. Your
application calls connect() again this time it returns 0 and you stop
waiting for connection now and start using the socket to convey data.
I agree, and what I may suggest more is to check socket state
after successful connect() on non-blocking socket
For example:
/* check socket error state - only if val == 0 after this call
* connection is properly established.
*/
len = sizeof(int);
if (getsockopt(fd, SOL_SOCKET, SO_ERROR, (void *) state, len) 0) {
goto err;
}
if (state != 0) {
/* socket state error - setting errno */
errno = state;
goto err;
}
Or maybe I doing too much ?
Best regards,
--
Marek Marcola [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
RE: Non-blocking BIO and BIO_do_connect problem.
I don't know what is supposed to happen in theory, but in practice I have found select() to be quite a disaster in informing me when a socket becomes writable. I have seen this on both Linux and FreeBSD. I have no idea why it gave you a problem. Lots of people do this and you're the first person to report a problem that I've ever seen. select() is very useful and an elegant solution for multiplexing sockets and doing non blocking IO. However it is useful only for getting to know when a socket becomes ready for read. Umm, no. It is just as useful to know what a socket is ready to write. I have seen code in which select() is used for getting to know pending writes. But this is only when we have written and for some reason the write operation does not write the full amount. In this case, we are interested when the socket becomes writeable bcoz we want to finish our write. That's one of the most common reasons why you would want to know if a socket became writable. There are others. (There is no guarantee that your very first call to 'write' for a single byte won't blockl) But if you naively check for write condition on a socke t with select() you will find that it always returns that the socket is writeable. No, it will not always return that the socket is writeable. It will return that the socket is writeable if and only if the socket is in fact writeable. This is precisely what it's *for*. Can you document a case where 'select' said that a socket was writeable when it was not writeable? But I have always found non blocking IO to be a very advanced use of sockets and my advice will be that you should not attempt if you don't know what you are doing . I could not disagree more. Blocking I/O is much less forgiving because if you accidentally call 'read' or 'write' at the wrong time, your program can hang indefinitely. It is very hard to get blocking sockets right. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Non-blocking BIO and BIO_do_connect problem.
Marek Marcola wrote:
For example:
/* check socket error state - only if val == 0 after this call
* connection is properly established.
*/
len = sizeof(int);
if (getsockopt(fd, SOL_SOCKET, SO_ERROR, (void *) state, len) 0) {
goto err;
}
if (state != 0) {
/* socket state error - setting errno */
errno = state;
goto err;
}
Or maybe I doing too much ?
Yes.
connect() will return 0 on success. From that point on you use can use
readability indication and read() to detect closed/timeout connection.
connect() will return -1/INPROGRESS when it still waiting for the
network layer to conclude the connection attempts. Right now the TCP
layer is automatically retransmissing connection requests (SYN_SENT state).
connect() will return -1 and anything else on failure. Some possible
return values maybe ETIMEDOUT, ENETDOWN, ENETUNREACH, ENETRESET, etc...
But all of these a fatal errors and mean the same thing, but can
provide a finer grained reasoning for the cause of failure.
ETIMEDOUT the connection requests just timed out after maximum retries.
ENETDOWN the local host's network interface is not operational.
ENETUNREACH a remote network returned ICMP network unreachables for the
network.
ENETRESET the request port is not available for inbound connections at
that address.
EHOSTUNREACH a remote network returned ICMP host unreachables for the
address.
blah blah blah...
Darryl
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: Non-blocking BIO and BIO_do_connect problem.
Sorry for typo, should be pBio instead of m_pBio everywhere. On 7/22/06, Bu Bacoo [EMAIL PROTECTED] wrote: Hello, I'm having problem with BIO_do_connect, when trying to setup non-blocking behaviour for it. When using: BIO* pBio = BIO_new_connect((char*)conn.c_str()); BIO_set_nbio(m_pBio,0); //returns 1 BIO_do_connect(m_pBio); //returns 1 it works just fine,... .. but with non blocking: BIO* pBio = BIO_new_connect((char*)conn.c_str()); BIO_set_nbio(m_pBio,1); //returns 1 BIO_do_connect(m_pBio); //returns -1 It doesn't connect. Why could that be? Any idea please. Thanks Bu __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Non-blocking BIO and BIO_do_connect problem.
Hello, I'm having problem with BIO_do_connect, when trying to setup non-blocking behaviour for it. When using: BIO* pBio = BIO_new_connect((char*)conn.c_str()); BIO_set_nbio(m_pBio,0); //returns 1 BIO_do_connect(m_pBio); //returns 1 it works just fine,... .. but with non blocking: BIO* pBio = BIO_new_connect((char*)conn.c_str()); BIO_set_nbio(m_pBio,1); //returns 1 BIO_do_connect(m_pBio); //returns -1 It doesn't connect. Why could that be? Any idea please. Thanks Bu __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Non-blocking BIO and BIO_do_connect problem.
Instead of modifying the BIO, I've also tried to set it's socket to non-blocking mode. Same result, BIO_do_connect returns -1 BIO* pBio = BIO_new_connect((char*)conn.c_str()); BIO_socket_nbio(BIO_get_fd(pBio,NULL), 1); BIO_do_connect(pBio); //returns -1 On 7/22/06, Bu Bacoo [EMAIL PROTECTED] wrote: Sorry for typo, should be pBio instead of m_pBio everywhere. On 7/22/06, Bu Bacoo [EMAIL PROTECTED] wrote: Hello, I'm having problem with BIO_do_connect, when trying to setup non-blocking behaviour for it. When using: BIO* pBio = BIO_new_connect((char*)conn.c_str()); BIO_set_nbio(m_pBio,0); //returns 1 BIO_do_connect(m_pBio); //returns 1 it works just fine,... .. but with non blocking: BIO* pBio = BIO_new_connect((char*)conn.c_str()); BIO_set_nbio(m_pBio,1); //returns 1 BIO_do_connect(m_pBio); //returns -1 It doesn't connect. Why could that be? Any idea please. Thanks Bu __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Non-blocking BIO and BIO_do_connect problem.
Hello, --- Bu Bacoo [EMAIL PROTECTED] wrote: Instead of modifying the BIO, I've also tried to set it's socket to non-blocking mode. Same result, BIO_do_connect returns -1 This is good news then since it is expected behavior. :-) You are doing nothing wrong till now. However you have to keep trying in a while loop until BIO_do_connect() succeeds. That is the way non blocking IO works. HTH, Girish BIO* pBio = BIO_new_connect((char*)conn.c_str()); BIO_socket_nbio(BIO_get_fd(pBio,NULL), 1); BIO_do_connect(pBio); //returns -1 On 7/22/06, Bu Bacoo [EMAIL PROTECTED] wrote: Sorry for typo, should be pBio instead of m_pBio everywhere. On 7/22/06, Bu Bacoo [EMAIL PROTECTED] wrote: Hello, I'm having problem with BIO_do_connect, when trying to setup non-blocking behaviour for it. When using: BIO* pBio = BIO_new_connect((char*)conn.c_str()); BIO_set_nbio(m_pBio,0); //returns 1 BIO_do_connect(m_pBio); //returns 1 it works just fine,... .. but with non blocking: BIO* pBio = BIO_new_connect((char*)conn.c_str()); BIO_set_nbio(m_pBio,1); //returns 1 BIO_do_connect(m_pBio); //returns -1 It doesn't connect. Why could that be? Any idea please. Thanks Bu __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Non-blocking BIO and BIO_do_connect problem.
Bu Bacoo wrote:
Instead of modifying the BIO, I've also tried to set it's socket to
non-blocking mode. Same result, BIO_do_connect returns -1
BIO* pBio = BIO_new_connect((char*)conn.c_str());
BIO_socket_nbio(BIO_get_fd(pBio,NULL), 1);
BIO_do_connect(pBio); //returns -1
On 7/22/06, Bu Bacoo [EMAIL PROTECTED] wrote:
Sorry for typo, should be pBio instead of m_pBio everywhere.
On 7/22/06, Bu Bacoo [EMAIL PROTECTED] wrote:
Hello, I'm having problem with BIO_do_connect, when trying to setup
non-blocking behaviour for it.
When using:
BIO* pBio = BIO_new_connect((char*)conn.c_str());
BIO_set_nbio(m_pBio,0); //returns 1
BIO_do_connect(m_pBio); //returns 1
it works just fine,...
.. but with non blocking:
BIO* pBio = BIO_new_connect((char*)conn.c_str());
BIO_set_nbio(m_pBio,1); //returns 1
BIO_do_connect(m_pBio); //returns -1
It doesn't connect. Why could that be? Any idea please.
And if you do this:
while(1) {
int rv = BIO_do_connect(m_pBio);
if(rv 0) {
// Fix this line below with correct detection for a fatal or
non-fatal error, if BIO_do_connect() returns a fatal error we want to
abort, if BIO_do_connect() returns an expected non-fatal error we need
to delay and try again.
if(errno != EINPROGRESS)
break; // fatal error
// wait a bit and try again
sleep(1);
}
}
I am not familiar with BIO and nonbocking connects but the the connect()
system call will return -1/EINPROGRESS when the connect is not yet
connected but still working on establishing a connection.
Just a thought for you.
Darryl
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: Non-blocking BIO and BIO_do_connect problem.
Thanks you both... after correcting my BIO_do_connect (and all
read/write following it) - adding retries (as Girish pointed), it
works just fine.
Now I'll check the errors, mentioned by Darryl, to make it more clear,
not just to retry until some counter runs out.
Thanks.
Bu
On 7/22/06, Darryl Miles [EMAIL PROTECTED] wrote:
Bu Bacoo wrote:
Instead of modifying the BIO, I've also tried to set it's socket to
non-blocking mode. Same result, BIO_do_connect returns -1
BIO* pBio = BIO_new_connect((char*)conn.c_str());
BIO_socket_nbio(BIO_get_fd(pBio,NULL), 1);
BIO_do_connect(pBio); //returns -1
On 7/22/06, Bu Bacoo [EMAIL PROTECTED] wrote:
Sorry for typo, should be pBio instead of m_pBio everywhere.
On 7/22/06, Bu Bacoo [EMAIL PROTECTED] wrote:
Hello, I'm having problem with BIO_do_connect, when trying to setup
non-blocking behaviour for it.
When using:
BIO* pBio = BIO_new_connect((char*)conn.c_str());
BIO_set_nbio(m_pBio,0); //returns 1
BIO_do_connect(m_pBio); //returns 1
it works just fine,...
.. but with non blocking:
BIO* pBio = BIO_new_connect((char*)conn.c_str());
BIO_set_nbio(m_pBio,1); //returns 1
BIO_do_connect(m_pBio); //returns -1
It doesn't connect. Why could that be? Any idea please.
And if you do this:
while(1) {
int rv = BIO_do_connect(m_pBio);
if(rv 0) {
// Fix this line below with correct detection for a fatal or
non-fatal error, if BIO_do_connect() returns a fatal error we want to
abort, if BIO_do_connect() returns an expected non-fatal error we need
to delay and try again.
if(errno != EINPROGRESS)
break; // fatal error
// wait a bit and try again
sleep(1);
}
}
I am not familiar with BIO and nonbocking connects but the the connect()
system call will return -1/EINPROGRESS when the connect is not yet
connected but still working on establishing a connection.
Just a thought for you.
Darryl
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: Non-blocking BIO and BIO_do_connect problem.
On Sat, Jul 22, 2006, Bu Bacoo wrote: Thanks you both... after correcting my BIO_do_connect (and all read/write following it) - adding retries (as Girish pointed), it works just fine. Now I'll check the errors, mentioned by Darryl, to make it more clear, not just to retry until some counter runs out. By a strange coincidence I added some code to the ocsp application a couple of days ago that covers this situation. What you should do is call BIO_should_retry() if you get = 0 return from BIO_do_connect() in fact until it connects you'll get BIO_should_retry_special() as true. You can loop until you get an error or BIO_do_connect() succeeds but that isn't very efficient and it non portable with the current connect BIO implementation on Windows as I found out when I tried the updated ocsp application with a timeout on WIN32. That should be fixed I suppose. The efficient thing to do depends on the underlying transport. Getting the actual socket description with BIO_get_fd() then calling select() while waiting for a write condition is often done for example. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Non-blocking BIO and BIO_do_connect problem.
Thanks you both... after correcting my BIO_do_connect (and all read/write following it) - adding retries (as Girish pointed), it works just fine. Now I'll check the errors, mentioned by Darryl, to make it more clear, not just to retry until some counter runs out. Don't do that. Retry until it succeeds or fails. You need to check the error code. If it has really failed, there's no point in waiting and retrying. And if it's still trying to connect, there's no reason to consider it an error just because some particular amount of time has passed. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: non-blocking BIO
For SSL_accept, you need to make the underlying socket non-blocking, rather than a non-blocking BIO. You can make a socket non-blocking with the 'fcntl' system call (check the manpages). You may also be interested in the excellent sockets tutorial 'Beej's Guide to Network Programming' located at http://www.ecst.csuchico.edu/~beej/guide/net/html/ Once you have made a socket, and set it non-blocking, create your SSL object as usual and the SSL connection should be then non-blocking. There are some other issues though (particularly when using select), see the following two articles for more info: http://www.linuxjournal.com/article.php?sid=4822 http://www.linuxjournal.com/article.php?sid=5487 Hope that helps, Patrick On Mon, 17 May 2004 8:00 pm, Alexis Lefort wrote: Hi all, My server sometimes block on the call to SSL_accept() because my client crash on SSL_connect. In many man pages it is told that a BIO can be blocking or non-blocking. But how can I create a non-blocking BIO (This would solve my problem I hope). Thanks in advance. Alexis __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] -- RedHerring: Linux wiki support and tutorials http://covox.sepwich.com/linux CECID: The CEnsorship CIrcumvention Device http://cecid.sf.net __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: non-blocking BIO
Thank you, I missed that! BIOs don't need any special settings to support non blocking I/O: if the underlying transport signals a call should be retried the BIO takes appropriate action. In other words you just have to set the underlying transport (socket normally) to a non blocking mode. Steve. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Non-blocking BIO
You are misinterpreting the meaning of BIO_should_retry(). What it is telling you is that you should wait until a certain condition is satisfied on the underlying transport (SOCKET in this case) before you retry. You can retry immediately but that is likely to be inefficient. Is it harmful if try immediately again? In the first case the I/O special is probably telling you that you should wait until the SOCKET has connected. Ahhh... these are just the kind of advices I wanted to hear, but how do I do it? What would be the best way to see if connection is ready? I guess Sleep(1000) and connect again isn't the best method available? :-) Though it works... After that BIO_should_read() is saying you should wait until the SOCKET has data available before retrying. It isn't telling you to just call BIO_read()! Okay. That's good to know. I thought it was a commad for me to make a read attempt. Your select() call is also waiting to see when data can be read *or* written. Therefore it will probably return immediately telling you its OK to write data. What you should actually be doing is waiting until the relevant condition is satisfied: is it wants to read then wait until data is available etc. And that is done with select? And write mask being NULL? Thank you! VW __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
non-blocking BIO
Hi! I was wondering how to set non-blocking mode on in my helper application (using OpenSSL). I found a BIO example at: http://www.openssl.org/docs/crypto/BIO_f_ssl.html# which worked fine until I tried to make it nonblocking by adding: BIO_set_nbio (sbio, 1); in the code, right before: BIO_do_connect(...); I get "Error connecting to server" even though my server says it got a new connection. ERR_print_errors_fp(stderr); doesn't say any error message. Now if anyone is familiar with non-blocking BIO I'd be pleased to hear I did something wrong and some advices on how to continue :-) Thanks VW __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: non-blocking BIO
Did you do a select() after the BIO_do_connect()? Steven -- Steven Reddie [EMAIL PROTECTED] Senior Software Engineer Computer Associates Pty Ltd (Australia) -Original Message- From: Wirta, Ville [SMTP:[EMAIL PROTECTED]] Sent: Monday, April 02, 2001 11:54 PM To: '[EMAIL PROTECTED]' Subject: non-blocking BIO Hi! I was wondering how to set non-blocking mode on in my helper application (using OpenSSL). I found a BIO example at: http://www.openssl.org/docs/crypto/BIO_f_ssl.html# which worked fine until I tried to make it nonblocking by adding: BIO_set_nbio (sbio, 1); in the code, right before: BIO_do_connect(...); I get "Error connecting to server" even though my server says it got a new connection. ERR_print_errors_fp(stderr); doesn't say any error message. Now if anyone is familiar with non-blocking BIO I'd be pleased to hear I did something wrong and some advices on how to continue :-) Thanks VW __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
