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.

[crunk]

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 ...

[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...

[crunk]

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

Code :

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

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

[crunk]

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.

[Médinoc]

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

[crunk]

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.

[mchk0123]

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() ?

[crunk]

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 ...

[Laurent Gomila]

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.

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.

[crunk]

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

[Laurent Gomila]

Code :

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

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...
        }
    }
}

[crunk]

Code :

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

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 :

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

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

normalement les parametres de send c'est

Code :

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

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...

[crunk]

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 ??

[Laurent Gomila]

C'est cette ligne qui me pose probleme :

Code :

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

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.

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 ?