> The application I am writing has requirement that > after a request is sent to server, it should hear > from the server in xyz seconds.
> With normal tcp socket, i can achieve this through select() > function. But how do I achieve this for SSL_read? Same way. > As I understand from last few threads on this group, > a select() will just tell the application that some > bytes are available in the tcp buffer for the layer > above to read. But select does not distinguish between > application data and control data (renegotiation data). It's hard to imagine why that would make a difference. > So will select() be really able to tell me that the next > SSL_read() will succeed immediately and fill application > buffer with the server's response? No, but 'select' on a regular TCP socket doesn't tell you that either. You could just get a tiny piece of the server's response. As far as a timeout is concerned, why is a byte of SSL protocol data different from a tiny piece of a server response? > What if my server and client are not going to renegotiate ever? > In that case would a hit from select() indicate availability of > application data only? It depends upon your definition of "availability". It would indicate the other side sent at least one byte of application data, but it would not mean SSL_read had enough to decrypt it. You can use non-blocking sockets and pass the timeout to 'select'. SSL_read will never block. You might wind up waiting longer than the timeout if application or protocol data dribbles in, but you'd do the same thing for TCP if that happened. You can, of course, reduce the timeout if you want in subsequent calls to 'select' based on how much wall time has passed. Most likely (with the most typical requirements), just keeping the timeout in 'select' will work just fine. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
