[java,c++] CLIENT-SERVER

[nuovoUtente86]

Faccio un esempio ma serve per capire un discorso piu generale:
ipotizziamo che il server sia scritto in java per cui avrò in ascolto un server Socket

serverSocket.accept();


ipotizzando di dover scambiare nome e cognome scrivendo il client in Java si potrebbe scambiare una semplice stringa,ma lavorando con linguaggi differenti l' unica soluzione è lavorare sui flussi di Byte?Ovviamente il discorso si estende a linguaggi differenti e alla gestione di protocolli ben piu complessi di una stringa.

[andbin]

Originariamente inviato da nuovoUtente86

ipotizzando di dover scambiare nome e cognome scrivendo il client in Java si potrebbe scambiare una semplice stringa,ma lavorando con linguaggi differenti l' unica soluzione è lavorare sui flussi di Byte?Ovviamente il discorso si estende a linguaggi differenti e alla gestione di protocolli ben piu complessi di una stringa.

I socket sono orientati ai byte, questo vale in qualunque linguaggio, java, c/c++, c# ecc....

Cosa c'è "al di sopra" nel flusso di byte, dipende dal "protocollo" che è stato progettato. Se il protocollo prevede di scambiare stringhe, ad esempio, la prima questione che mi viene in mente è quella del charset da usare. Se invece prevedesse di scambiare dati binari come int, long, ecc..., la questione è quella dell'endian.

[nuovoUtente86]

Quello che voglio dire,una volta acquisito il canale se lavorassi con 2 entità java potrei utilizzare un metodo o meglio uno stream orientato allo scambio di Object per cui il client invia una stringa e il server sa come castizzarla,che poi sotto il "cofano" avvenga tutto in modo serializzato è normale.Ma se un client C++deve inviare una Stringa al server java questo deve poi ricomporsela a partire dai byte...e non puo piu essere utilizzato uno stream come ObjectInputStream ad esempio

[andbin]

Originariamente inviato da nuovoUtente86

Quello che voglio dire,una volta acquisito il canale se lavorassi con 2 entità java potrei utilizzare un metodo o meglio uno stream orientato allo scambio di Object per cui il client invia una stringa e il server sa come castizzarla,che poi sotto il "cofano" avvenga tutto in modo serializzato è normale.Ma se un client C++deve inviare una Stringa al server java questo deve poi ricomporsela a partire dai byte...e non puo piu essere utilizzato uno stream come ObjectInputStream ad esempio

Eh no. Se vuoi che il protocollo possa essere usato da diversi linguaggi/piattaforme, devi prima pensare il protocollo in maniera più generica e ampia.

Con Java puoi prendere un oggetto e serializzarlo facilmente con ObjectOutputStream. Certo è vero che il C++ non ha un ObjectInputStream e non saprebbe nulla della serializzazione di Java ma tu potresti documentarti bene sulla serializzazione di Java (le specifiche ci sono) e realizzare il codice in C++ che interpreta il flusso di dati. Questo ovviamente con tutte le problematiche che comporta .....

Dal mio punto di vista non sarebbe la soluzione giusta anche se in teoria fattibile.

[nuovoUtente86]

in pratica una volta che le specifiche del protocollo sono state definite diventa trasparente al linguaggio utilizzato per i client e i server,l' importante che riescano a sincronizzarsi sulle specifiche stesse.?

[andbin]

Originariamente inviato da nuovoUtente86

in pratica una volta che le specifiche del protocollo sono state definite diventa trasparente al linguaggio utilizzato per i client e i server,l' importante che riescano a sincronizzarsi sulle specifiche stesse.?

Il linea di massima sì, è così.

[nuovoUtente86]

e se si trattasse di scambiare un file,la maggiore universalità del file stesso ci semplificherebbe la vitaoppure è la medesima cosa?

[andbin]

Originariamente inviato da nuovoUtente86

e se si trattasse di scambiare un file,la maggiore universalità del file stesso ci semplificherebbe la vitaoppure è la medesima cosa?

Trasferire un file è forse la cosa meno complicata, perché non devi stare a preoccuparti di charset, endian, ecc....
Un host legge il file e invia lo stream di byte, l'altro host legge lo stream e scrive su file.

