Discussion :

[Frank1010]

Bonjour,

Le projet que je dois réaliser un est projet réseaux, en particulier l'implémentation d'un protocole. Ce protocole spécifie plusieurs formats de paquets appelés "TLV".

Mon problème est de trouver une façon d'implémenter ces TLV de façon idiomatique en C++.

Tous les TLV ont un champ "type".

Puis tous les TLV sauf un ont un champ "length".

Ensuite ça diverge. Cependant on peut noter qu'il existe deux TLV avec les mêmes champs mais dont seulement le type est différent.

Ma première idée était d'utiliser l'héritage en utilisant un enum pour différencier les TLV.

En particulier j'aurais eu en classe mère un TLV du type :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
class Tlv{
	enum TlvType {
           ... //Differents types de TLV
 
	};
protected:
	TlvType type_;
public:
	TlvType type();
	Tlv();	
};

Puis j'aurais fait une classe fille avec un champ length. Puis pour chaque TLV différent une classe "petite fille". Cependant mon problème est que parfois je vais avoir deux TLV qui diffèrent par leur Type mais qui pourtant auront la même classe. Je trouve ça bizarre d'un point de vue utilisateur.

Je me trompe peut-être, mais si l'utilisateur veut créer le TLV machin, j'aurais pensé qu'il fasse appelle au constructeur de la classe TLV machin, pas au constructeur de la classe TLV bidule en lui passant machin en paramètre.

Puis le enum dans la classe mère je ne suis pas convaincu que ce soit la bonne façon de faire car ça n'est pas très extensible. Si je souhaite rajouter des TLV je devrais modifier le enum et toutes les classes faisant un "pattern matching" (ou un case) sur le type.

Bref je suis un peu dubitatif sur les choix que j'ai fait jusqu'à présent et je me demande s'il n'éxiste pas une meilleure solution.

En espérant avoir été clair,

Bonne journée

[bacelar]

Le plus simple, c'est de ce servir d'un Framework de sérialisation qui s'occupera de tous ces détails pour vous et de manières transparentes.

[Bousk]

Salut,

un moyen simple de faire avec l'enum justement

Code :

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

1
2
3
4
5
6
7
8
9
enum TLVType { Type1, Type2, ... };
struct BaseType {
 TLVType _type;
 BaseType(TLVType__type) : _type(__type) {}
};
struct TLV1 {
TLV1(...) : BaseType(TLVType::Type1) {}
};
...

par contre, oublie les "oui mais les 2 types là ils ont X, Y champs communs, ..." ça complique la tache pour pas grand chose.
Si vraiment tu veux utiliser ce genre de trucs, tu peux mettre des classes intermédiaires, mais je conseille pas.

[Invité]

Bonjour,

pourquoi

Code :

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

1
2
3
4
5
6
7
8
9
10
11
class Tlv{
	enum TlvType {
           ... //Differents types de TLV
 
	};
protected:
	TlvType type_;
public:
	TlvType type();
	Tlv();	
};

enum TlvType? à quoi sert ton enum
à quoi sert de stocker le type?

si Tlv est la classe mère,
tu as tes types
Tlv1, Tlv2,... qui sous des fils de Tlv
Rien ne t'empêche de considérer
Tlv11 et Tlv12 qui sont des fils de Tlv1 si leur champs sont identiques, de toute façon tu manipuleras des Tlv* non?

[Frank1010]

@bacelar: la sérialisation est hors de propos dans le cadre de ce projet. Le protocole est un protocole pair à pair. Chaque étudiant utilisant son propre langage avec ses propres frameworks. Je ne vois pas en plus en quoi ça me concerne puisque je cherche à définir la sémantique des paquets à l'intérieur de mon programme, le réseau n'intervient pas là-dedans.

@bousk: je ne comprend pas bien l'avantage de ta solution par rapport à celle que j'ai proposée. Tu peux me dire ce qu'elle apporte ?

@galerien69: Je n'ai pas assez d'expérience pour savoir si je ne vais manipuler que des Tlv* mais à vue de nez j'ai envie de dire non. En effet, une tlv peut contenir l'adresse d'autres pairs, une autre peut contenir des données, une autre peut contenir d'autres informations. Bref, chaque tlv à une sémantique propre et j'ai envie d'avoir un comportement spécifique en fonction de la tlv. J'ai donc besoin d'avoir accès à des fonctions membres à l'intérieur.

Pourquoi je veux un enum pour spécifier le type ? Parce que si je me place du côté client, je n'ai pas envie de connaître le mapping entre les int et les tlv correspondant. En l'occurence il y a une dizaine de type + les extensions, c'est pas très sympa je trouve. Le but de l'enum est donc de fournir ce mapping au client car en interne, le type du paquet envoyé par le réseau sera un entier.

