[C] dubbio send e recv su programma client-server

[Mettiu_]

Originariamente inviato da Eddie1985

Cosa mi consigliate? Quale è la dimensione opportuna da inviare secondo voi?

Discorso lungo...
Ogni send (almeno in linea di principio) diventa un pacchetto del flusso TCP o, nel caso la quantità di dati sia troppo grande per un singolo pacchetto, viene frammentata in N pacchetti che poi il ricevitore ricompone. Per massimizzare l'efficienza dovresti fare pacchetti più grande possibile in modo da minimizzare il numero di pacchetti e, di conseguenza, l'overhead dovuto agli header TCP, IP, ecc che devi aggiungere ad ogni pacchetto. D'altro canto, se fai pacchetti grandi, se se ne perde uno e TCP deve ritrasmetterlo, ritrasmetterà una quantità di dati maggiore. Insomma, è un compromesso: per grosse quantità di dati, io farei pacchetti grossi (non meno di 512-1024 byte alla volta)

[Mettiu_]

Originariamente inviato da starfred

Io immagino che tu stia in un sistema multithread, nel quale ogni thread gestisce un socket descriptor, cioè che ogni thread gestisce una connessione con un client. Se qualche thread fa riferimento a variabili globali, come nel 99% dei casi avviene, allora devi implementare un meccanismo di mutua esclusione per tali variabili.

Spero di esser stato chiaro.
Ciao

Nel tuo esempio si bisogna stare attenti, ma è appunto un esempio di server scritto non proprio bene. Ogni thread può tranquillamente mallocarsi il suo buffer di ricezione senza rompere le scatole agli altri con variabili globali. L'onere di gestire dei semafori è abbastanza grande mentre di RAM ormai ce n'è a bizzeffe

[marco.r]

Originariamente inviato da Eddie1985

Non è esattamente quello che ho fatto io?
Ma io continuo a non capire se le problematiche che cercavo di spiegare all'inizio del thread ci siano oppure no!
Dunque dopo che ho fatto le send dal lato client, i dati saranno o nelle variabili o comunque in un buffer, e prima o poi verranno presi dalla recv del lato server? Ma intanto il lato client, dopo aver eseguito le send, va avanti con il codice, e chi mi garantisce che le recv sul lato server siano già state effettuate????

Ok, ora ho capito meglio.
Tu non sai se e quando il server abbia fatto delle recv. Se la tua send ritorna con successo sai che in linea di massima i dati sono arrivati all'altro capo, ma potrebbero essere fermi in qualche buffer. Se vuoi avere qualche garanzia (tipo che il server ha finito di salvare i dati su disco) devi far si che il server risponda con qualche comando di conferma.
Di cosa vuoi aver conferma ?

[Eddie1985]

o immagino che tu stia in un sistema multithread, nel quale ogni thread gestisce un socket descriptor, cioè che ogni thread gestisce una connessione con un client. Se qualche thread fa riferimento a variabili globali, come nel 99% dei casi avviene, allora devi implementare un meccanismo di mutua esclusione per tali variabili.

mmm non mi pare di usare variabili globali nel mio caso...

Discorso lungo...
Ogni send (almeno in linea di principio) diventa un pacchetto del flusso TCP o, nel caso la quantità di dati sia troppo grande per un singolo pacchetto, viene frammentata in N pacchetti che poi il ricevitore ricompone. Per massimizzare l'efficienza dovresti fare pacchetti più grande possibile in modo da minimizzare il numero di pacchetti e, di conseguenza, l'overhead dovuto agli header TCP, IP, ecc che devi aggiungere ad ogni pacchetto. D'altro canto, se fai pacchetti grandi, se se ne perde uno e TCP deve ritrasmetterlo, ritrasmetterà una quantità di dati maggiore. Insomma, è un compromesso: per grosse quantità di dati, io farei pacchetti grossi (non meno di 512-1024 byte alla volta)

con grosse quantità di dati intedi roba dell'ordine di?

Ok, ora ho capito meglio.
Tu non sai se e quando il server abbia fatto delle recv. Se la tua send ritorna con successo sai che in linea di massima i dati sono arrivati all'altro capo, ma potrebbero essere fermi in qualche buffer. Se vuoi avere qualche garanzia (tipo che il server ha finito di salvare i dati su disco) devi far si che il server risponda con qualche comando di conferma.
Di cosa vuoi aver conferma ?

Beh se spedisco il file, vorrei avere la conferma che esso sia stato ricevuto. Se spedisco il nome del file, vorrei la conferma che esso sia stato ricevuto. E così via.
Ma a quanto mi hanno detto queste conferme non sono necessarie.
O sbaglio?

[marco.r]

Originariamente inviato da Eddie1985

Beh se spedisco il file, vorrei avere la conferma che esso sia stato ricevuto. Se spedisco il nome del file, vorrei la conferma che esso sia stato ricevuto. E così via.
Ma a quanto mi hanno detto queste conferme non sono necessarie.
O sbaglio?

Allora la conferma non serve per quel che riguarda la trasmissione in se'. Immagino pero' ti servira almeno una conferma che tutta la transazione e' andata a buon fine (e se finisce il disco? Se non puoi creare il file ? Se c'e' qualcosa che non va nei dati che hai spedito ?)

[Mettiu_]

Originariamente inviato da Eddie1985

con grosse quantità di dati intedi roba dell'ordine di?

Difficile dare un numero preciso, dipende dal contesto. Se ti interessano le prestazioni potresti voler ottimizzare anche l'invio di 1000 byte così come di 10 MB, non è che ci sia un numero preciso, sono scelte di progetto...
Per quanto riguarda le conferme NO, non sono necessarie nel senso che i dati arrivano sicuramente. Però, come giustamente facevano notare, il fatto che i dati arrivino non significa che tutto andrà bene: disco pieno, ram finita, ecc... Per risolvere questo problema ci vuole qualcosa di più complesso, tipo una connessione di controllo separata (come il protocollo FTP) per segnalare eventuali problemi da server a client e viceversa. Però in questo caso ti servono più thread... Non mi viene in mente niente di semplicissimo da implementare, pensaci su!