Put your sockets into nonblocking mode (with fcntl()). If they would block and you try to read them, the system call will return with EWOULDBLOCK.
Other than that, you can set an alarm; a signal will interrupt a system call. You might wish to set your signal handler to be a function that resets itself as the signal handler for SIGALRM and returns, because: a) the default action for SIGALRM is to terminate the process b) some UNIX implementations clear or disable the signal handler when the signal is raised You should, of course, clear and reset the alarm after you read the data, so that the timeout is per-read and not per-process. -Kyle H On Thu, Aug 7, 2008 at 2:36 PM, Du, Jinsong <[EMAIL PROTECTED]> wrote: > Kyle is right, I didn't set SO_KEEPALIVE on the socket in my server. > > Do I have to set SO_KEEPALIVE to avoid this situation in server side? > Since I use select in the main loop to deal with time out situation, > is there any other way to prevent OpenSSL library to wait for reading > a socket indefinitely? > > Thanks > > -J Du > > On Tue, Aug 5, 2008 at 2:11 PM, Kyle Hamilton <[EMAIL PROTECTED]> wrote: >> Because no data has been transmitted on the socket, the client didn't >> send an RST, and SO_KEEPALIVE wasn't set on the socket. >> >> -Kyle H >> > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
