Quindi, ho scritto un thread sul mio lato client, che tenta di readObject() da un flusso di socket.Java - readObject() e setSoTimeout()
Questo thread viene eseguito fino a quando il client è connesso.
La connessione al server può essere chiusa sulla GUI del client. Se il client decide di disconnettersi (questo non uscirà dal programma client) facendo clic sull'opzione di menu "disconnessione" , il socket verrà chiuso e un isConnected impostato su falso.
Poiché i client che leggono thread tenta di readObject() dallo stream, mentre la connessione può essere chiusa tramite la GUI, ho impostato un timeout su 250ms (setSoTimeout(250)).
@Override
public void run()
{
this.connection = this.connectionHandler.getSocket();
while(connectionHandler.isConnected())
{
this.readCircle();
}
this.connectionHandler.setReadTaskRunning(false);
}
private void readCircle()
{
try
{
this.connection.setSoTimeout(250);
this.connectionHandler.readData(); //this uses readObject().
}
catch(SocketTimeoutException timeout){}
catch(...){}
}
So che readObject() sarà bloccare, e per verificare se il client è ancora connesso, ho wraped in un while, che controlla (ogni timeout) se il socket client è ancora connesso.
La mia domanda ora:
Nel caso in cui, se i readObject() comincia a diventare un oggetto passato dal server, tenta di leggerlo, ma durante l'elaborazione si verifica un timeout, saranno i dati sul flusso di essere "danneggiato" in qualche modo, perché cancellato. O dovrei semplicemente lasciare il blocco readObject() e rilevare un'eccezione se il thread della GUI vuole chiudere il socket.
Non ho molta esperienza con le prese e forse il mio approccio è sbagliato.
isConnected() non restituisce false se il peer è disconnesso. Devi prendere e gestire EOFException. – EJP
Sì, hai ragione. A 'catch (...) {}' devo catturare un sacco di eccezioni.Il fermo 'EOFException' richiamerà un' forceDisconnect() 'per chiudere le risorse sul lato client e anche regolare il Elementi della GUI per l'utente. – Hexa