Michael Farajian wrote:

What protocol are you using for your application layer data?  If you are using HTTP/1.1 then the connection is left open by default and you have to make sure that you are only reading as much data as is specified by the content-length header. But this problem is not peculiar to non-blocking sockets so I don't know if I'm reading you clearly or not.

Brad

We are using Win32 non-blocking sockets for our communication.  Everything seems to be working with one exception. Recursive calls to SSL_read() get the server response, but when to STOP calling it is the question I've seen posted here quite often.  Below is a very simplified version of the logic we are using: The behavior we are seeing is SSL_read returns -1, WSAWaitForMultipleObjects() _immediately_ returns 0 ( WSA_WAIT_EVENT_0), and a subsequent SSL_read will still return -1.Finally, when all the data is received from the server, the WSAWaitForMultipleEvents() blocks for 30 seconds and times out, forcing our loop to exit. What are we missing that causes us not to recognize the true ending of the servers response?  ThanksMike   WSAEventSelect( iSocketID, m_hSocketEvent, FD_READ|FD_WRITE);  //  ...  for(;;)
 {
  iErr = SSL_read(m_sslconn, szBuffOut, sizeof(szBuffOut));   if( iErr < 0 )
  {
   int iLastErr = SSL_get_error( m_sslconn, iErr );
   if( iLastErr == SSL_ERROR_WANT_READ  || iLastErr == SSL_ERROR_WANT_WRITE )
   {
    if( WSAGetLastError() == WAEWOULDBLOCK )
    {
     int iResult = WSAWaitForMultipleEvents( 1, &m_hSocketEvent, FALSE, 30000, FALSE );
     if( iResult == WSA_WAIT_EVENT_0 )
     {
      WSAResetEvent( m_hSocketEvent );
      continue;
     }     else        break;
    }
   }
  }   // Append szBuffOut to our response string   if ( iErr == 0 )
   break;
 }

Reply via email to