Android – Socket conectado aunque no pueda

Esto es interesante. He estado probando y puedo replicar el comportamiento que usted describe.

En primer lugar, la respuesta más votada aquí proporciona una buena discusión sobre el Java Socket API:

Java socket API: ¿Cómo saber si una conexión ha sido cerrada?

A partir de esto, me preguntaba si intentar leer un byte desde el socket nos permitiría comprobar si está realmente abierto

 // Endpoint that does not exist Socket socket = new Socket("1.2.3.4", 1234); InputStream tmpIn = socket.getInputStream(); int result = tmpIn.read(); Log.i("SocketTest", "read() result: " + result); 

En el caso de que el punto final no es válido, he encontrado que la llamada a read() devuelve -1 después de aproximadamente 10 segundos.

En el caso de que hay un oyente en la IP y el puerto, la llamada a read() parece bloquear indefinidamente hasta que algo sucede, como realmente la recepción de datos desde el servidor, o perder la conexión a Internet, etc

Sobre la base de esta diferencia, he envuelto esta prueba en una nueva clase:

 public class VerifiedSocket extends Socket { public VerifiedSocket(String ip, int port, int millisecondTimeout) throws UnknownHostException, IOException{ super(ip,port); ReadThread tryRead = new ReadThread(); tryRead.start(); try { tryRead.join(millisecondTimeout); } catch (InterruptedException e) { } if(tryRead.getReadValue()==-1){ // We read -1 so assume endpoint invalid throw new IOException("Endpoint is invalid"); } } private class ReadThread extends Thread{ private int readValue = 512; // Impossible byte value @Override public void run(){ try { InputStream input = getInputStream(); readValue = input.read(); } catch (IOException e) { } } public int getReadValue(){ return readValue; } } } 

Y luego probarlo de la siguiente manera:

 try { VerifiedSocket socket = new VerifiedSocket("1.2.3.4", 1234, 20000); Log.i("SocketTest", "Endpoint is valid"); socket.close(); } catch (UnknownHostException e) { Log.e("SocketTest", e.getLocalizedMessage()); } catch (IOException e) { Log.e("SocketTest", e.getLocalizedMessage()); } 

Si utilizo un punto final no válido en Wifi, el constructor de VerifiedSocket lanza una excepción con un tiempo de espera. Si utilizo un punto final no válido en datos móviles, lanza IOException con el mensaje 'Endpoint is invalid'. No es perfecto, pero espero que pueda ayudarte.

Si el entorno donde está ejecutando el código no se comporta como usted necesita (por cualquier razón, Robert ha escrito uno), puede resolver el mal comportamiento entorno con traer una nueva abstracción.

Usted puede hacer muchas cosas para resolverlo; Aquí hay una solución – implementar un envoltorio en la parte superior del protocolo utilizado (java.net.Socket) que extenderá la clase Socket y reemplazará los métodos connect () / getInputStream () / getOutputStream () / whatever-method-you-need () La forma en que el código primero intenta contactar realmente al servidor antes de devolver un flujo válido.

En el envoltorio, envía un par de bytes (una clave de cliente) al servidor en el que el servidor responde con una respuesta (una clave de servidor). Mantenga las claves en secreto, solo el cliente y el servidor conocerán las claves. Si el servidor no responde con un tiempo de espera, lance una excepción.

 private class MySocket extends Socket { Socket inner; MySocket(Socket inner) { this.inner = inner; } @Override InputStream getInputStream() { // do your ping here // if ping fails, thrown an exception return inner.getInputStream(); } ... override additional methods as you need } 

Puede utilizar este patrón de ping en todos los lugares para detectar la conexión se perdió.

Sé que estás haciendo lo que la capa subyacente se supone que está haciendo … pero si no está haciendo lo que estás esperando, ¿qué puedes hacer?