Java Client Server

[linux_r]

ClientConnection mi pare più sensato che sia una normale classe, con metodi di istanza che forniscono le "primitive" del tuo protocollo di comunicazione, nascondendo i dettagli tecnici interni.

Quindi va bene cosi ClientConnection?

Intendi interfaccia Swing? Allora considera anche tutte le implicazioni sul threading in Swing, ovvero il networking non dovrebbe essere fatto nel contesto del Event Dispatch Thread ma in un thread a parte (con quello che ne comporta).

Ma ad esempio se ho un form dove mi si chiede di inserire user e pass, e quando premo il tasto ok le info vengono inviate al server mediante un action listener installato sul button "ok", in quell'action listener , e quindi nel suo metodo actionPerformed , posso usare la classe ClientConnection ad esempio(Supponendo che non mi occorra "globale") e inviare tali informazioni? però poi sarebbe un lavoro compiuto dall'evt . QUindi o dovrei implementare runnable su ClientConnection oppure creare un nuovo Thread all'interno dell'actionperformed e comunque dire all'evt di aspettare che esso termini per verificare che la connessione è avvenuta? Cosa proponi?

[linux_r]

Inoltre volevo chiederti quando devo utilizzare altri metodi per contattare il server, poichè se chiudo gli stream si chiude il socket , nelgli altri metodi posso richiamare nuovoamente getOutputStream ?

[andbin]

Quindi va bene cosi ClientConnection?

Quanto hai postato è poco, quindi non posso dire se è e sarà davvero ok. A grandi linee sì. Vedo che come address hai preso fisso il "localhost" e la porta è anch'essa fissa. Se ti serve solo così, ok, altrimenti sarebbe più flessibile poter configurare address+port.

Ma ad esempio se ho un form dove mi si chiede di inserire user e pass, e quando premo il tasto ok le info vengono inviate al server mediante un action listener installato sul button "ok", in quell'action listener , e quindi nel suo metodo actionPerformed , posso usare la classe ClientConnection ad esempio(Supponendo che non mi occorra "globale") e inviare tali informazioni? però poi sarebbe un lavoro compiuto dall'evt . QUindi o dovrei implementare runnable su ClientConnection oppure creare un nuovo Thread all'interno dell'actionperformed e comunque dire all'evt di aspettare che esso termini per verificare che la connessione è avvenuta? Cosa proponi?

Tutte le operazioni con un oggetto della tua ClientConnection sarebbero da fare in un thread a parte, non nel EDT. Questo ovviamente complica un po' le cose ma si può fare e in svariati modi .... dipende da quanto sei ferrato su thread e sincronizzazione in generale.

Un possibile scenario è avere un thread a parte che si occupa di tutta la comunicazione. Visto che non si può "invocare" qualcosa nel contesto di un altro thread, generalmente per far comunicare/cooperare 2 o più thread si usano delle strutture dati sincronizzate. In questo caso basta una "coda" sincronizzata, thread-safe e ovviamente condivisa tra EDT e il thread di comunicazione. Il thread che opera sul networking è sempre in attesa, bloccato, di "comandi". Tu pubblichi sulla coda un "comando" (modellato con un oggetto, es. la "connessione" o l' "invio" di un dato) e l'altro thread si sblocca ed opera il comando. Appena ha dei risultati, potrebbe fare in modo che venga eseguito nel EDT un Runnable che magari aggiorna qualcosa sulla interfaccia grafica.

Diventa molto asincrono, certo ma è fattibile. Nulla di tutto questo è davvero "difficile" ma bisogna essere un po' "versatili" su thread, sincronizzazione e un po' su strutture dati basilari.

Inoltre volevo chiederti quando devo utilizzare altri metodi per contattare il server, poichè se chiudo gli stream si chiude il socket , nelgli altri metodi posso richiamare nuovoamente getOutputStream ?

No, una volta che il socket è chiuso non puoi più riaprire la comunicazione con quello stesso oggetto Socket. Devi istanziare un nuovo oggetto Socket.

[linux_r]

quindi poichè voglio utilizzare sempre la stessa connessione già creata , ad esempio all'interno del metodo connect non devo chiudere gli stream esatto?

[andbin]

all'interno del metodo connect non devo chiudere gli stream esatto?

In connect() sicuramente no. Puoi (e dovresti) invece offrire un close() (o disconnect() .. scegli tu il nome).

[linux_r]

In connect() sicuramente no. Puoi (e dovresti) invece offrire un close() (o disconnect() .. scegli tu il nome).

posso impostare gli stream come campi private della classe?

[andbin]

posso impostare gli stream come campi private della classe?

Naturalmente sì. In pratica nell'oggetto tieni: il socket, gli stream e qualunque altro dato/oggetto che ti può servire (es. buffer, variabili di stato, ecc...).

[linux_r]

ti ringrazio davvero tanto della tua disponibilità e delle tue dritte

[linux_r]

ti chiedo solo un ' ultima cosa riguardo a quel discorso dell' edt dove posso trovare qualcosa che parla dei possibili scenari da implementare?

[andbin]

ti chiedo solo un ' ultima cosa riguardo a quel discorso dell' edt dove posso trovare qualcosa che parla dei possibili scenari da implementare?

Eh .. non lo so. Sono scenari abbastanza specifici e non so se c'è una "guida" per questo. Principalmente è conoscendo un po' a fondo thread, thread-pool, sincronizzazione, ecc... che riesci ad avere automaticamente un buon quadro di cosa si può fare e cosa non si dovrebbe fare.