Sebastián Treu wrote:
> I used a select() thread with non-blocking IO just to no keep the cpu
> busy in a infinite loop. Kind of:
>
> while( alive && CONTINUE )
> {
> /* The main client attendance */
>
> copy = master;
> if ( select(client->fd+1, ©, NULL,NULL,NULL) == -1)
> printf("<thread %d>:[ERR]:\tSelect fail\n",tid);
> else
> {
> if ( FD_ISSET(client->fd, ©) )
> {
> /* read from the secure connection gaining exclusive
> access */
> /* to the client ssl structure. The 'sender thread' could
> */
> /* access this structure coliding with the 'err' value
> and */
> /* starting a catastrophe.
> */
> pthread_mutex_lock(&client->mutex[SSL_MUTEX]);
> nbytes = SSL_read(client->ssl, client->buffer,
> chunk_size);
> err = SSL_get_error(client->ssl, nbytes);
> pthread_mutex_unlock(&client->mutex[SSL_MUTEX]);
>
> You can check the hole threaded server in earlier development here:
>
> http://code.google.com/p/tellapic/source/browse/trunk/server.c
Your logic is backwards here. You are trying to decide whether or not to
read data on the decrypted output link, so why are you 'select'ing on the
encrypted input link?
SSL is a state machine, not a filter. The implementation of SSL_read is
*NOT*:
1) Read some data from the socket.
2) If we got any data, decrypt it.
3) Return the data we read.
It is:
1) Try to make forward progress, doing any reads and writes as necessary.
2) If this resulted in any decrypted data, return it.
3) If not, tell the caller why.
As a result, you can only 'select' *after* calling SSL_read, never before.
And you cannot assume that you will be selecting in the read direction,
because either can be necessary.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
