[JAVA] Metodo readLine() con BufferedReader e socket

[hackerdm]

Salve,
ho un piccolo problema con la lettura delle linee passate al BufferedReader. Vorrei poter leggere tutte le linee che ricevo sul buffer ed ho fatto un while

String line;

while ((line = buffIn.readLine()) != null) {

    System.out.println(line);

}

il tutto funziona, mi legge le due linee di testo che ricevo e al terzo giro invece di uscire dal ciclo, visto che line dovrebbe essere null, rimane appeso su readLine. posso evitare che ciò accade??

grazie mille

[valia]

come è la linea che invii? per caso una stringa vuota? Una stringa vuota non è null e quindi resta in attesa

[hackerdm]

allora per farla breve ho un client e un server che comunicano attraverso socket e si scambiano stringhe di dati.
il server invia messaggi di risposta al client attraverso

esempio:
BufferedWriter out = new BufferedWriter(new OutputStreamWriter(m_oWorkingSocket.getOutputStrea m()));
out.flush();

out.write("Benvenuto sul server!");
out.write("\n");
out.write("Messaggio ricevuto dal Server");
out.write("\n");
out.flush();

tutto qui da parte del server, il client esegue il while che ti ho inviato prima. la comunicazione avviene perfettamente per singole righe ma visto che a me serve poter leggere più righe girate dal server, ho implementato quel while, il problema è che resta appeso appena termina di leggere tutte le righe

[valia]

si ma devi gestire la riga vuota che leggi (lo "\n"), devi sapere anche quante righe invii (di solito si invia il numero di righe da leggere in modo da non rimanere appesi

[hackerdm]

ma come faccio a gestirmi lo "\n"?? e cmq se invio il numero di righe, dovrei utilizzare un for a destinazione... mi sembra troppo macchinoso come soluzione... sia nella documentazione che un po ovunque viene utilizzato sempre il while per leggere i messaggi... purtroppo sono obbligato ad utilizzare "\n" per l'invio dei messaggi perchè sennò i messaggi non partono dal server... penso sia una convenzione.

[valia]

beh ovvio che devi gestirtelo, è un carattere e quindi come tale lo puoi trattare.
O fai una roba del genere

String tmp = buffer.readLine(); 
while (tmp != null && !"\n".equals(tmp)){
//DO YOUR STUFF
}

oppure come ti dicevo invia il numero di righe da leggere

[hackerdm]

ho provato come mi hai suggerito ma continua a restare appeso, e poi penso che specificando "&& !"\n".equals(tmp)" esca dal cilo ogni volta che trova "\n" e non è detto che "\n" sia solo alla fine


grazie per l'aiuto che mi stai dando

[LeleFT]

Originariamente inviato da hackerdm
ma come faccio a gestirmi lo "\n"?? e cmq se invio il numero di righe, dovrei utilizzare un for a destinazione... mi sembra troppo macchinoso come soluzione... sia nella documentazione che un po ovunque viene utilizzato sempre il while per leggere i messaggi... purtroppo sono obbligato ad utilizzare "\n" per l'invio dei messaggi perchè sennò i messaggi non partono dal server... penso sia una convenzione.

Ti sembra macchinoso perchè stai usando l'oggetto "sbagliato" per ciò che chiedi di fare.
BufferedReader è un oggetto che serve a leggere righe di testo da una sorgente in modo bufferizzato. Esso ritorna "null" quando raggiunge la fine della sorgente (quindi, quando incontra l'EOF della sorgente).

Una socket è una sorgente particolare: non ha una fine (se non quando viene chiusa). Quindi per usare in modo corretto BufferedReader con una Socket, colui che riceve i dati deve sapere quanti dati riceverà, o, per lo meno, deve avere un modo per capire quando i dati sono finiti. Questo, in gergo, si chiama protocollo di comunicazione.

Il protocollo lo scegli tu, ma deve essere solido (essere coerente e non permettere ambiguità): o informi il ricevente del numero di righe che invierai, o il ricevente è a conoscenza di una particolare riga che ne indica la fine.


Ciao.

[hackerdm]

potrei stabilire una sorta di convenzione per la fine delle righe da leggere... secondo te non è corretto utilizzare l'oggetto BufferReader nel mio caso??

grazie mille anche a te per il tuo aiuto

[valia]

si ma devi supporre che sia un carattere molto particolare e chep er sbaglio non sia contenuto dentro il tuo messaggio (può succedere): resto dell'idea che inviare prima il numero di righe da ricevere sia la cosa migliore