[71104]

aggiungo: è proprio per non doversi preoccupare dell'endianness che molti protocolli per Internet di livello Application sono ASCII, vedi ad esempio HTTP, POP ed SMTP, IRC, MSN...
l'unico contro dell'avere un protocollo ASCII è il consumo di banda lievemente maggiore. ad esempio per spedire un numero intero in ASCII lo dovrò tipicamente spedire in forma testuale scritto in base 10, quindi mentre con un protocollo binario userò solamente 4 bytes con un protocollo ASCII ne userò un numero variabile da 1 a una decina.

[nuovoUtente86]

Originariamente inviato da andbin

Trasferire un file è forse la cosa meno complicata, perché non devi stare a preoccuparti di charset, endian, ecc....
Un host legge il file e invia lo stream di byte, l'altro host legge lo stream e scrive su file.

Se dovessi scrivere una applicazione java che invia un file ad altre applicazioni non scritte in java come lo implementeresti o meglio quali strumenti java andresti ad utilizzare,probabilmente utilizzare la classe File è scorretto in quanto si tratterebbe di inviare un Object.

[andbin]

Originariamente inviato da nuovoUtente86

Se dovessi scrivere una applicazione java che invia un file ad altre applicazioni non scritte in java come lo implementeresti o meglio quali strumenti java andresti ad utilizzare,probabilmente utilizzare la classe File è scorretto in quanto si tratterebbe di inviare un Object.

Ma no.
Non devi inviare un oggetto File ... che tra l'altro non ha nulla a che fare con il contenuto fisico del file, visto che File rappresenta solo una "astrazione" del nome di un file.

L'ideale è pensare al protocollo. Trasferire un file significa trasferire in sequenza tutti i byte del file così come sono (e come abbiamo detto i socket sono orientati ai byte).

Per fare una buona cosa lo stream di dati potrebbe essere:

+-----------+---------/ /----------+
| lunghezza |  contenuto del file  |
+-----------+---------/ /----------+

dove 'lunghezza' sono 4 byte che formano un int e il resto è lo stream di byte letto dal file.
La lunghezza è utile al ricevente perché così sa quanti byte deve aspettarsi.

[nuovoUtente86]

si concettualmente avevo intuito,ma in codice java a grandi linee come lo faresti.

[andbin]

Originariamente inviato da nuovoUtente86

si concettualmente avevo intuito,ma in codice java a grandi linee come lo faresti.

Usando DataOutputStream.

OutputStream os = socket.getOutputStream ();

DataOutputStream dos = new DataOutputStream (os);

int len = file.length ();

InputStream is = new FileInputStream (file);

byte[] buf = new byte[512];

int n;

dos.writeInt (len);

while ((n = is.read (buf)) > 0)
    dos.write (buf, 0, n);

is.close ();
dos.close ();

dove 'socket' è il socket e 'file' è un oggetto File.

Il codice dovrebbe essere ok, salvo errori/omissioni ... l'ho scritto di getto e comunque c'è da aggiungere una valida gestione delle eccezioni.

Nota che writeInt scrive un int in un formato ben preciso e indipendente dalla piattaforma: in Big-Endian. Vuol dire che se un file è lungo 1000 byte (3E8h) i primi 4 byte dello stream sono 00h 00h 03h E8h

[nuovoUtente86]

Originariamente inviato da andbin

Usando DataOutputStream.

OutputStream os = socket.getOutputStream ();

DataOutputStream dos = new DataOutputStream (os);

int len = file.length ();

InputStream is = new FileInputStream (file);

byte[] buf = new byte[512];

int n;

dos.writeInt (len);

while ((n = is.read (buf)) > 0)
    dos.write (buf, 0, n);

is.close ();
dos.close ();

dove 'socket' è il socket e 'file' è un oggetto File.

Il codice dovrebbe essere ok, salvo errori/omissioni ... l'ho scritto di getto e comunque c'è da aggiungere una valida gestione delle eccezioni.

Nota che writeInt scrive un int in un formato ben preciso e indipendente dalla piattaforma: in Big-Endian. Vuol dire che se un file è lungo 1000 byte (3E8h) i primi 4 byte dello stream sono 00h 00h 03h E8h

Ok grazie 1000.