sendto() et const void *buffer

Version imprimable

01/03/2007, 15h16
dest

sendto() et const void *buffer

Bonjour à tous.

Je suis en train de coder un petit programme qui utilise les connexions réseaux via le protocole UDP.
La fonction sendto() prend en argument un const void *buffer ainsi que la taille du buffer.

Je passe sans aucun problème des chaînes de caractères mais ça coince pour passer d'autres types.

Je n'ai par exemple pas réussi à passer de simples int. Il faut que je transtype à chaque fois. Mais le fait de passer des int, c'est juste pour tester, en fait, j'aimerais passer un tableau de structures mais je n'y parviens pas.

Merci de me donner un petit coup de main.

Dest.

D'un côté:

Code:

1
2
3
4
5
int i;
 
...
sendto(socketid,(char *) &i,sizeof i,0,(struct sockaddr *) &sockaddrin,
sizeof sockaddrin);

De l'autre:

Code:

1
2
3
4
5
int i;
 
...
recvfrom(socketid,(char *) &i,sizeof i,0,(struct sockaddr *) &sockaddrin,
sizeof sockaddrin);

01/03/2007, 16h02
dest

Ah bah oui effectivement.

J'avais fait ce que tu m'as dit sauf que dans le recvfrom, je ne mettais pas (char *) mais (int *) et j'avais sniffé le réseau pour voir ce qui passait et ce n'était pas bon. Sauf que là en sniffant, ce n'est toujours pas bon mais le client reçoit bien un entier.

Bref, c'est génial, merci.
01/03/2007, 16h04
stephl

Citation:

Envoyé par dest

Sauf que là en sniffant, ce n'est toujours pas bon mais le client reçoit bien un entier.

Comment cela "ce n'est toujours pas bon"?
01/03/2007, 16h52
dest

En sniffant, je ne voyais que le dernier chiffre de l'entier mais le client qui reçoit les infos reçoit bien ce qu'il faut.
01/03/2007, 16h54
stephl

C'est étrange; j'utilise ethereal pour capturer les paquets et je peux voir la valeur sans problème :? .
01/03/2007, 17h48
Emmanuel Delahaye

Citation:

Envoyé par dest

Bonjour à tous.

Je suis en train de coder un petit programme qui utilise les connexions réseaux via le protocole UDP.
La fonction sendto() prend en argument un const void *buffer ainsi que la taille du buffer.

Je passe sans aucun problème des chaînes de caractères mais ça coince pour passer d'autres types.

Je n'ai par exemple pas réussi à passer de simples int. Il faut que je transtype à chaque fois. Mais le fait de passer des int, c'est juste pour tester, en fait, j'aimerais passer un tableau de structures mais je n'y parviens pas.

Tu as oublié de poster le code avec lequel tu as un problème...

Attention. Si tu passes des valeurs binaires directement sr le réseau, il faut respecter des conventions de codage (endianness, largeur) qui permettent de faire des échange portables (indépendants de la machine).

Par exemple :
BYTE : un octet
WORD : 2 octets MSB en tête
LONG : 4 octets MSB en tête
etc.

Pour les flottants, c'est atroce : Il faut par exemple tout convertir en format normalisé IEEE 754 avec MSB en tête...

http://www.irisa.fr/caps/PROJECTS/Te...tion2_8_1.html
http://www.enseignement.polytechniqu...in1/node7.html

Bref, un transcodage en texte évite bien des soucis...
01/03/2007, 20h24
dest

J'utilise également ethereal (wireshark) et je ne comprends pas non plus pourquoi je ne vois pas passer mon entier.

Cependant, j'ai correctement réussi à passer mon tableau de structures, ce qui est positif.

Mais j'ai une question technique à vous poser. Oublions l'UDP, je suis en train de tout changer et passer en TCP. Mon tableau de structures est alloué dynamiquement, de ce fait, le client ne sait pas à l'avance la quantité d'octets qu'il va recevoir.

Quelle solution serait la meilleure ?
- Envoyer un message spécifiant la taille du tableau qui suivra dans un second envoi.
- Allouer en dur une taille de tableau qui selon moi ne sera jamais atteinte. Maximum 30 cases.
- Autre.

Si vous avez une autre idée, je suis preneur.

Merci
01/03/2007, 21h54
Emmanuel Delahaye

Citation:

