Discussion :

[MeWaa]

Bonjour,

Alors voila j'ai des petits soucis lors d'une communication UDP. Mon problème est que les données reçus sont altérées.
Je désire transmettre un Header perso suivit d'adresse sur 4 octets.
Je développe l'envoie sur Cygwin et la réception se fait par une IHM crée en Qt (C++)
Voici un bout de mon code

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
18
19
20
21
22
23
24
25
26
27
28
 
for(i=0; i < 32; i+=nb_prof+2)
		{
			//Header 
			buf[i] = 0x02 << 24;
			buf[i] += nb_prof*4+8 << 16;
			buf[i] += j << 0;
 
			//PC 
			buf[i+1] = random();
 
 
			//Empilement des appels 
		for (k = 1; k <= nb_prof; k++)// empilement du Pc et des appels 
            {
				buf[i+k+1] = random()/1000;
			}
			j++;
		}
 
 
		for(i=0; i<=32; i++)
		{
			printf("buf[%d] = %X \n",i,buf[i]);
		}
 
 
		udpsend(buf, 512, sock);

Trames envoyées

Code :

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

1
2
3
4
 
buf[0] = 20C0003
buf[1] = 7A94D1CA
buf[2] = 1490D9

Trames reçues:

Code :

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

1
2
3
4
 
03000c02
cad1947a
d9901400

On dirait un problème d'endian mais étant donné que je développe sur la même machine cela me parait bizarre

Merci d'avance

[rilou]

Même si tu travail sur la même machine (enfin si tu envois et reçois sur la même) rien ne te dit que la trame envoyée en UDP n'est pas envoyée avec les octets inversés, ou reçue avec les octets inversés.

[MeWaa]

Donc il n y a aucun moyen pour qu'il n y ai pas d'inversion dans les octets?

[Emmanuel Delahaye]

Même si tu travail sur la même machine (enfin si tu envois et reçois sur la même) rien ne te dit que la trame envoyée en UDP n'est pas envoyée avec les octets inversés, ou reçue avec les octets inversés.

Euh, non. UDP n'inverse jamais l'ordre des octets. Ce qui n'est pas garanti, c'est l'odre de reception des trames.


sento("Hello");
sento(" wild");
sento(" world\n");

peut être reçu

"Hello wild world\n"
" wild Hello world\n"
" wild world\nHello"
etc.

mais jamais "Hlleo" ni "odlrw" ni même "dliw "

Donc il n y a aucun moyen pour qu'il n y ai pas d'inversion dans les octets?

Si inversion il y a, c'est au moment de l'encodage ou du décodage des données. Montre le code de réception.

déjà, l'encodage nest pas clair. ce qui doit être émis est un tableau de unsigned char La covention 'réseau' impose le format MSB en tête.

Ce que tu fait n'a rien à voir. On dirait que le tableau (buf) est de type int, ce qui n'est évidemment pas portable.

Il faut commencer par définir clairement l'aspect (les champs) de la trame à transmettre, et ensuite écrire le code qui la génère correctement (et indépendamment de la machine).

[MeWaa]

J ai resolu mon probleme
L'erreur n'etait pas du a l'UDP mais a mon enregistrement dans le buffer (unsigned long). Le printf n'affichait la position concrete des octets dans la trame.
Pour remedier a ce probleme j'ai utiliser la methode suivant :

Code :

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

1
2
3
4
5
 
                        temp  = 0x02 << 24;
			temp |= (0xFF & nb_prof*4+8) << 16;
			temp |= (0xFFFF & j) << 0;
			buf[i] = htonl(temp);

La fonction htonl() permet de mettre en ordre les octets pour le réseau.
http://man.developpez.com/man3/htonl.3.php
Pour le reste de la trame ça (enregistrement PC et appelant) n'a pas spécialement d'importance car j'effectue un test en reception pour savoir si je suis en Big ou Little Endian grace au Header. Donc la disposition des octets est alors pris en compte.

Quand a l'affichage je l'ai décomposé par octet en utilisant un pointeur de char :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
			unsigned char * p;
 
			printf("envoie de la trame \n");
			for(p = (unsigned char*)buf, i=0; i<=32; i++)
			{
				printf("buf[%d] = %02x%02x%02x%02x\n",i,
					p[(i*4) + 0],
					p[(i*4) + 1],
					p[(i*4) + 2],
					p[(i*4) + 3]);
			}

Merci pour l'aide.