Cosa ti manca è il concetto di una 'session'. Pensa alla posizione di un server, quando alcuni bit arrivano "sul filo". Cosa fare con questi? Con TCP/IP, c'è qualche informazione già presente sul filo, vale a dire:
- src addr
- porta src
- dest addr
- porta di destinazione
- e il messaggio payload stessa
- e alcune altre cose (come contatori di sequenza, per garantire che i "pacchetti" non vengano confusi durante la trasmissione)
Il sistema operativo del server utilizza le informazioni src/dest addr/port per decidere se si tratta di "una conversazione che è già in corso" oppure no. Principalmente considera lo dest port
(poiché il messaggio lo ha già fatto alla macchina stessa, attraverso internet e il firewall) per decidere se è in ascolto per il tuo programma Java sulla "dest port". Tuttavia, utilizza l'intero src-addr/src-port/dest-addr/dest-port per provare a recapitare il payload al tuo programma nell'ordine in cui il mittente li ha inviati (che potrebbe non essere l'ordine in cui sono arrivati , a causa dell'inter-net interposta). Si noti che un singolo "messaggio" potrebbe effettivamente essere suddiviso in più pacchetti. Lo stack TCP/IP del tuo sistema operativo sta facendo un bel po 'di lavoro per te.
Tuttavia, si noti che per eseguire questa funzione a proprio nome, il sistema operativo deve dedicare alcune risorse al "monitoraggio dello stato" della sessione TCP/IP. Per lo meno, per ogni set di porta/addr src/dest, ci deve essere un contatore dell'ultimo pacchetto "ben ricevuto", uno spazio buffer per contenere i pacchetti fino a quando il tuo programma è pronto a consumarli, e così via.
Ora la domanda rivolta all'implementatore di stack TCP/IP è "per quanto tempo dovrei rimanere" in questo stato per "? 10 secondi sono sufficienti? 20 minuti?Ad un certo punto, dopo non aver ascoltato dal client per un po ', la sessione deve "timeout". Se ci sono più pacchetti da inviare in una sequenza e il client inizia a inviarli di nuovo, il server deve essere in grado di dire "mi dispiace, mi stai mandando il pacchetto 234 di qualche messaggio precedente, ma perché non ho sentito da per un po ', ho buttato fuori i pacchetti 1-233. Potremmo ricominciare? ".
Quindi, in questo senso, non c'è modo di impedire al client di "disconnettersi". Certo, puoi continuare ad ascoltare sul socket, nel caso in cui il client si riprenda e mandi altri dati. Ma tu e il tuo cliente avrete bisogno di un modo per "riprendere da dove avevamo lasciato".
In HTTP, ciò viene ottenuto utilizzando un "cookie di sessione", una lunga stringa univoca che il server ha fornito al client e il client re-invia con ogni nuova richiesta (che si verifichi nella stessa sessione a livello TCP o non). Questa è una 'sessione a livello di applicazione' che ha una durata superiore a quella della sessione TCP.
Dato che stai scrivendo un'applicazione e sembra che tu abbia un certo grado di controllo su ciò che il client e il server possono dirsi l'un l'altro (il "protocollo"), hai più opzioni su come concordare su cosa è una sessione, come comportarsi con le cose se il cliente "va via" (timeout della sessione), e su come entrambe le parti si riprenderanno e "riprenderanno da dove abbiamo lasciato" (ristabilire la sessione). Non dimenticarti dell'autenticazione, vero?
Come altri hanno già detto, dipende molto da quello che stai cercando di ottenere.
Ulteriori informazioni su TCP e UDP. Con TCP non è possibile, dovrai gestire la riconnessione tu stesso. Con UDP è possibile, ma ha altre implicazioni –
Perché vuoi farlo? Ricollegare una connessione interrotta è impossibile, ma potrebbe esserci un altro modo di fare quello che vuoi. – tbodt
@tbodt - un altro modo - hmm, come cosa?> – Coffee