Par contre je ne sais pas pourquoi mais ça m'embête que deux tlv qui vont avoir la même interface soient dans deux classes différentes juste à cause du type et en même temps je vois mal comment les mettre dans la même classe.

J'ai surtout l'impression qu'il y a une meilleure solution et que je ne la vois pas.

[bacelar]

la sérialisation est hors de propos dans le cadre de ce projet

Houai, sauf que ce que tu fais, bin c'est de la sérialisation/désérialisation de base.
Prend la définition de sérialisation et tu veras que tu cherches une manière de la faire, pas la plus élégante, mais c'est quand même une sérialisation.

Alors, si tu veux réinventer la roue, bin triche, regarde le plan de la vraie roue.

Si tu veux absolument une mécanique avec un T sous forme d'un numérique, regardes comment les MFC l'ont généré, avec une classe de base et une macro pour enregistrer l'identifiant d'une classe dans un membre static de la classe de base. Cela permet une extensibilité automatique.
Les MFC gèrent aussi le versionning, mais là, c'est un peu overkill.
Les MFC utilise la classe CArchive (http://msdn.microsoft.com/en-us/library/caz3zy5s.aspx) pour permettre une sérialisation/désérialisation d'objet polymorphique:
http://www.informit.com/library/cont...Plus&seqNum=93

[Frank1010]

@bacelar: excuse moi d'insister mais je ne suis pas d'accord. Alors peut-être que je me suis mal exprimé, mais le sujet définit le format des paquets à envoyer sur le réseau : que mettre à l'octet 0, à l'octet 1 etc... Je ne vois pas en quoi la sérialisation va m'aider. Ce que je veux c'est une représentation de mes objets en C++ qui soit intéressante à utiliser. Je ne vois pas en quoi la sérialisation va m'aider. L'interface ne correspond pas du tout à ce que je souhaite.

[bacelar]

http://fr.wikipedia.org/wiki/S%C3%A9rialisation
Donc pile-poil.
Tu veux ton propre format de sérialisation, dont acte, mais c'est de la sérialisation.
Il y a des Framework de sérialisation paramétrables qui devraient permettre de s'adapter à ton format.
L'utilisation de MACRO des MFC permet une gestion extensible des types sérialisable. Vous pouvez vous en servir juste pour ça, et pas pour le reste.
Peut-être que d'autres Framework utilisent d'autres mécanismes pour la même chose, mais je ne pense pas qu'ils soient plus simple que la bête MACRO MFC facilement émulable hors MFC.

[Frank1010]

Ok ok. Mais même si ça s'appelle de la sérialisation, je ne vois pas pourquoi dans ce cadre de projet de petit envergure, j'irai utiliser les outils que tu propres.

Mon problème à la base est un problème de modélisation pas de librairie. Pour le coup, ce que vous proposez risque de me compliquer la vie plus qu'autre chose. Surtout que même si c'est une forme de sérialisation, je ne vois pas du tout en quoi votre solution me simplifierait la vie.

[bacelar]

Avez-vous au moins regardé comment était implémenté cette mécanique ?

Il n'y a rien de sorcier, c'est juste de l'astuce.

Vos classes sérialisables dérivent toutes d'une classe de base.
Cette classe de base dispose d'un membre statique permettant d'associer un entier T à une classe.
Les MACRO permettent de mettre à jour ce membre avec le type de la classe dérivé (en faite un pointeur sur un "constructeur" de la classe et l'entier T, venant d'une enum ou non).

Le désérialiseur n'a qu'à lire le membre statique de la classe de base à la recherche de la valeur T qui à lu dans le flux, de lire la longueur, de récupérer le nombre d'octets correspondant et de les envoyer au "constructeur" enregistré qui lira cette chaine pour en faire un objet correspondant.

C'EST TOUT.

[Frank1010]

Je suis désolé, mais je n'arrive pas à voir l'intérêt de votre proposition. Ca ne ressemble pas du tout à ce que j'avais en tête.

En fait, si on regarde les TLV d'un point de vue fonctionnel, ce sont juste des types algébriques. Du coup, ce poly semble répondre à ma demande : http://astitcher.github.io/ACCU2012/...algebraic.html

Peut-être que c'est de la sérialisation, mais je préfère cette vision des choses.

Merci à vous bacelar.

Cependant si vous avez d'autres propositions, je reste preneur

[bacelar]

Moi, je ne vois pas de rapport entre un type algébrique et la sérialisation/désérialisation d'un flux eu format TLV.

Le principe de la sérialisation à la MHC est simple.

Le désérialisateur a besoin de créer les objets associés au type T avec les données V.
Les MACRO MFC ne font qu'alimenter un repository (le membre static de la classe mère CObject) qui associe à une valeur T une fonction capable de produire un objet correspondant à la classe associée à T en lui passant V comme un tableau d'octet.

[Frank1010]

Nous arrivons je pense dans une discussion de sourd. Vous persistez dans votre avis à parler de sérialisation/désérialisation et je vous dis que ça ne m'intéresse pas.

Le rapport avec les types algébriques est pourtant triviale. On peut représenter les un TLV selon un type algébrique simple :

Code :

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

1
2
 
data TLV = TLV1 | TLV2 | TLV3 | TLV4 of peer list

Puis derrière on a des fonctions qui peuvent faire ce qu'on a envie avec une TLV par exemple :

Code :

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

1
2
3
4
5
 
let get_peer tlv =
    match tlv with
        | TLV4 (p_list)= -> p_list
        | _ -> []

Et c'est un peu comme ça que je vois mon programme. On me donne une TLV je fais un pattern matching dessus et je fais un traitement.

Ok c'est de la désérialisation. De la même manière que lorsque je souhaiterais créer mes TLV, je voudrais faire de la sérialisation. Mais il me semble que la sérialisation demande d'avoir le paquet en entier. Or, a priori, je n'ai pas de raison de sérialiser un paquet en entier. Je souhaite peut-être le construire au fur et à mesure en fonction de ce qu'un pair m'envoie.

De la même manière, je n'ai pas envie de tout désérialiser puisqu'il peut y avoir des TLV de padding.

Donc j'en reviens à mon point de vue de débutant et restreint où utiliser votre outil me semble compliqué. Pour vous ça semble facile mais mon expérience fait que l'approche par type algébrique et peut-être un petit pattern visiteur si j'ai l'envie me semble plus simple.

[Invité]

re,

c'est une question bete mais

J'ai donc besoin d'avoir accès à des fonctions membres à l'intérieur.

quel type de fonctions peut varier d'un tlv à l'autre.

De mon point de vue tu as un tlv par format. A fortiori, deux formats différents c'est deux tlv différents.
Eventuellement tu peux avoir un format générique encore que faut faire gaffe aux restrictions qui peuvent survenir par d'autres formats. (voir liskov)

Du coup, la première question qui se pose c'est:
tes tlv t'as vraiment besoin d'avoir des fonctions dessus, ou tu peux composer, idem tu différencies les données des fonctions.
considères que t'as une structure

Code :

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

1
2
3
4
5
6
7
8
struct TlvA{//format A
 int a;
 int print(){return 2+a;}
}
struct TlvB{//format B
 int b;
 int doThis(){return b;}
}

tu peux très bien imaginer avoir

Code :

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

1
2
3
4
5
6
7
8
9
struct Data{int a;}
struct TlvA{
 struct Data d;
 int print(){return 2+d.a;}
}
struct TlvB{
 struct Data d;
 int doThis(){return d.a;}
}

(mon petit doigt me dit que tes tlv c'est surtout la masse de données au format différents donc t'embêtes pas à faire de l'héritage ou je sais pas quoi (sauf pour sérialiser))
Par contre la facon dont tu te sers des données je pense qu'elle change.
donc tu peux faire deux TlvUser1 et TlvUser2 qui utilisent un meme TlvData

au final ca devient intéressant de faire une archi pour tes TlvUser s'ils ont des comportements similaires mais tes TlvData je les garderais séparés les uns des autres

ps:

On me donne une TLV...

si on te donne un Tlv (idem générique) mais que tu dois faire un traitement spécifique dessus...tu échapperas pas au switch ou au dynamic_cast
dans tous les cas tu auras un pointeur qui traine. Soit dans ton store (ou tu fais ton pattern matching dessus) qui a des Tlv*, soit dans ton Tlv si tu as dissocié Data (vu que deux Tlv auront des Data différents, idem Data*)

[KsassPeuk]

@Frank1010 : tu essaies de transposer ce que tu as appris dans un autre langage en C++. Ce n'est pas du tout une bonne manière de faire. Si ce langage est différent, il ne s'utilise pas de la même manière.

En l'occurrence, le DP visiteur en C++, c'est franchement pas une partie de rigolade. Si on l'utilise c'est parce qu'on a pas de manière plus élégante de faire, sinon on s'en passerait.

Utiliser un outil dédié qui a été codé par des gens largement plus compétent que soi-même est largement préférable au fait de coder un truc branlant qui ne fera que la moitié du job. Il y a la solution que propose @bacelar mais aussi boost::serialization, etc ...

EDIT : puis si on veut un truc simple qui tient la route, il suffit d'arrêter de penser aux données. Tu reçois un tag, ça génère une tâche (du bon type donc), la tâche extrait du réseau les informations qui la concerne (désérialisation par une fonction template) et fais son boulot. Inversement, envoyer des données, c'est demander la création d'une tâche ailleurs et fournir les informations qui seront nécessaires.

[Frank1010]

@Frank1010 : tu essaies de transposer ce que tu as appris dans un autre langage en C++. Ce n'est pas du tout une bonne manière de faire. Si ce langage est différent, il ne s'utilise pas de la même manière.

En l'occurrence, le DP visiteur en C++, c'est franchement pas une partie de rigolade. Si on l'utilise c'est parce qu'on a pas de manière plus élégante de faire, sinon on s'en passerait.

Utiliser un outil dédié qui a été codé par des gens largement plus compétent que soi-même est largement préférable au fait de coder un truc branlant qui ne fera que la moitié du job. Il y a la solution que propose @bacelar mais aussi boost::serialization, etc ...

En codant, je me rend compte de mon erreur. En effet, c'est pas du tout efficace ce que j'ai fait. En partie parce que les TLV ont des relations que je n'avais pas vu avant.

EDIT : puis si on veut un truc simple qui tient la route, il suffit d'arrêter de penser aux données. Tu reçois un tag, ça génère une tâche (du bon type donc), la tâche extrait du réseau les informations qui la concerne (désérialisation par une fonction template) et fais son boulot. Inversement, envoyer des données, c'est demander la création d'une tâche ailleurs et fournir les informations qui seront nécessaires.

Et là, je ne te suis pas, probablement car je n'ai pas assez d'expérience.

Merci à vous pour vos conseils


Edit :

Peut-être que j'ai mal compris mais j'ai de toute façon besoin d'avoir des classes Tlv pour les sérialiser (avec boost par exemple). Donc je dois bien spécifier une certaine "hiéarchie" entre mes tlv si il y a des points en commun pour les sérialiser.

L'autre point c'est que le protocole spécifie certe un ordre, mais un ordre d'octets, avec une longueur etc... En quoi le fait de sérialiser va m'aider à faire passer ça sur le réseau ? Car au retour, les gens ils vont recevoir un paquet de bits qui doivent exactement correspondre au protocole. Si l'archive rajoute des bits c'est inutile. Bref, je vois bien pourquoi c'est de la sérialisation, mais je ne vois pas comme une bibliothèque peut s'adapter au projet.

[koala01]

Salut,

L'autre point c'est que le protocole spécifie certe un ordre, mais un ordre d'octets, avec une longueur etc... En quoi le fait de sérialiser va m'aider à faire passer ça sur le réseau ? Car au retour, les gens ils vont recevoir un paquet de bits qui doivent exactement correspondre au protocole. Si l'archive rajoute des bits c'est inutile. Bref, je vois bien pourquoi c'est de la sérialisation, mais je ne vois pas comme une bibliothèque peut s'adapter au projet.

Le but de la sérialisation (respectivement de la désérialisation) n'est pas de créer une archive! Le but de la sérialisation est de créer un flux de données. Pour créer un flux de données, on va respecter un protocole qui indique quelles données seront transmises, dans quelle ordre et sous quelle forme (taille et boutisme éventuel).

L'idée est de pouvoir placer à "l'autre bout du flux" un système qui utilisera le même protocole pour récupérer les données qui ont été transmise. On parle de désérialisation.

Le fait que ces processus envoient (respectivement récupèrent) les données au travers du réseau, du disque dur ou des vibrations d'une peau de cuir tendue sur un tamtam n'a absolument plus rien à voir avec le problème : une fois que tu as su créer le flux de données, tu le transmet (et donc tu le récupère) de la manière qui correspond le mieux à ton besoin

Et, si les besoins auxquels tu es confrontés t'obligent à organiser plusieurs flux de données et, pourquoi pas, à essayer de limiter la taille qui sera transmise sur le réseau (car la taille totale des données transmises aura forcément un impact sur le temps nécessaire à leur transmission d'un point A à un point B), tu peux décider de faire passer (ou non !!!) le flux de données par une "moulinette supplémentaire" qui aurait pour effet de regrouper plusieurs "fichiers" (voir plusieurs dossers) sous la forme d'un seul fichier unique et, pourquoi pas, d'utiliser un algorithme qui permette de transmettre un maximum d'information en utilisant le minimum de bits (on parle de compression).

Evidemment, si tu veux utiliser ces "moulinettes supplémentaires" d'un coté (lors de la sérialisation), il faudra penser à ... utiliser les moulinettes qui te permettent d'obtenir l'effet inverse (décompression, séparation des différents fichiers) de l'autre (lors de la désérialisation). Mais ca, ca n'a pas grand chose à avoir avec le problème de la sérialisation, cela a juste à voir avec d'éventuels problème d'organisation des données qui doivent être transmises, voir (pour ce qui est de la compression) avec d'éventuels problèmes liés à la quantité d'information à transmettre et donc au temps nécessaire pour ce faire .