Comments on: Come programmare le socket in ambienti GNU/Linux (Parte 1)

By: Come programmare le socket in ambienti GNU/Linux (Parte 2) – OScene.net - Italiano

Wed, 20 Oct 2010 10:41:29 +0000

[...] Come programmare le socket in ambienti GNU/Linux (Parte 2) Ti interesserà anche…Come programmare le socket in ambienti GNU/Linux (Parte 1) Nel primo articolo abbiamo analizzato il funzionamento delle socket e di un server con rispettivo client. In questo vedremo un modo di programmare un tipico server concorrente utilizzando la funzione fork(). [...]

By: Saverio

Saverio — Sun, 29 Aug 2010 16:11:21 +0000

C’e’ un modo per rifiutare tout court le connessioni se ce n’e’ già una attiva?
Pur mettendo 1 come valore di queue della listen, comunque le connessioni sono accettate (temo che 5 sia il valore minimo nel mio ambiente). Il problema e’ che cio’ che il client manda, viene cachato, e mi arriva tutto assieme quando il client corrente si disconnette!!

Io ho bisogno di limitare ad una sola connessione (il server accetta comandi per un Servo), magari dando “Busy, try later” alle successive e chiudendo il soket.

By: Alessandro Iezzi

Alessandro Iezzi — Sun, 08 Aug 2010 13:23:54 +0000

@Antonio e @marco:
Si in effetti avrebbe più senso ciclare l’invio.

@marco:
Sono felice che il commento ti sia stato utile, avevo paura di non essermi spiegato bene. Come accade spesso, molte cose purtroppo vengono tralasciate, ad esempio come quella del casting, non per dimenticanza ma proprio perché sarebbero un surplus.

By: Antonio Barba

Antonio Barba — Sun, 08 Aug 2010 10:49:52 +0000

@marco:
Bene!
Il problema comunque non è soltanto quello di computer con poca Ram, anche perchè grazie all’address space virtuale puoi avere sempre 2GB di Ram “virtuale” anche con un PC a 32bit con 128MB di Ram fisica.
Il problema è che i moderni filesystem supportano file con dimensioni a 64bit, è quindi possibile (ed ormai anche comune) avere un file maggiore di 2GB (basti pensare all’immagine ISO di un qualsiasi DVD), e quindi sarebbe fisicamente impossibile caricarlo in Ram su un sistema a 32 bit.
Ricordo che, sebbene 32 bit rappresentino lo spazio di 4 GB, metà di questo address space è riservato al kernel nella zona alta della memory map, quindi i programmi utente ne vedono solo 2 GB. Questo vale sia su Windows che Linux per x86. Il problema non si pone sulle versioni AMD64 (o meglio, il problema viene semplicemente rimandato più in là nel tempo).

By: marco

marco — Sun, 08 Aug 2010 10:39:29 +0000

@Antonio Barba:
mi hai anticipato di qualche secondo
Per lo meno hai confermato la mia proposta. Ciao!

By: marco

marco — Sun, 08 Aug 2010 10:38:07 +0000

@Alessandro lezzi:
grazie per la delucidazione in merito al casting
Per quanto riguarda la domanda di Pietro, invece di utilizzare un unico buffer di dimensione pari al file da spedire non si potrebbe usarne uno di dimensione definita a priori e ciclare l’invio dei dati “un pezzo per volta”? Così facendo si evita di sovraccaricare la memoria e si permette anche a computer con poca RAM di inviare file molto grandi.

By: Antonio Barba

Antonio Barba — Sun, 08 Aug 2010 10:32:39 +0000

@Alessandro e @Pietro:
per file piccoli (al di sotto del MB) si può optare per ingrandire il buffer, ad ogni modo la sizeof() non restituisce la dimensione del file (operazione fattibile soltanto a runtime), perchè è un operatore del linguaggio che viene risolto a compile time (non è una funzione).
Per sapere la dimensione di un file in bytes bisogna usare la funzione stat(), che restituisce tra le altre cose anche questa informazione.

Per file di dimensione arbitrariamente grande, la soluzione consiste nel leggere il file a “chunk” di grandezza fissata (ad esempio 1K alla volta), attraverso la funzione fread(), e inviare via socket questi chunk.
Sia la trasmissione che la ricezione dovranno avvenire dentro un ciclo while, usando una variabile che conteggia i byte trasmessi/ricevuti, e ad ogni ciclo si dovrà effettuare una nuova fread/fwrite per leggere/scrivere quel chunk sul file.
E’ un’operazione che comunque comporta tutta una serie di problemi dovuti alla scarsa affidabilità del mezzo di trasmissione, pertanto è meglio affidarsi a protocolli già sperimentati come FTP, che consentono anche il reinvio di chunk perduti, e il riordino degli stessi in caso di arrivo “in ordine sparso”, evento che si verifica frequentemente su grandi reti come internet.

By: Alessandro Iezzi

Alessandro Iezzi — Sun, 08 Aug 2010 02:23:57 +0000

@Pietro:
Tenendo conto che non ho mai provato ad inviare file tramite delle socket, posso solo dire che se vuoi inviare dati più grandi devi obbligatoriamente modificare il buffer.
Una soluzione sarebbe quella di andare a creare un buffer dinamico che venga dimensionato in base al file da inviare. Per fare questo ci sono due modi:
1° Usando il C89 con la funzione “malloc”;
2° Usando il C99 con le VLA.
Penso anche che tramite l’uso di sizeof ti potresti ricavare la dimensione in byte del file e di conseguenza adattare il buffer. La tipologia del socket dovrebbe essere invariata, ovvero usare SOCK_STREAM.
Magari se ho tempo qualche piccolo esperimento lo faccio questi giorni e se ne esce qualcosa di buono non esito a scrivere un articolo.

@marco:
Scusa se rispondo solo ora, ma l’università ha preso il sopravvento sul mio tempo libero.
Mi dispiace doverti rispondere per commento, se non ti è chiaro qualcosa non esitare ad inviarmi una email.

La struttura hostent ha le seguenti variabili:

struct hostent
{
char *h_name; // Official name of host.
char **h_aliases; // Alias list.
int h_addrtype; // Host address type.
int h_length; // Length of address.
char **h_addr_list; // List of addresses from name server.
#define h_addr h_addr_list[0] // Address, for backward compatibility.
};

Come puoi ben notare, h_addr è il primo indirizzo del vettore di “stringhe” (intese come array di caratteri), ogni array è formato da 4 elementi, quindi 4 byte.
L’indirizzo perciò viene memorizzato in questo modo:

127.0.0.1 —> h_addr[0] = 127, h_addr[1] = 0, h_addr[2] = 0, h_addr[3] = 1.

Il casting, non fa altro che prendere questo piccolo vettore e trasformarlo in un intero formato da 4 byte. Esso è contenuto nella struttura in_addr:

struct in_addr {
uint32_t s_addr; // that’s a 32-bit int (4 bytes)
};

Viene quasi spontaneo ora eseguire:

server_addr.sin_addr.s_addr = ((struct in_addr*)(hp->h_addr)) -> s_addr;

Dovrebbe funzionare anche così:

server_addr.sin_addr = (struct in_addr*)(hp->h_addr);

Spero sia esaustiva come risposta e grazie per il commento.

By: Pietro

Pietro — Sat, 07 Aug 2010 19:37:38 +0000

Ciao, come cambia il codice in caso di invio di un file (per esempio un pdf) di dimensione molto più grande del buffer?

By: marco

marco — Thu, 06 May 2010 13:02:28 +0000

@Antonio Barba: Buono a sapersi
Grazie ancora!