int timeout = 15;
setsockopt(socket, SOL_SOCKET, SO_RCVTIMEO, &timeout, sizeof(int));
This will result in the following behaviors as described in http://msdn.microsoft.com/library/default.asp?url="">
Note When using the recv function, if no data arrives during the period specified in SO_RCVTIMEO, the recv function completes. In Windows versions prior to Windows 2000, any data received subsequently fails with WSAETIMEDOUT. In Windows 2000 and later, if no data arrives within the period specified in SO_RCVTIMEO the recv function returns WSAETIMEDOUT, and if data is received, recv returns SUCCESS.
Tim Regovich wrote:
What a lively discussion! One point that I thought was implicit in my comment when I started was that the timeout approach using some sort of alarm around a call to say SSL_accept, is that you cannot use the TCP timeouts, because SSL_accept wraps a whole serious of TCP transactions. My assertion is that given a situation where TCP transactions as taking place, it is difficult to come up with a reasonable timeout number. Furthermore, if you are using non blocking I/O you are doing it because you get better scalability/performance in an application that is managing a significant number of connections.Using non blocking I/O with OpenSSL is no more or less tricky than using non blocking I/O for any other application, but the point is well taken that if you are not familiar with socket programming and non blocking sockets/pooling/etc etc etc, then you will have problems layering OpenSSL on top of it! I am currently writing up a little HOWTO with some example code for handling non-blocking sockets, not using BIOs. I will include a very minimal connection manager/thread pooler that will hopefully clear up a lot of confusion. Regards, Tim Regovich
