Des int dans un buffer binaire

**Colbix** · 27/03/2009, 09h12

Bonjour � tous,

Je dois envoyer envoyer dans un packet tcp/ip des donn�es sous un certain format. Le probl�me ne vient pas de tcp/ip, mais plus de la mani�re dont je doit remplire le packet.

En gros le contenu du packet doit comporter 5 int32 puis 2 int16 (tous �a en format binaire).

Je voulais savoir : d'apr�s vous comment je peut faire �a joliment ?
- G�rer un buffer en C et faire des shift de mes int ?
- ... ?

Merci d'avance

**ram-0000** · 27/03/2009, 09h46

Est ce que tu as le droit de les envoyer sous forme de texte s�par� par un caract�re sp�cial ("," par exemple) car ainsi, tu t'affranchis des diff�rences d'architecture poid fort/poid faible (et puis, c'e'st plus facile � d�bugger)

**3DArchi** · 27/03/2009, 09h50

Salut,
Souvent tu trouves des fonctions de type hton[s/l] (host->network) et l'inverse ntoh[s/l] (network->host). Sinon, je te conseille de le faire.

**Colbix** · 27/03/2009, 09h56

Envoy� par ram-0000

Est ce que tu as le droit de les envoyer sous forme de texte s�par� par un caract�re sp�cial ("," par exemple) car ainsi, tu t'affranchis des diff�rences d'architecture poid fort/poid faible (et puis, c'e'st plus facile � d�bugger)

Malheureusement, je dois me plier � l'architecture d�j� �tablie... Je ne peux donc pas changer quoi que ce soit et je dois respecter la norme �tablie...

J'aimerai faire un truc du style :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
			void* buffer = malloc(size);
			if(buffer == NULL)
				return false;
			// Init Header of packet
			buffer[0] = var1;
			buffer[4] = var2;
			buffer[8] = var3;
			buffer[12] = var4;
			buffer[16] = var5;
			// Init body
			buffer[20] = var6;
			buffer[22] = var7;

L�, le compilateur posera pbl �videmment.

Salut,
Souvent tu trouves des fonctions de type hton[s/l] (host->network) et l'inverse ntoh[s/l] (network->host). Sinon, je te conseille de le faire.

Je vais me renseigner

.

Merci pour vos r�ponses rapides

**Colbix** · 27/03/2009, 10h06

J'ai essay� avec un struct, mais j'ai encore un probl�me...

Pour ce qui est des int 32 et 16 c'est ok, mais je dois pouvoir rajouter du texte (des param�tre en fait). Ce texte est donc de taille variable. Pour mon struct �a pose donc un probl�me...

Une id�e pour r�soudre ce probl�me ?

**3DArchi** · 27/03/2009, 10h47

Construire un message compos� : format de type LV (longueur/valeur) ou TLV (type longueur valeur).
[EDIT]: pour du texte, faudra quand m�me choisir un encodage

**Trunks** · 27/03/2009, 10h47

Si tu connais la structure de ton paquet, tu peux une structure :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
struct packet
{
type_1 var1;
type_2 var2;
type_3 var3;
...
};

o� les types types pourrait �tre des flags, adresses r�seaux (source et destination), ...

Ensuite, tu envoies la struct sous la forme d'un buffer, en donn�es brutes

**3DArchi** · 27/03/2009, 10h49

Les structs peuvent g�n�rer des probl�mes d'alignement.

**Trunks** · 27/03/2009, 11h05

J'ai rien dit dans ce cas

**sopsag** · 27/03/2009, 13h20

Dans ce genre de cas, le mieux c'est d'�crire un serializer/deserializer.
Evidemment, c'est un peu long mais une fois que c'est fait, tu peux le r�utiliser � l'infini.

Un truc dans ce genre :

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
class Serializer
    {
    public:
        bool init ( void * outputbuffer , int outputsize ) ;
        bool add ( uint16 c ) ;
        bool add ( uint32 c ) ;
        bool add ( const char * string ) ;
    };
 
class Deserializer
    {
    public:
        bool init ( const void * inputbuffer , int inputsize ) ;
        bool get ( uint16 * c ) ;
        bool get ( uint32 * c ) ;
        bool get ( char  * string , int maxlength ) ;
    };

du coup, pour fabriquer ton paquet, �a donne �a :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
    my_serializer.add( var1 ) ; // var1 est un uint32 -> ok
    my_serializer.add( var2 ) ; // var2 est un uint32 -> ok
    my_serializer.add( var3 ) ; // var3 est un uint32 -> ok
    my_serializer.add( var4 ) ; // var4 est un uint32 -> ok
    my_serializer.add( var5 ) ; // var5 est un uint32 -> ok
    my_serializer.add( var6 ) ; // var6 est un uint16 -> ok
    my_serializer.add( var7 ) ; // var7 est un uint16 -> ok
    my_serializer.add("ho ! les beaux paramètres que voila") ; // char * -> ok

Tous les pb d'endianness sont g�r�s dedans (� toi de choisir comment).
Pour le add( const char * ), tu peux d�cider d'�crire d'abord la longueur sur un uint16 puis les chars � la suite ou de copier les chars et d'ajouter un 0 � la fin...

L'important �tant que le serializer et le deserializer soient d'accord aux 2 bouts de la liaison.

