2009-05-12 20 views
7

Tengo una aplicación C++ que usa llamadas de socket estándar y quiero saber si puedo saber si un socket sigue abierto sin enviar ni recibir datos. ¿Hay una llamada confiable select o ioctlsocket que pueda hacer?¿Cómo puedo verificar si todavía hay un socket abierto?

+0

¿Quiere decir comprobar si la toma se ha cerrado en el otro extremo? –

+0

Sí. Mi aplicación se ejecuta en Windows y si la computadora está hibernada, cuando vuelve el socket puede que ya no sea válido ya que el otro extremo lo ha cerrado (y como mi aplicación se suspende, no recibo ninguna notificación). – Rob

Respuesta

7

Si intenta recibir un byte, puede recibir varios errores, si tuviera un socket no bloqueante y tratara de recibir una conexión válida, obtendrá el error WSAEWOULDBLOCK.

Sabiendo esto podemos comprobar una toma no bloqueante al igual que

bool connected(SOCKET sock) 
{ 
    char buf; 
    int err = recv(sock, &buf, 1, MSG_PEEK); 
    if(err == SOCKET_ERROR) 
    { 
      if(WSAGetLastError() != WSAEWOULDBLOCK) 
      {return false;} 
    } 
    return true; 
} 

como se puede ver en la return value of recv recv puede devolver un tiempo de espera o varios otros errores de desconexión, i belive WSAEWOULDBLOCK es el único valor que puede devuelva si hubo un error pero aún está conectado, pero es posible que desee verificar dos veces esa lista de valores devueltos. Además, el indicador utilizado en recv (MSG_PEEK) significa que los datos aún se pueden leer cuando va a mirar más tarde después de la verificación, por lo que no tiene que preocuparse por perder un byte de datos.

Creo que esto solo funcionará bien con enchufes sin bloqueo, ya que puede bloquear hasta que reciba datos. Si desea utilizar el socket de bloqueo, puede configurarlo sin bloqueos con ioctlsocket antes de esta comprobación, luego devolverlo a cómo estaba.

+0

Para los enchufes de bloqueo que usaría seleccione. –

3

Un socket "abierto" no lo ayuda con la conectividad de extremo a extremo. La única manera de saber con certeza que puede comunicarse con el otro extremo es, bueno, comunicarse con el otro extremo.

En cualquier protocolo que diseñe, debe pensar en implementar este comportamiento de comprobación. Si no es su protocolo, a veces hay maneras de hacerlo a escondidas (por ejemplo, FTP hasta un archivo muy pequeño e inútil para verificar si los puertos FTP aún están abiertos).

Cuestiones relacionadas