connaitre la bonne taille de buffer à utiliser pour la lecture de socket

Re-Bonjourcher developpeurs (oui c'est le deuxieme fois que je poste dans la journée), j'utilise les sockets dans un petit programme que j'écrit en ce moment
et je suis confronté à un probleme assez problématique lors de la lecture d'une socket avec la fonction read().
J'aimerai pouvoir connaitre la taille exacte du buffer a utiliser pour pouvoir lire
la socket sans gaspiller d'espace n memoire en allouant un buffer bocoup trop grand; car actuellement la solution que j'utilise est de creer un buffer de 65000 octets, maid ca me parai vraiment pas terrible comme solution.
J'avais penser a faire un

Code:

---

1 2	char buffer [read(....)];

---

mais ca me parai encore plus stupide que ma premiere solution .

La je suis vraiment a cour d'imagination alors merci d'avance pour vos suggestions.

Si tu es certain de ce que tu va pouvoir lire sur ta chaussette ( soket quoi ;-) ) et là tu peux reserver juste la place desirée, mais c est pas terrible.

Si tes communications sont prefixé d un header, tu pourrais juste reservé la place pour cet header puis lire la taille des données à venir et reserver la suite à la volée...

Mais reserver 2^16 byte est une solution acceptable => tu reserves (et libère) qu'une seule fois ces bytes et en plus si tu travaille dans une architecture actuelle tu n auras aucun problem de ressource materielle.

Salut,

Autant le dire tout de suite, les sokets et moi, ca fait meme plutot trois que deux... donc je peux etre tout à fait à coté de la plaque :P

Mais, l'énorme avantage d'une std::string, c'est qu'elle peut recevoir un char* en initialisation/définition...

Ne pourrait-on donc pas envisager de placer le message recu/à envoyer dans une string et d'utiliser la methode c_str() pour l'émission sur le soket :question:

Donc, si read() fournit un char*, on aurait un code pouvant ressembler à

Code:

---

1 2 3

std::string chaine=read(); (traitement

---

et, s'il faut envoyer un char* dans send, on travaillerait sous la forme de

Code:

---

1 2 3 4

std::string chaine; (création de la chaine) send(chaine.c_str());

---

De cette manière, le buffer serait toujours exactement adapté à la taille du message envoyé sur /recu par le soket ;)

Citation:

---

Autant le dire tout de suite, les sokets et moi, ca fait meme plutot trois que deux... donc je peux etre tout à fait à coté de la plaque

---

Un petit peu ;)

read() (pourquoi pas recv ?) ne renvoie pas une chaîne de caractères style C, mais juste une séquence d'octets dont la taille est spécifiée en retour de la fonction. Il faut donc allouer la place nécessaire avant de connaître le nombre d'octets à lire. D'autant plus que les données peuvent être fragmentées et reçues en plusieurs fois, si leur taille est trop importante.

Citation:

---

Envoyé par Laurent Gomila

read() (pourquoi pas recv ?)

---

Parce que le P.O n'a jamais dit qu'il voulait être portable sous Windows... :aie:

N'importe comment, on ne peut savoir à l'avance combien il faut lire, sauf si la taille est envoyée avant les données, ou s'il y a une taille maximale connue.
Mais pour les sockets orientés connexion, ce n'est pas un problème, puisque les données non-lues restent disponibles pour la prochaîne lecture.

Pour un socket de type stream, la taille du buffer de lecture n'est vraiment pas importante.
Le pile réseau est configurée par le système pour une utilisation de fenêtre de lecture fixe dans tous les cas. Qu'on lise 2 par 2 ou 10000 par 10000, peu importe. Dans tous les cas, on récupère la quantité de données vraiment lues.

Par contre, à l'emission, alors oui, ca fait une ENORME différence. Prenons l'exemple d'un envoi de 5000 octets.

