Boost asio socket tcp disponibile segnala il numero errato di byte

Question

Nel modello server client SSL, utilizzo il codice riportato di seguito per leggere i dati dal socket sul lato client o lato server.

Ho letto solo i dati quando ci sono dati disponibili. Per sapere quando sono disponibili i dati, controllo il metodo available() su lowest_layer() di asio::ssl::stream. Dopo aver inviato 380 byte dal client al server e inserito il metodo di lettura sul server, vedo quanto segue.

's' è il buffer I fornito.
'n' è la dimensione del buffer che ho fornito.
'a1' è il risultato di available() prima della lettura e riporta 458 byte.
'r' è il numero di byte effettivamente letti. Riferirà 380, che è corretto.
'a2' è il risultato di available() dopo la lettura e riporta 0 byte. Questo è quello che mi aspetto, dal momento che il mio cliente ha inviato 380 byte e li ho letti tutti.

Perché la prima chiamata a available() segnala troppi byte?

Tipi:

/** 
* Type used as SSL Socket. Handles SSL and socket functionality. 
*/ 
typedef boost::asio::ssl::stream<boost::asio::ip::tcp::socket> SslSocket; 
/** 
* A shared pointer version of the SSL Socket type. 
*/ 
typedef boost::shared_ptr<SslSocket>       ShpSslSocket; 

Utenti:

ShpSslSocket      m_shpSecureSocket; 

parte del metodo di lettura:

std::size_t a1 = 0; 
if ((a1 = m_shpSecureSocket->lowest_layer().available()) > 0) 
{ 
    r += boost::asio::read(*m_shpSecureSocket, 
          boost::asio::buffer(s, n), 
          boost::asio::transfer_at_least(1)); 
} 

std::size_t a2 = m_shpSecureSocket->lowest_layer().available(); 

informazioni

---

Aggiunto:

Così ho cambiato il mio metodo di lettura per controllare più a fondo se ci sono ancora dati disponibili da leggere da boost :: asio :: ssl :: stream. Non solo ho bisogno di controllare se ci sono dati disponibili a livello di socket, ma potrebbero esserci dei dati bloccati nei buffer OpenSSL da qualche parte. SSL_peek fa il trucco. Accanto al controllo dei dati disponibili, controlla anche lo stato della porta TCP e fa tutto questo fino a quando non c'è un timeout.

Ecco il metodo di lettura completo della classe boost :: iostreams :: device che ho creato.

std::streamsize SslClientSocketDevice::read(char* s, std::streamsize n) 
{ 
    // Request from the stream/device to receive/read bytes. 
    std::streamsize r = 0; 

    LIB_PROCESS::TcpState eActualState = LIB_PROCESS::TCP_NOT_EXIST; 

    char chSslPeekBuf; // 1 byte peek buffer 

    // Check that there is data available. If not, wait for it. 
    // Check is on the lowest layer (tcp). In that layer the data is encrypted. 
    // The number of encrypted bytes is most often different than the number 
    // of unencrypted bytes that would be read from the secure socket. 
    // Also: Data may be read by OpenSSL from the socket and remain in an 
    // OpenSSL buffer somewhere. We also check that. 
    boost::posix_time::ptime start = BOOST_UTC_NOW; 
    int   nSslPeek = 0; 
    std::size_t nAvailTcp = 0; 
    while ((*m_shpConnected) && 
      (LIB_PROCESS::IpMonitor::CheckPortStatusEquals(GetLocalEndPoint(), 
                 GetRemoteEndPoint(), 
                 ms_ciAllowedStates, 
                 eActualState)) && 
      ((nAvailTcp = m_shpSecureSocket->lowest_layer().available()) == 0) && 
      ((nSslPeek = SSL_peek(m_shpSecureSocket->native_handle(), &chSslPeekBuf, 1)) <= 0) && // May return error (<0) as well 
      ((start + m_oReadTimeout) > BOOST_UTC_NOW)) 
    { 
     boost::this_thread::sleep(boost::posix_time::millisec(10)); 
    } 

    // Always read data when there is data available, even if the state is no longer valid. 
    // Data may be reported by the TCP socket (num encrypted bytes) or have already been read 
    // by SSL and not yet returned to us. 
    // Remote party can have sent data and have closed the socket immediately. 
    if ((nAvailTcp > 0) || (nSslPeek > 0)) 
    { 
     r += boost::asio::read(*m_shpSecureSocket, 
          boost::asio::buffer(s, n), 
          boost::asio::transfer_at_least(1)); 
    } 

    // Close socket when state is not valid. 
    if ((eActualState & ms_ciAllowedStates) == 0x00) 
    { 
     LOG4CXX_INFO(LOG4CXX_LOGGER, "TCP socket not/no longer connected. State is: " << 
            LIB_PROCESS::IpMonitor::TcpStateToString(eActualState)); 
     LOG4CXX_INFO(LOG4CXX_LOGGER, "Disconnecting socket."); 
     Disconnect(); 
    } 

    if (! (*m_shpConnected)) 
    { 
     if (r == 0) 
     { 
     r = -1; // Signal stream is closed if no data was retrieved. 
     ThrowExceptionStreamFFL("TCP socket not/no longer connected."); 
     } 
    } 

    return r; 
} 

Answer 1

Quindi forse so perché questo è. È una connessione SSL e quindi i byte trasferiti saranno crittografati. I dati crittografati potrebbero essere di dimensioni diverse a causa delle dimensioni del blocco. Immagino che risponda alla domanda perché il numero di byte disponibili a livello TCP sia diverso dal numero di byte che esce da una lettura.