[Java]Problema readLine() su connessione ssh

[watermark]

Onestamente non ho mai visto cose del genere in tanti anni di server Linux... E ancora più onestamente non capisco perché introdurre strati aggiuntivi e complicare la comunicazione a fronte di un'utilità (a mio parere) davvero minima... Ho sempre pensato che quando al client serve qualcosa lo chiede al server, il server risponde con quello che serve al client e si rimette in attesa col prompt.. Quando il client ha ottenuto tutto ciò che voleva e non gli serve più niente è lui a chiudere la comunicazione... Se vai dal salumiere e chiedi 100 grammi di mortadella, lui ti dà quello che hai chiesto, paghi e te ne vai... Non è che devi aspettare che sia lui a dirti "ok, ora puoi andare", oppure che continua a tagliare mortadella quando hai pagato e sei uscito... Non so se rendo l'idea...

[watermark]

@AtoXx: no, normalmente non manda nessun fine stringa (a meno di situazioni particolari e fuori standard come scoperto in questa discussione), ma poco male... Fai il confronto con il simbolo del prompt: quando arriva sei sicuro che il server ha terminato ed è in attesa del prossimo comando (che può essere anche la chiusura se non ti serve più niente).

[valia]

purtroppo lo stream java nel metodo read si aspetta che tu gli dici "ho finito", so che sembra assurdo, ma questo è un chiaro caso in cui wrappare ti fa rilasciare le risorse (a meno di mettere su meccanismi di sincronizzazione.
Lo stream java vuole
"dammi 200 gr di salame e dimmi quando hai finito"
e il salumiere
"tieni 200 gr di salame e ho finito"

E' chiaro che se tu STAI scrivendo il tuo servizio, è logico che fissi le tue regole, se ne usi uno esistente, ti prendi le regole che hai e sincronizzi.


NOTA:
ti faccio notare che qui la necessità di sentirsi dire "ok ora puoi andare" è dello stream java, non del servizio in sè, non so se mi hai capita

[AtoXx]

Ho risolto facendo questa funzione:

String leggi() {
        String prova = new String();
        int flag = 0;
        byte[] buffer = new byte[1024];
        int bytesRead = 0;
        try {while ((bytesRead = bis.read(buffer)) != -1) {

                risultato = new String(buffer, 0, bytesRead);

                prova = prova.concat(risultato);


                if (prova.contains("~ #") && flag == 1) {
                    System.out.println("trovato, esco");
                    break;
                }

                if (prova.contains("~ #")) {
                    System.out.println("flag=1");
                    prova = "";
                    flag = 1;
                }



            }
            System.out.println(prova);



        } catch (IOException ex) {
            Logger.getLogger(Leggi.class.getName()).log(Level.SEVERE, null, ex);
            return null;
        }
        try {
            bis.close();
            //br.close();
            return prova;
        } catch (IOException ex) {
            Logger.getLogger(Leggi.class.getName()).log(Level.SEVERE, null, ex);
            return null;
        }
    }

Grazie a tutti per l'aiuto

[watermark]

@AtoXx: sono contento che alla fine, nonostante tutte queste chiacchiere, tu abbia risolto il problema... Il forum è servito!!

@valia: alla fine stiamo dicendo la stessa cosa, lo so bene come funzionano gli stream in java... Ma il fatto è che gli stream non si autogenerano né autodistruggono, è sempre il programmatore che li crea, li gestisce e li chiude (se tutto è ben gestito ovviamente). Ora quello che volevo dire è che non è necessario che il server reinventi la ruota con meccanismi opinabili, perché a qualsiasi comando Linux l'interprete risponde e restituisce sempre il prompt in attesa di altri comandi. Ciò è uno standard e vale per tutte le shell DOS e UNIX. Quindi il programmatore, sapendo ciò, può gestire tranquillamente la chiusura dello stream quando vuole e senza troppi problemi, basta aspettare l'arrivo del carattere in questione. Con queste considerazioni sono io client che vado via quando voglio e non devo aspettare l'ok di nessuno.

[valia]

si e hai ragione, ma questo contempla un comando, ma se devi eseguire più comandi e non usi un thread per sincronizzarti, come sblocchi l'attesa? E' un cane che si mangia la coda, è chiaro come funziona lo standard,è anche chiaro come far funzionare tutto senza ad ogni comando aprire/chiudere stream.
Ora è comunque un quadro generale, stiamo un po' uscendo dal seminato, ci si sincronizza con thread e va bene.
A te fa strano, io di server leggermente modificati/wrappati ne ho visti (non parlerei altrimenti)

[watermark]

Certo, ci credo che esiste anche altro che non ho visto... E sono anche d'accordo che siamo usciti un po' fuori dal seminato... Comunque giusto per concludere, non è poi così difficile creare un client ssh... A parte che esistono le API Apache Commons Net, ma poi io farei (anzi, ho fatto in più occasioni) così:

1) apro sessione ssh e mi loggo

2) lancio comando 1, bufferizzo output e aspetto prompt

3) lancio comando 2, bufferizzo output e aspetto prompt

...

n) lancio comando n, bufferizzo output e aspetto prompt

n+1) ho finito e chiudo la sessione ssh

Quindi non devo aprire/chiudere continuamente gli stream (la sessione è sempre attiva) e posso fare tutto nello stesso thread. Il problema di sincronizzazione è con un eventuale thread principale, se deve utilizzare i risultati intermedi della mia sessione ssh. Ciao!!

[valia]

ehehe menomale siamo caduti nel caso generico e menomale che ci siamo capiti

[watermark]

Eh si... E meno male che questo caso generico si verifichi nel 99% dei casi... Altrimenti i programmatori andrebbero al manicomio!!!