Si les 5000 octets sont envoyés 2 par 2, ca fera 30 octets (28 d'en-tête si mes souvenirs sont bons) envoyés 2500 fois, soit.... 75000 octets en tout !

L'idéal est de découvrir pour cette connexion, la "MTU" à utiliser (la taille maximale de donnée sans morcellement), et utiliser cette taille comme buffer.
Le plus simple est de tout envoyer en une fois, et laisser la pile faire son boulot de morcellement.

Bon ba deja merci pour toutes ces reponses, je pense qu'avec les sockets je vais pouvoir m'en sortir; mais le meme probleme ce pose aec les pipes et la , vu que la lecture est destructrice, et que je ne peut pas utiliser d'entete car le programme au bout du tube n'est pas ecrit par mes soins .... la je seche un peu ...

Il me semble que pour les tubes non plus, la lecture ne détruit pas les données non-lues.

C'est pour les files de messages que les données non-lues sont définitivement perdues...

Une idée m'est survenue cher developpeurs, que penser vous de ce coee :

Code:

---

1 2 3 4 5 6 7 8 9 10

char temp[1]; string buffer;   while (il y a qq chose alire) { lire un octet et mettre cet octet dans temp; copier temp dans buffer; vider temp; }

---

Je pense que c'est possible grace a select() que j'utilise deja de toute facon dans mon programme pour savoir quand lire la socket

Citation:

---

Envoyé par Médinoc

Il me semble que pour les tubes non plus, la lecture ne détruit pas les données non-lues.

C'est pour les files de messages que les données non-lues sont définitivement perdues...

---

Sisi j'ai bien regardé et la lecture est destructrice pour les tubes, ce qui est assez emmerdant.

Cela me parait de plus en plus bizarre, car il me semble qu'on est censé pouvoir lire octet par octet dans un tube...

Non en fait tu as tout a fait reson, on peut lire octet par octet, en fait j'avais mal compris le sens de lecture destructrice; la lecture est destructrice sa veut juste dire que si un processus lit dans u tube, les données disparaisent une fois lues, et si un autre processus tente de lire, il ne trouvera aucunes données.

Bon ba je sus un peu plus avancé je crois, merci a tous d'avoir pris le temps de m'aider.

Citation:

---

Envoyé par nicroman

Le pile réseau est configurée par le système pour une utilisation de fenêtre de lecture fixe dans tous les cas. Qu'on lise 2 par 2 ou 10000 par 10000, peu importe. Dans tous les cas, on récupère la quantité de données vraiment lues.

---

Juste une question supplémentaire ...
Est-ce que cela veut dire que à partir du moment où des données sont disponibles à la lecture, la pile réseau à reçue l'intégralité du message envoyé sur la socket stream ?
Autrement dit, si je boucle sur un recv(), l'obtiendrais tout le message sans avoir à attendre de nouveau ?
C'est à dire est-ce que la pile réseau attend de recomposer l'intégralité du message avant de notifier que des données sont disponibles pour un recv() ?

Heu je sais que c'est pas vraiment en rapport avec le sujet du post, mais bon j'ai pas envie de faire un nouveau post.
Je voudrais comprendre comment on fait pour envoyer de gros paquets d'octets avec une socket stream, car j'ai lu que si les données a envoyer étaient trop grosses send() n'envoyait pas l'integralité, et la je ne vois pas trop comment faire pour s'en sortir ...

Citation:

---

Est-ce que cela veut dire que à partir du moment où des données sont disponibles à la lecture, la pile réseau à reçue l'intégralité du message envoyé sur la socket stream ?
Autrement dit, si je boucle sur un recv(), l'obtiendrais tout le message sans avoir à attendre de nouveau ?

---

De toute façon recv est bloquant, donc même si tout n'a pas été envoyé tu finiras bien par le recevoir.

Citation:

---

Je voudrais comprendre comment on fait pour envoyer de gros paquets d'octets avec une socket stream, car j'ai lu que si les données a envoyer étaient trop grosses send() n'envoyait pas l'integralité, et la je ne vois pas trop comment faire pour s'en sortir ...

---

send renvoie le nombre d'octets envoyés, il suffit donc de boucler jusqu'à ce que la totalité du paquet est été traitée.

Rien a faire je vois toujours pas comment faire, tu peut donner un petit exemple de code stp pour eclairer ma lanterne ??

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

void Send(const char* Data, std::size_t SizeInBytes) { std::size_t Sent = 0; while (Sent < SizeInBytes) { int Res = send(Data + Sent, SizeInBytes - Sent, ...);   if (Res > 0) { Sent += Res; } else { // Error... } } }

---

Citation:

---

Envoyé par Laurent Gomila

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

void Send(const char* Data, std::size_t SizeInBytes) { std::size_t Sent = 0; while (Sent < SizeInBytes) { int Res = send(Data + Sent, SizeInBytes - Sent, ...);   if (Res > 0) { Sent += Res; } else { // Error... } } }

---

---

Ya rien a faire je comprend pas comen tu fais pour envoyer la partie qui n'a pas ncore été envoyée a chaque iteration du while
C'est cette ligne qui me pose probleme :

Code:

---

1 2	int Res = send(Data + Sent, SizeInBytes - Sent, ...);

---

normalement les parametres de send c'est

Code:

---

1 2	ssize_t send (int fd,void *buffer,size_t len,int flags)

---

et je vois pas comen a la place de bufer te peut mettre les données qui n'ont pas été envoyées a l'iteration d'avant...

Sinon ya une autre (encore) petite question qui me vient a l'esprit,
si j'au une string (de la stl) comment pourrai-je faire pour la reduire d'un certain nombre de bytes/bits , en l'occurence le nombre renvoyer par send ??

Citation:

---

C'est cette ligne qui me pose probleme :

Code:

---

int Res = send(Data + Sent, SizeInBytes - Sent, ...);

---

---

A chaque itération, j'incrémente le pointeur sur les données à envoyer du nombre d'octets qui a été envoyé depuis le début. De la même manière, je réduis le nombre d'octets restant à envoyer.

Citation:

---

si j'au une string (de la stl) comment pourrai-je faire pour la reduire d'un certain nombre de bytes/bits , en l'occurence le nombre renvoyer par send ??

---

Pourquoi tu veux faire ça ?

En fait ce qui me pose un probleme c'est que data et sent sont de types differents et que tu les additionne ...
Sinon pour la question sur les string , laisse tomber, encore une inpeptie sortie
de mon petit cerveau fatigué ...

Citation:

---

En fait ce qui me pose un probleme c'est que data et sent sont de types differents et que tu les additionne ...

---

Data est un pointeur sur char : lui additionner un entier fera se déplacer le pointeur d'autant d'octets (c'est l'arithmétique des pointeurs).

Ah mes non d'accord en fait je suis c** aujourd'hui !!
Data c'est un pointeur qui pointe vers le premier element du tableau
char data[] non ??
A ce moment la on peut alors lui ajouter sent pour que sa pointe vers le debut
données pas encore envoyées ...
Enfin je suis peut etre entrin de m'enfoncer encore plus la ..... Sacré sockets ...

Ok ok bon ba j'ai enfin compris , un grand merci pour ton aide et surtout pour ta patiente, pasqu'avec moi il en vaut une bonne dose ...

des tubes avec des sockets... quel cauchemard!

Code:

---

1 2	int Res = send(Data + Sent, SizeInBytes - Sent, ...);

---

send prend en paramètre un descripteur, donc la socket correspondante. c'est quoi ce data+sent?

ps: quelle différence pour un réseau tcp mode connecté entre [read & write] et [recv & send]?

j'ai toujours utilisé pour du tcp write et read. et pour l'udp recvfrom et sendto.

et au fait qu'est ce que fait une discussion sur des sockets dans la partie c++ (meme si c'est codé en c++/c)? ya une partie developpement réseau!

Citation:

---

send prend en paramètre un descripteur, donc la socket correspondante. c'est quoi ce data+sent?

---

Peu importe l'ordre ou la place des paramètres (je n'en suis pas encore à les connaître par coeur), ici on parle juste du pointeur vers les données et leur taille. J'aurais dû placer des "..." de chaque côté pour éviter que les pinailleurs ne me tombent dessus... ;)

Citation:

---

ps: quelle différence pour un réseau tcp mode connecté entre [read & write] et [recv & send]?

---

S'assurer qu'on ne sera jamais tenté de porter le code vers les sockets Windows, peut-être ?
A part ça il n'y a sans doute aucune différence, tout étant géré sous forme de descripteur de fichier sous Unix.

Citation:

---

et au fait qu'est ce que fait une discussion sur des sockets dans la partie c++ (meme si c'est codé en c++/c)? ya une partie developpement réseau!

---

C'est vrai que c'est limite, mais bon comme on intercale quelques questions de C++, et que ça ne gêne pas de laisser quelques questions de réseau ici, il est préférable de laisser le sujet ici.

et c'est laquelle qui permet la portabilité vers les sockets windows?
et désolé de pinailler mais j'ai pas compris, donc j'ai demandé précision ^^ ;)
merci de ta rép, mais faut penser que des gens postent dans la partie développement réseau qui est bien moins visitée que celle de c++. (j'en suis la preuve)

votre pinailleur en chef :p

C'est send()+recv() qui marche sur tous les sockets, quelle que soit leur nature sous-jacente.

read()/write() ne marche que sur des descripteurs, donc ne marche avec les sockets que là où les sockets sont des descripteurs (à savoir: Tout système unixoïde/POSIX, mais sûrement pas Win32).

N'y a t-til pas un avantage de read/write par rapport a send/recv?
a part le nombre d'arguments qui sont moins nombreux dasn read/write!
j'utilise read write en principe mais bon...

Citation:

---

N'y a t-til pas un avantage de read/write par rapport a send/recv?

---

Le résultat sera le même, quel genre d'avantage voudrais-tu avoir ?

Citation:

---

a part le nombre d'arguments qui sont moins nombreux dasn read/write!

---

Bah... Il faut juste rajouter un flag (qu'on met toujours à 0) :roll:

Non, en fait je fais des projets sur des sockets en tcp, et j'utilise read/write.
et je me demandais comment je pourrais justifier l'utilisation de read/write par rapport a rcv/send.

c'est tout!

read et rcv sont tous deux bloquantes?

Citation:

---

read et rcv sont tous deux bloquantes?

---

Oui, il me semble que c'est sur le socket (ou plus généralement sur le descripteur de fichier) qu'il faut paramétrer la notion de blocage / non-blocage. Comme ça peut se faire pour l'entrée standard par exemple, puisque c'est aussi un fichier (toujours sous Unix évidemment).

lun4t1k :

1. Inutile de chercher, tu ne peux. :D
2. Oui. Comme dit par Laurent, ça se paramètre sur le socket (ou le descripteur de fichier sous nux).
   La fonction doit être ioctl() sous nux, ioctlsocket() sous Windows.

merci a vous!
autre question: un client envoie 5000 caracteres (ou octets).
le buffer coté server est suffisament grand pour tout accueillir.
cependant je ne recois pas tout d'un coup.
apres chaque read j'affiche le nb d'octets recus, et de tps en tps l'envoi ne se fait pas qu'en une fois. (en tcp mode connecté toujours)

Code:

---

1 2 3

1 octets recus. 2563 octets recus

---

le nb de carctères envoyés par le client est aléatoire et s'échelonne de 1000 a 10000. (souvent aux alentours des 3000)

d'ou ca pourrait venir? sachant que le client n'envoi qu'une fois et que le serveur ne recoit qu'une fois!
pourquoi read se bloque?

ps: c'est la derneire question! ^^

Les sockets en mode connecté on toute lattitude pour découper leurs packets quand bon leur semble, cela fait partie du standard.
La seule chose dont tu peux être sur, c'est l'absence de perte de packets, ainsi que l'ordre d'arrivé qui est toujours respecté.

D'ou cela vient ? Surement des différents buffeurs dans la chaîne réseau (os, cartes, routeurs, ...) qui choisisent la meilleure taille de packet pour être le plus rapide possible.

D'ailleurs la taille des frames est paramétrable sur les cartes réseau, cependant il n'existe pas à ma connaissance de formule exacte pour connaître la taille de "3000" que tu indiques.

Pourquoi read se bloque ? Laurent t'as donné la réponse => fonction ioctlsocket ...

Par contre je suis désolé je vais en contredire certains, mais j'ai bien peur que ce soit faux que d'affirmer que recv est portable sur windows.

Source: Prof de réseau! :roll:

recv n'est pas plus portable que les autres fonctions ; simplement dans 90% des cas ce sont juste des différences de types (int / unsigned int, SOCKET / int, ...) et qui compilent tout de même sur les deux OS sans modification.

Je confirme que la fonction recv existe bel et bien sur Win32.
En fait ce n'est autre qu'un alias d'une des fonctions "natives" de Windows sur les sockets. Mais les 2 fonctionnent bien.

En règle générale Windows fournit toujours de quoi être compatible avec les sockets Berkeley, il reste juste quelques lourdeurs dûes à certaines différences entre Windows et les Unix. Quoiqu'il en soit faire une interface portable par dessus tout ça n'a rien de bien compliqué.

En gros il n'y a pas lieu de dire que rcv & send sont portables vers win! (vocabulairement)

La seule différence que je vois entre read et rcv c'est l'absence du flag sur read.
(flag que je laisse souvent à 0 pour mes utilisations...)

Ok merci à vous.
Bonne soirée à tous!