Discussion :

[crunk]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[ZaaN]

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.

[koala01]

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

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

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
std::string chaine=read();
(traitement

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Laurent Gomila]

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.

[Médinoc]

read() (pourquoi pas recv ?)

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

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.

[nicroman]

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.