Newsgroup: it.comp.java
Titolo: Socket + win = kill'em all

Dopo una settimana passata ad ascolare e leggere i vari msgs nonché tutte le
FAQ et simil credo di essere pronto ad entrare nel forum, e lo faccio subito
con un questito che mi assilla:
Supponendo di avere una connessione socket attiva e valida tra due macchine
fisiche (Client-Server) cosa succede se per qualche motivo il canale fisico
di comunicazione viene interrotta????
In java teoricamente leggendo sul socket viene restituita un IoException (se
usi una istanza di BufferedReader) che basta catturare l'eccezione per
riconoscere che la connessione non é piú valida.
Bello, peccato che sotto Windows NT 4 (SP3), se stacchi il canale fisico (il
cavo di rete) prima che il programma si accorga dellínterruzione, passi del
tempo (tipicamente dal min ai 2-3') e se che nel frattempo hai mandato
messaggi sul sock questi siano persi.
Possibili cause:
1) la winsock gestisce la caduta del socket in un modo suo (documenti, dove
!!!!),
2) una volta che java passa i dati al livello piú basso (quale????) nella
pila iso-osi, java se ne frega e del tutto se ne occupano gli altri layers
3) in ogni caso non ci sono metodi o api java che permettano di accedere
alla probabile Queue nella quale i messaggi in attesa vengono messi prima di
uscire fisicamente dalla workstation
Morale:
se salta la connessione, non si sa quali sono i dati arrivati e quali no!!!!
Se riconnetto il cavo prima che java si accorga e spari l'eccezione, i dati
sul server arrivano!
Voi che ne dite??????
Ps: ma quanto male scrivo???? spero si sia capita la req!
Ciao NaPALM

[...]
Ci sono tre livelli da osservare: uno, il tipo di servizio che TCP offre; due, 
l'implementazione TCP/IP di MS per win32; tre, il tipo di codice applicativo 
che usi.
TCP offre un servizio connection-oriented garantito, il che significa che, se 
hai un problema a livello fisico o IP, sei sicuro che *prima o poi* questo 
verra' segnalato al livello di trasmissione e quindi a quello applicativo. Puoi 
assegnare esplicitamente timeout, oppure viene usato un timeout di sistema.
Due, WinSock ha di per se' dei limiti (ad esempio e' famigerato il problema 
dell'IO interrompibile) dettati in parte da come e' costruita e in parte dai 
servizi di Win32.
Tre, a livello applicativo, se usi un BufferedReader/Writer hai - come il nome 
dovrebbe suggerire - un buffer di mezzo: il che significa che sia in lettura 
che scrittura le tue informazioni sono, quando possibile, bufferizzate 
internamente piuttosto che lette/scritte direttamente a livello trasmissione. 
Quindi se interrompi la linea fisica, ma nel buffer sono gia' stati memorizzati 
300 bytes, potrai leggere 300 bytes senza problemi, oppure ricevere un timeout 
al 100esimo, a seconda di come TCP e' implementato e di come il *buffer* e' 
implementato.


Quindi se leggessi/scrivessi direttamente senza bufferizzare java
comunicherebbe  immediatamente la situazione di non connessione?????
Thanx for all!
(ps per la cronaca ho impostato i valori di timeout al minimo ma nonostante
questo non riesco a tracciare l'evento di disconnessione)
appena ho un po di tempo voglio provare senza buffer
NaPALM

comunicherebbe  immediatamente la situazione di non connessione?????
Ti togli certamente un livello di complessita' per capire che succede. Il resto 
dipende dall'implementazione win32 e giu' fino al livello fisico (ma in questo 
le schede di rete ormai sono piuttosto omogenee).