Envoyé par dest

Mais j'ai une question technique à vous poser. Oublions l'UDP, je suis en train de tout changer et passer en TCP. Mon tableau de structures est alloué dynamiquement, de ce fait, le client ne sait pas à l'avance la quantité d'octets qu'il va recevoir.

http://emmanuel-delahaye.developpez....eaux.htm#texte
01/03/2007, 22h22
dest

Merci de ton lien.

De ce que j'ai pu y voir, ils mettent une valeur max et les données reçues seront inférieurs ou égales à ce max. Il ne faut vraiment pas se planter.
01/03/2007, 22h25
Emmanuel Delahaye

Citation:

Envoyé par dest

Merci de ton lien.

De ce que j'ai pu y voir, ils mettent une valeur max et les données reçues seront inférieurs ou égales à ce max. Il ne faut vraiment pas se planter.

'ils', c'est moi, au cas où te devrais te plaindre !

C'est pas grave. La réception prend ce qu'elle peut, c'est tout. Tant que recv() retourne >0, c'est qu'il y a des octets qui arrivent...

Tu n'as pas compris que c'était bouclé ?
01/03/2007, 22h39
dest

Excuse moi, je ne savais pas que c'était ta page et je n'ai pas de critique à en faire donc, je ne me plains pas.

J'ai bien compris que c'était bouclé, il démarre du premier indice et va jusqu'à strlen dans le cas de l'envoi et de chaînes.

Ma question se situe plus au niveau de la réception. Je veux bien mettre un indice max et en réception, il prendra tout ce qu'il peut, ok.
Tout ceci est finalement dans le but d'économiser la mémoire. C'est pour cela que je demandais plus tôt s'il ne valait mieux pas d'abord transmettre la taille du tableau, faire une allocation dynamique de la taille exacte de ce qui avait été émis puis transmettre le fameux tableau .

Je me pose encore quelques questions:
Que se passe t-il si la quantité de données reçues dépassé la taille du buffer ?
Y a t-il un équivalent à strlen pour savoir le nombre de cases d'un tableau ? Est-il raisonnable de diviser la taille des données reçues par la taille d'une case du tableau pour connaître ce nombre de cases?

Je m'excuse si les questions vous paraissent évidentes mais cela m'intéresse grandement.
01/03/2007, 22h55
Emmanuel Delahaye

Citation:

Envoyé par dest

Ma question se situe plus au niveau de la réception. Je veux bien mettre un indice max et en réception, il prendra tout ce qu'il peut, ok.
Tout ceci est finalement dans le but d'économiser la mémoire. C'est pour cela que je demandais plus tôt s'il ne valait mieux pas d'abord transmettre la taille du tableau, faire une allocation dynamique de la taille exacte de ce qui avait été émis puis transmettre le fameux tableau .

Il peut y avoir différentes stratégies de réception.
écriture dans un fichier, tableau souple, liste chainées etc.

Citation:

Je me pose encore quelques questions:
Que se passe t-il si la quantité de données reçues dépassé la taille du buffer ?
Y a t-il un équivalent à strlen pour savoir le nombre de cases d'un tableau ?

Non, à moins qu'un mécanisme analogue à celui d'une chaine (sentinelle) ait été implémenté. Dans ce cas, il faut écrire la fonction de mesure de longueur qui va bien. et ne pas confondre "nombre d'éléments" et "taille du tableau"... évidemment...

Citation:

Est-il raisonnable de diviser la taille des données reçues par la taille d'une case du tableau pour connaître ce nombre de cases?

Euh, non, car on ne sait pas si on a fini de recevoir...

Passer la taille, pourquoi pas... Pour le contrôle, ou pour déterminer la fin de transfert... A toi de définir ton protocole (ou prendre un protocole existant comme FTP, pas léger léger...)

De toutes façon, une trame a une taille limitée, alors tu auras beau passer "500k", la taille d'une trame ne pourra pas dépasser une certaine valeur qui dépend de la configuration du système... (qq 10aine de ko)
01/03/2007, 23h09
dest

C'est dommage, en java, il y a des fonctions très pratique pour retourner la taille d'un tableau.

Je vais faire comme j'ai dit, à savoir, transmettre le nombre d'éléments du tableau puis transmettre le tableau puisqu'en plus, tu ne le contre-indiques pas.

Merci