[JAVA]socket e newsreader

[Frank1962]

ho deciso un pò per gioco, un pò per curiosità di voler creare un newsreader in java ma ho qualche problema con l'utilizzo del socket:

public class TCPClient {
  
  
    public void start()throws IOException {
      
        //Connessione della Socket con il Server
        Socket socket = new Socket("news.tin.it", 119);

        //Stream di byte da passare al Socket
        DataOutputStream os = new DataOutputStream(socket.getOutputStream());
        DataInputStream is = new DataInputStream(socket.getInputStream());
        BufferedReader stdIn = new BufferedReader(new InputStreamReader(System.in));

        //Ciclo infinito per inserimento testo del Client
        while (true) {
          
           System.out.println(is.readLine());
           System.out.print("Inserisci: ");
           String userInput = stdIn.readLine();
           
           //esco dal ciclo se digito quit
           if  (userInput.equals("QUIT"))
              break;
            
           os.writeBytes(userInput + '\n');
           System.out.println(is.readLine());
        }

        //Chiusura dello Stream e del Socket
        os.close();
        is.close();
        socket.close();
   }
   
   
   public static void main (String[] args) throws Exception {
        TCPClient tcpClient = new TCPClient();
        tcpClient.start();
   }
   
   
}

Questo codice si collega al server delle news di tin.it alla porta 119 .......la connessione come vedete funziona dato che il server risponde ma non riesco a capire come mai quando digito un comando il programma si blocca rimanendo cmq in esecuzione senza segnalare niente (neanche un errore)!

per esempio se dal prompt del dos prova a digitare "telnet news.tin.it 119" comparirà la scritta "200 news.tin.it (Twister v1.2.0)", poi magari scrivendo "help" puosso sapere i comandi per naviagare nel server delle news ........con il socket java invece ogni comando mi blocca il programma!

sapete mica cosa può essere?

[PGI]

il server news è esigente quanto al carattere terminatore.


Per risolvere, questo:

os.writeBytes(userInput + '\n');

diventa:

os.writeBytes(userInput + '\r' + '\n');
os.flush();

Ciao.

[LukeHack]

Originariamente inviato da PGI
il server news è esigente quanto al carattere terminatore.


Per risolvere, questo:

os.writeBytes(userInput + '\n');

diventa:

os.writeBytes(userInput + '\r' + '\n');
os.flush();

Ciao.

come mai l'uso di \r è necessario?

[PGI]

Questo non lo so.

Il terminatore di linea pare dipendere dal sistema operativo (secondo la documentazione Java).

Non sempre un "\n" va bene per l'OS (ma va sempre bene per Java).

Si può notare quando cerchi di scrivere un file di testo e termini le linee con "\n" anzichè System.getProperty("line.separator"). Usando Notepad (in Windows) per aprire il file si nota come vi sia una linea unica (del "\n" se ne frega). Wordpad al contrario digerisce tutto. Per Unix invece non ci sono problemi.

Ho pensato che il servizio news rispondesse ad una logica simile e così "ho provato". Mi è andata bene.

Ciao.

[LukeHack]

Originariamente inviato da PGI
Questo non lo so.

Il terminatore di linea pare dipendere dal sistema operativo (secondo la documentazione Java).

Non sempre un "\n" va bene per l'OS (ma va sempre bene per Java).

Si può notare quando cerchi di scrivere un file di testo e termini le linee con "\n" anzichè System.getProperty("line.separator"). Usando Notepad (in Windows) per aprire il file si nota come vi sia una linea unica (del "\n" se ne frega). Wordpad al contrario digerisce tutto. Per Unix invece non ci sono problemi.

Ho pensato che il servizio news rispondesse ad una logica simile e così "ho provato". Mi è andata bene.

Ciao.

capisco, ma se \n è l'accapo, \r in teoria a cosa serve?

[PGI]

"\r" sta per "ritorno carrello" (termini da Olimpia...). Il cursore torna (a volte...) al punto di partenza, sulla stessa linea.

\r serve se \n non basta, nel senso che il sistema richiede la combinazione dei due caratteri come messaggio "hey, è finita la linea!".

[LukeHack]

Originariamente inviato da PGI
"\r" sta per "ritorno carrello" (termini da Olimpia...). Il cursore torna (a volte...) al punto di partenza, sulla stessa linea.

\r serve se \n non basta, nel senso che il sistema richiede la combinazione dei due caratteri come messaggio "hey, è finita la linea!".

