[Java]Problema readLine() su connessione ssh

[watermark]

Puoi fare così: leggi e bufferizzi, così puoi analizzare tutto l'output del server; quando il server ha terminato ciò che doveva fare restituisce il prompt (e quindi $ o #, che puoi utilizzare come condizione di uscita).

[valia]

tutte le read a meno di una chiusura esplicita sono bloccanti.
Chiedevo se pilota il server perchè in questo caso indica appunto un messaggio ( o meglio sequenza di byte ) che liberano lo stream momentaneamente consentendo alla comunicazione di proseguire.
La soluzione del thread mi sembra la più adatta in questo frangente, occhio a rilevare anche le condizioni di blocco/chiusura della comunicazione.
Inoltre, se la comunicazione è terminata (perché il metodo è finito) e arrivano dati, che fai?

[valia]

Originariamente inviato da watermark
Puoi fare così: leggi e bufferizzi, così puoi analizzare tutto l'output del server; quando il server ha terminato ciò che doveva fare restituisce il prompt (e quindi $ o #, che puoi utilizzare come condizione di uscita).

quello che dicevo io, usare una sequenza di uscita, ma lo può fare se pilota l'altro capo (quindi il server), altrimenti è una soluzione inapplicabile)

[AtoXx]

vi ringrazio entrambi per le risposte, adesso allora valuterò quale soluzione intraprendere. Pensavo che si potesse fare qualcos'altro di più "elegante" Comunque grazie lo stesso

[watermark]

Ma è ovvio che il server è "pilotato"! Effettuare una connessione ssh verso un server significa aprire una socket tcp, quindi una comunicazione client-server punto-punto. Nell'ambito di questa sessione il client ssh effettua delle richieste e ragionevolmente già immagina determinate risposte; in ogni caso il server ad ogni comando ricevuto effettua delle elaborazioni e alla fine restituisce sempre il prompt in attesa di altri comandi. Se il client non chiede nulla, il server non manda nulla...
Un thread a parte è sicuramente la soluzione più efficiente, ma anche la più difficile... O almeno dipende da cosa deve fare il programma, perché occorre sincronizzare la comunicazione tra client e server (già di per sé da sincronizzare) con le altre operazioni svolte dal thread principale.

[valia]

non hai capito, pilotato da me!!! Sono io a decidere cosa risponde e quando risponde (quindi fargli rispondere picche anziché cuori)
Se tu hai un server ssh scritto da terze parti e questo è così e non sono possibili variazioni, come fai a forzare la risposta che vuoi?
Questo è parte di un ampio insieme che purtroppo noi non conosciamo

[watermark]

Non ho capito a cosa ti riferisci, che significa un server ssh scritto da terze parti?
ssh è un protocollo che permette una comunicazione criptata tra un client e un server all'interno di un tunnel, quindi in maniera molto semplicistica si può dire che è solo il mezzo attraverso cui mandi dei comandi ad una macchina. Lo scenario più frequente (o almeno quello visto da me) è accedere ad un server Linux mediante ssh e lanciare dei comandi... A questo punto su una macchina Linux sia i comandi che le risposte sono standard: se gli mando un ps, sono già sicuro che il server mi risponde con la lista dei processi in esecuzione in un determinato formato... Non è che io gli mando ps e lui mi risponde hello world!...

[valia]

bah a volte mi chiedo se parlo arabo o altro.
Un qualsiasi server ssh ad un comando risponde con quello che tu hai detto (cioè ps risponde con la lista dei processi e si mette in attesa di un nuovo comando).
Ma ssh (e ricordiamocelo) è un protocollo di comunicazione, quindi tu puoi dare una serie di comandi e puoi decidere che questi comandi finiscano nella tua implementazione.
TI assicuro che è possibile wrappare un servizio in un altro servizio che in determinati contesti risponda come ti pare inteso come TERMINAZIONE, quindi puoi decidere che a ps rispondono con la lista dei processi altri rispondono con la lista dei processi + EOF (se a te interessa ad esempio subito chiudere lo stream o cmq dare un determinato segnale).
A questo punto tu hai rispettato l'ssh, hai aggiunto una info necessaria a te per chiudere/rilasciare lo stream e non hai usato un thread.

Se questo non è possibile ovviamente (significa che non puoi fare un append brutale) significa che devi trovare un'altro modo per "sbloccare" un qualsiasi stream in attesa.

[AtoXx]

Originariamente inviato da valia
quello che dicevo io, usare una sequenza di uscita, ma lo può fare se pilota l'altro capo (quindi il server), altrimenti è una soluzione inapplicabile)

infatti hai ragione a quanto pare non c'è modo se non piloto lato server

[AtoXx]

Originariamente inviato da watermark
Ma è ovvio che il server è "pilotato"! Effettuare una connessione ssh verso un server significa aprire una socket tcp, quindi una comunicazione client-server punto-punto. Nell'ambito di questa sessione il client ssh effettua delle richieste e ragionevolmente già immagina determinate risposte; in ogni caso il server ad ogni comando ricevuto effettua delle elaborazioni e alla fine restituisce sempre il prompt in attesa di altri comandi. Se il client non chiede nulla, il server non manda nulla...
Un thread a parte è sicuramente la soluzione più efficiente, ma anche la più difficile... O almeno dipende da cosa deve fare il programma, perché occorre sincronizzare la comunicazione tra client e server (già di per sé da sincronizzare) con le altre operazioni svolte dal thread principale.

In pratica quando invia il prompt in attesa di comandi non manda il fine stringa che @@.
Non volevo fare il thread proprio perchè mi verrebbe un macello fare la sincronizzazzione dell'output con il client. Ma a quaesto punto sono costretto a farlo :S