En tous cas, �a te permettera d'avoir un code � ne tester qu'une fois et bien isol� du reste. Et si les spec du format d'�change de donn�es change, tu n'auras qu'un code � modifier.
C'est la base de la programmation modulaire.

Hadrien

**Colbix** · 27/03/2009, 15h34

C'est une bonne id�e.

J'ai commenc� a faire un truc semblable, mais en utilisant des struct donc je modifie la taille de mani�re dynamique. C'est tr�s bourrin, j'avoue...

Je vais encore un peu y r�fl�chir...

Il y a le pbl big-endian -> little-endian aussi :s

Merci pour votre aide

[Edit] si je veux faire un Serializer. Ton int16 et int32, comment les d�clarer ?

**3DArchi** · 27/03/2009, 16h05

Juste quelques remarques sur la solution propos�e, histoire de partir du bon pied :
-> Probl�me de const,
-> Les param�tres peuvent �tre pass�es par r�f�rence (les pointeurs ne servent � rien sinon introduire du risque)
-> Utiliser std::string au lieu de pointeur sur char

Pour les conversions, des macros existent plus ou moins sous la m�me forme depuis des lustres avec les d�calages kifo.

uintXX_t si ton compilo impl�mente stdint.h. ; sinon Boost.Integer.

**sopsag** · 27/03/2009, 16h08

C'est ultra simple :
J'utilise la surchage des m�thodes.
Pour tous les types que tu veux pouvoir serialiser, tu ajoute un nouveau add dans le Serializer, et un nouveau get dans le Deserializer.
Bien s�r, il vaut mieux que ces types ne soient pas trop �volu�s pour que l'outil reste g�n�rique.

J'avais utilis� int16 et int32 pour fixer les id�es mais c'est ce que tu veux.
Pour faire encore plus g�n�rique, le mieux, c'est d'utiliser les types natifs du langage :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
class Serializer
    {
    public:
        bool add ( char a ) ;
        bool add ( unsigned char a ) ;
        bool add ( short b ) ;
        bool add ( unsigned short b ) ;
        bool add ( int b ) ;
        bool add ( unsigned int b ) ;
        bool add ( long b ) ;
        bool add ( unsigned long b ) ;
    };

Avec �a, tu g�res tous les types entiers.
Ensuite, dans l'implementation, on peut imaginer une fonction de priv�e de base qui g�re juste les octets.
En fonction de l'endianess, tu vas s�riliaser les autres types en parcourant leurs octets dans un sens ou dans l'autre.

Attention, il y 2 endianess � g�rer, celle des donn�es qui vont circuler (sur le r�seau ou sur un disque) et celle de la machine sur laquelle ton code va s'executer.

Hadrien

**3DArchi** · 27/03/2009, 16h13

Attention, rien ne te garantie que char=1 octet, short=2 ocets, int =4 octets et long = 4/8 octets.

**sopsag** · 27/03/2009, 17h04

C'est vrai, mais je ne vois pas ce �a change, du moment qu'il existe un add/get par type dont on a besoin.
Apr�s, il faut jouer avec sizeof pour ne pas se faire surprendre.

Mais juste comme �a, si un char ne fait plus un octet, comment manipuler des donn�es � l'octet pr�s (comme quand on retourne les 4 octets d'un long pour le convertir en big endian) ?

Est-ce que uint8_t deviendrait un type natif ?

Hadrien

**3DArchi** · 27/03/2009, 17h32

Envoy� par sopsag

C'est vrai, mais je ne vois pas ce �a change, du moment qu'il existe un add/get par type dont on a besoin.
Apr�s, il faut jouer avec sizeof pour ne pas se faire surprendre.

C'est dans la fa�on d'�crire get/add (d'ailleurs, j'aurais pr�f�r� operator<< et operator>>, ce qui est coh�rent avec le sens d'ajouter des donn�es au buffer ou d'en lire)

Envoy� par sopsag

Mais juste comme �a, si un char ne fait plus un octet, comment manipuler des donn�es � l'octet pr�s (comme quand on retourne les 4 octets d'un long pour le convertir en big endian) ?

En fait j'ai r�pondu un peu trop vite. La vrai relation est :
sizeof(char)=1
sizeof(char)<=sizeof(short)<=sizeof(int)<=sizeof(long)
et CHAR_BITS >= 8
sizeof(short)*CHAR_BITS >= 16, sizeof(long)*CHAR_BITS >= 32.
Donc, en fait, un char n'est pas forc�ment 8 bits. Et les autres en d�rivent.
Tu peux avoir des architectures o� int=short, ou int=long, voir m�me short=int=long. Avec le 64 bit, tu te retrouve � avoir des fois int=long et d'autre int=long long.
Rien de tr�s certain...
Pour quelque chose d'un peu r�utilisable : boost.Integer (voir Boost.Serialize) ou g�n�rique � base de template sur les tailles.

Enfin, il y a des plate-forme o� tu ne peux manipuler la m�moire � l'octet pr�s car tu ne peux d�r�f�rencer que des adresses align�es (sur 32 bits par expl).

Envoy� par sopsag

Est-ce que uint8_t deviendrait un type natif ?

D'apr�s ce que j'ai compris, �a doit �tre dans la norme C99, mais Visual ne l'impl�mente pas...