grazie,buono a sapersi

[Frank1962]

aggiungendo la /r adesso funziona ....il problema però è quando vado a leggere: in pratica utilizzando il metodo .readline mi legge solo la prima riga della risposta del server ....provando invece a utilizzare il metodo .read convertendo successivamente in char mi si presenta di nuovo il problema che si blocca

[PGI]

E' lo stesso problema, solo "invertito". Occorre cercare di capire quale sia il carattere terminatore inviato dal server al client per dire "ho finito di parlare".

Ma stò server news non ha una documentazione?

Ciao.

[cionci]

Tutti i servizi di Internet richiedono \r\n come terminatori di linea... Ad esempio anche l'HTTP...

[Frank1962]

Originariamente inviato da PGI
E' lo stesso problema, solo "invertito". Occorre cercare di capire quale sia il carattere terminatore inviato dal server al client per dire "ho finito di parlare".

Ma stò server news non ha una documentazione?

Ciao.

ma io vado a leggere l'oggetto inputstream ....cosa centra il carattere che mando al server quando sono in lettura?

[PGI]

Tu sei il client, lui è il server.

Qui c'entra il simbolo con cui il server indica che ha terminato di trasmettere i dati.

Hai detto che fai un readLine sull'input e ti legge una linea.

Se il messaggio fosse composto da una sola linea, otterresti lo stesso risultato (blocco apparente) di quello che ottieni cercando di leggere un carattere per volta.

Questo perchè non intercetti il terminatore del flusso dati.

Scopri qual'è e hai risolto il problema.

Ciao.

[Frank1962]

Originariamente inviato da PGI
Tu sei il client, lui è il server.

Qui c'entra il simbolo con cui il server indica che ha terminato di trasmettere i dati.

Hai detto che fai un readLine sull'input e ti legge una linea.

Se il messaggio fosse composto da una sola linea, otterresti lo stesso risultato (blocco apparente) di quello che ottieni cercando di leggere un carattere per volta.

Questo perchè non intercetti il terminatore del flusso dati.

Scopri qual'è e hai risolto il problema.

Ciao.

mettiamo che il terminatore di linea è un punto "." ...come dovrei fare per indicarglielo al server?

[PGI]

Provo a spiegarmi meglio.

Poichè stai leggendo dal server non puoi indicare nulla. Devi solo interpretare i dati che il server news invia al tuo client. Tra questi c'è un carattere che indica che il messaggio è finito.

Secondo me hai bisogno di sapere qual'è quel carattere per poter dire al ciclo di lettura di terminare.

[cionci]

Frank1962: il server rispetta delle specifiche date in una RFC... Le specifiche indicano quale debba essere *obbligatoriamente* il terminatore di un messaggio...

Ecco l'RFC 977: http://www.freesoft.org/CIE/RFC/977/

[Frank1962]

Originariamente inviato da PGI
Provo a spiegarmi meglio.

Poichè stai leggendo dal server non puoi indicare nulla. Devi solo interpretare i dati che il server news invia al tuo client. Tra questi c'è un carattere che indica che il messaggio è finito.

Secondo me hai bisogno di sapere qual'è quel carattere per poter dire al ciclo di lettura di terminare.

allora, spulciando la RFC sono riuscito a capire/trovare/captare/ecc.. quale sia questo maledetto segno di terminazione del messaggio --> " \r\n.\r\n " ..che in codice ASCII equivale alla sequenza di byte: " 13-10-46-13-10 " !!

devo ancora capire come mai quei 9 caratteri mi vengono codificati in ASCII con soli 5 byte!

cmq come faccio a far leggere lo stream dei dati senza che mi si blocchi il prg? ....cioè potrei implementare un algoritmo ultracomplesso che mi vadi a controllare gli ultimi 5 byte letti ma mi sembra troppo lamma come soluzione ........non c'è qualche metodo ad hoc che mi permetta di far ciò ?

ps: come mai il metodo readline me lo segna come "deprecated" ?

[cionci]

Originariamente inviato da Frank1962
allora, spulciando la RFC sono riuscito a capire/trovare/captare/ecc.. quale sia questo maledetto segno di terminazione del messaggio --> " \r\n.\r\n " ..che in codice ASCII equivale alla sequenza di byte: " 13-10-46-13-10 " !!

devo ancora capire come mai quei 9 caratteri mi vengono codificati in ASCII con soli 5 byte!

Guarda che qulli non sono 9 caratteri, ma solamente 5... \n è un solo carattere...

Semplicemente:
if(buf[n-1] == '\n' && buf[n-2] == '\r' && buf[n-3] == '.' buf[n-4] == '\n' && buf[n-5] == '\r')

[Frank1962]

si in effetti avevo capito già prima che il terminatore poteva essere in pratica quel punto tra 2 "a capo" però ho scartato l'idea perchè pensavo fosse banale come soluzione ....cioè se uno posta una messaggio su un newsgroup con in mezzo un set di caratteri uguale a quelli del terminatore che succede? ...il server/client salva solo metà msg?

cmq ho buttato giù questo codice in sostituzione al metodo readline che usavo prima:

public String leggiInput() {


     int count = 0;
     boolean go = true;
     Vector vect = new Vector();
     
     
     try {

       while(go) {

         vect.add(""+is.readByte());

         if(count > 4) {
           
           if( (char)(Integer.parseInt((String)vect.get(count-0))) == '\n' )
             if( (char)(Integer.parseInt((String)vect.get(count-1))) == '\r' )
               if( (char)(Integer.parseInt((String)vect.get(count-2))) == '.' )
                 if( (char)(Integer.parseInt((String)vect.get(count-3))) == '\n' )
                   if( (char)(Integer.parseInt((String)vect.get(count-4))) == '\r' )
                     go = false;              
         }
         
         count++;
       }

     } catch(Exception e) { System.out.println(e); }
     
     
     Object[] arrayObject = vect.toArray();
     char[] arrayChar = new char[arrayObject.length];
     
     for(int i=0;i<arrayObject.length;i++) {
       arrayChar[i] = (char)(Integer.parseInt((String)arrayObject[i])); 
     }
     
     String msgText = new String(arrayChar);
     return msgText;
   }

...non sò perchè ma mi sembra di aver scritto una boiata sia per lunghezza che per complessità non necessaria ....oltretutto perchè mi traduce il carattere "è" come una "?" !!?

[LukeHack]

Originariamente inviato da Frank1962
si in effetti avevo capito già prima che il terminatore poteva essere in pratica quel punto tra 2 "a capo" però ho scartato l'idea perchè pensavo fosse banale come soluzione ....cioè se uno posta una messaggio su un newsgroup con in mezzo un set di caratteri uguale a quelli del terminatore che succede? ...il server/client salva solo metà msg?

cmq ho buttato giù questo codice in sostituzione al metodo readline che usavo prima:

innanzi tutto fai troppi cast,perchè usi Vector se poi lo riduci a char[]?
usa direttamente String no? gia risparmieresti belle righe di casting inutile...
poi vabbè,l'uso del DataInputStream io lo sostituirei con un buffered,più efficiente il controllo che poi esegui,sulla stringa per cercare i caratteri terminatori, è ridondante (per essere eufemistici)

 StringBuffer s=new StringBuffer();
int count=0;
  while(go) {

        s= s.append((char) is.readByte());

         if(count > 4) {
           
           if( (s.charAt(count)== '\n' )&&(  s.charAt(count-1) == '\r' )&&
            if( s.charAt(count-2)== '.' )&& (s.charAt(count-3)== '\n' )
             &&(  s.charAt(count-4)== '\r' )  )
                     go = false;              
         }
         
         count++;
       }

       return s.subString(0,count);
}

se non ho scritto fesserie vista l'ora dovrebbe andare

[cionci]

Originariamente inviato da Frank1962
si in effetti avevo capito già prima che il terminatore poteva essere in pratica quel punto tra 2 "a capo" però ho scartato l'idea perchè pensavo fosse banale come soluzione ....cioè se uno posta una messaggio su un newsgroup con in mezzo un set di caratteri uguale a quelli del terminatore che succede? ...il server/client salva solo metà msg?

Prova a mettercelo... Ora non mi ricordo come si comportano il POP3 e l'SMTP...entrambi usano lo stesso emtodo per terminare i messaggi... Infatti se spedisci un messaggio di posta in PLAIN TEXT riesci a vedere anche il punto in fondo
Comunque credo che il comportamento in questi casi sia a discrezione del mail client...ad esempio potrebbero sostituire ogni sequenza del genere con due punti...oppure se è un messaggio HTML con una codifica del punto... Fai una prova e guarda cosa ricevi