Discussion :

[Trademark]

Bonjour,

À l’occasion d'un projet, je dois coder un serveur. L'échange des données se fait principalement sous cette forme :

Code :

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

1
2
3
4
5
6
[balise1]
  id = IDENTIFIANT
  [info]
    nom = NOM
  [/info]
[/balise1]

On a déjà une classe qui s'occupe de parser ce schéma dans un arbre. Ce que j'aimerais c'est pouvoir valider cet arbre.

Par exemple avoir un schéma comme :

Code :

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

1
2
3
4
5
6
[balise1]
  id = REGEX <-- requis
  [info] <-- {0 .. 2}
    nom = REGEX <-- requis
  [/info]
[/balise1]

Ce validateur devrait pouvoir vérifier la répétition d'un champ, par exemple le champ info peut apparaitre de 0 à 2 fois. Et ceci sous d'autres formes encore comme '*', '1 .. *', ...

On controlera les types avec un regex ou éventuellement autre chose suivant.

Et il faudra que le nom des balises et des attributs soient exactement les mêmes.

Plus encore peut-être d'autre choses auxquelles je n'ai pas encore pensé.

J'étais prêt à coder ma propre solution, mais en essayant de faire un design, je me suis demandé si ce n'était pas un peu comme un lexer. Ou s'il n'existait pas des solutions pour ça, vu que ça semble assez banal.

Du coup j'ai un peu regardé Boost.Spirit.Lex mais est-ce que ça n'est pas un peu étrange d'écrire des règles de cette manière pour un protocole réseau ? Et de plus, j'ai l'impression que c'est un peu trop pour mon problème.

N'hésitez pas à me demander plus de détails.

Merci d'avance

[koala01]

Salut,

Je me demande si boost spirit ne te permettrait pas de faire tout cela :

• Spirit Qi est un parser
• Spirit Kama est un générateur (écriture)
• Spirit Lex est un analyseur lexical

Je ne sais pas quel est l'état d'avancement de ton projet ( surtout en ce qui concerne le parsing et l'écriture), mais, peut etre est-il encore temps de prendre une "solution intégrée"

Ouppsss... je m'étais arrêté avant la fin du message et n'avais pas remarqué que tu envisageais effectivement spirit...

Non, pour moi, il n'y a pas vraiment de problème à utiliser spirit pour un protocole réseau, étant donné que, de toutes manières, les informations peuvent être considérées comme un flux de données

De plus, "qui peut le plus peut le moins"... Tu auras plus facile à ne pas utiliser quelque chose de présent qu'à... essayer d'avoir quelque chose qui n'existe pas

[Trademark]

Merci pour ta réponse koala01,

En fait, c'est un projet open-source nommé Wesnoth, qui est un jeu de stratégie au tour par tour.

Ils ont déjà une classe config qui stocke un fichier comme présenté ci-dessus.

Ce qu'il me faut c'est juste la partie "validation".

De plus je me disais, qu'au final, un schéma est quelque chose de statique. J'ai donc envisagé les possibilités les plus folles avec la métaprogrammation et Boost::mpl par exemple. Mais je ne suis pas arrivé à quelque chose de convainquant.

Sachant que Spirit.Lex est totalement dynamique, je me demandais si ce n'était pas une éventuelle perte de performance ?

De toutes manières, les schémas seront créés dès le début, et au final je voudrais juste pouvoir faire :

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
config cfg;
// On récupère du réseau les données dans config.
// ...
 
validator.validate(cfg);
 
// Et dans validator on ferait quelque chose comme :
 
bool validate(const config &cfg)
{
  std::string label = cfg[0];
  if(label == "update")
    return update_validator.validate(cfg);
  else if(label == ...)
  // ...
 
  return false;
}

Ce qui serait statique serait par exemple, update_validator. Mais je ne sais pas comment représenter statiquement update_validator et si ça a un réel avantage.

Qu'en pensez-vous ?

[koala01]

Le fait est que, de toutes manières, le schéma n'est pas validé en permanence...

Typiquement, si c'est un schéma de configuration, tu vas le valider une première fois au moment de charger la configuration et, éventuellement, au moment où tu voudras sauvegarder une configuration modifiée.

Je ne pense sincèrement pas que tu doives réellement t'inquiéter des problèmes de performances dans le cas présent : n'oublie pas que 80 du temps d'exécution est perdu dans 20% du code...

AMHA, les problèmes de performance ne viendront pas d'un endroit qui n'est utilisé que si rarement

[Trademark]

Je pense qu'on s'est mal compris et que le nom de la classe porte à confusion.

La validation va s'opérer à chaque fois qu'on va recevoir un paquet du réseau, pour valider ce paquet. Un paquet est organisé comme présenté ci dessus.

Du coup, les questions de performance peuvent peut-être se poser ici.

[ternel]

Pas vraiment puisque les paquets réseaux n'arrivent qu'à chaque changement de tours, soit toutes les deux minutes et non toutes les secondes.

Alors, si la validation prends quelques secondes, le joueur est en général d'accord pour attendre si peu au changement de tour. (surtout qu'on doit pouvoir réaliser les animations de début de tour pendant ce temps...)

[Trademark]

Salut,

Merci pour cette réponse mais le serveur n'a rien avoir avec le jeu en lui-même. C'est un serveur d'add-ons.

Les paquets arriveront n'importe quand et éventuellement très vite.

Donc j'en profite pour reposer la question, est-ce qu'il y a des manières efficace de valider un schéma ?

Merci d'avance.

[Emmanuel Deloget]

S'il y a la possibilité de faire les choses bien, c'est à dire de ne PAS réinventer XML en moins puissant, je proposerais bien XSD.

Mais s'il y a une forte volonté de faire quelque chose qui va être compliqué à maintenir, sera probablement buggé ici et là, je propose (quitte à faire) de réimplémenter un XSD-like pour valider le XML-like.

C'est important, pour un projet Open Source, de minimiser les dépendances envers d'autres projets Open Source

[ternel]

Il me semble que le projet à préféré créer son propre *ML (WML) pour des raisons d'optimisation
Les paquets réseau transmis sont des fichiers WML gzippé. L'équivalent XML est pratiquement deux fois plus gros, ce qui impose une bande passante double, des serveurs plus puissants, et plus gros pour avoir des performances égales.

[Trademark]

Donc comme l'a bien dit leternel, ils utilisent leur propre format : WML.

De toutes façons j'ai l'impression que je cherche midi à 14 heures. Ma question était de savoir ce qui était le plus performant pour valider un schéma (qui est connu à la compilation). Apparement un Boost.Lex fera très bien son travail ?

[Emmanuel Deloget]

Il me semble que le projet à préféré créer son propre *ML (WML) pour des raisons d'optimisation
Les paquets réseau transmis sont des fichiers WML gzippé. L'équivalent XML est pratiquement deux fois plus gros, ce qui impose une bande passante double, des serveurs plus puissants, et plus gros pour avoir des performances égales.

C'est un choix, basé sur une motivation un peu étrange. Est-ce que du XML compressé avec bzip2 n'est pas plus petit ? Et dans ce cas, pourquoi ne pas utiliser un format binaire directement ?

Enfin, ce ne sont pas mes oignons

[ternel]

Bah, je pense qu'ils ne changeront pas, parce que les utilisateurs ont déjà créé beaucoup de contenu en utilisant ce langage, et qu'ils ne peuvent plus leur dire "on ne le fait plus, oubliez tout".
À moins de créer un utilitaire de traduction, qu'il va falloir coder, tester, valider...

Mais c'est vrai que quand j'avais commencé à lire les sources de Battle for Wesnoth, j'ai trouvé étrange de ne pas avoir utilisé l'XML.

[Emmanuel Deloget]

Bah, je pense qu'ils ne changeront pas, parce que les utilisateurs ont déjà créé beaucoup de contenu en utilisant ce langage, et qu'ils ne peuvent plus leur dire "on ne le fait plus, oubliez tout".
À moins de créer un utilitaire de traduction, qu'il va falloir coder, tester, valider...

Le format est suffisamment simple un utilitaire de traduction devrait prendre environ 1 journée à coder, tester, valider et documenter

Allez, on va être généreux : trois jours.

Pour trois jours de boulot, on gagne : une extensibilité accrue (grâce au support des namespaces, qui permettre l'introduction de nouvelles fonctionnalités sans perturber les anciennes) ; des possibilités de vérification des données (grâces aux schema XML) ; la possibilité d'utiliser des requêtes XPATH pour récupérer des informations particulières ; Et certainement d'autres choses tout aussi intéressantes.

Quand à la question du remplacement des outils actuels, elle ne se pose pas en ces termes. En terme de project management, il est préférable de prévoir une période de transition - en annonçant par exemple "le code machinML est obsolète. A moins d'un problème de dernière minutes, il sera enlevé du moteur de jeu dans 18 moins. D'ici là, vous avez le temps de vous former et de changer tous les fichiers proposés. Pendant les 3 prochains moins, nous accepterons conjointement les soumission de fichiers au format machinML et XML, avec une préférence pour le XML, puis à la fin de ces 3 moins, seuls les fichiers XML seront acceptés".

C'était une bonne idée de projet pour le GSoC 2012 - mais bon, avec un peu de politique et de bonne volonté, ça sera pour le GSoC 2013

[Klaim]

Je ne sais pas si ça conviens tout a fait a ton cas, mais personellement j'utilise CodeSynthesis xsd/tree : http://www.codesynthesis.com/projects/xsd/ (il y a aussi une version speciale pour l'embarqué).

L'idée est de générer le code C++ a partir d'un XSD. Pour peu que tu prennes le temps d'écrire le XSD de manière a include la validation (un regex par exemple), tu peux alors facilement générer des fonctions de parsing qui vont s'occuper de faire la validation.

Evidement le format xsd ne permet pas d'absolument tout valider, mais le reste se passe dans le code qui interprete.

[Trademark]

Merci Klaim, c'est une piste à creuser, mais j'ai l'impression que c'est trop fort lié au XML.

Maintenant, je vais étaler ma pensée, et vous me direz ce que vous en pensez.

Le format WML est une version simplifié de XML comme vous l'aurez compris. Je pense alors simplement décrire les protocoles dans des fichiers WML "améliorés", qui permettront de décrire facilement ce que j'exprimais au premier post. La lecture de ces fichiers se fera une fois pour toute au démarrage du serveur et "l'arbre de validation" sera construit grâce à Boost.spirit.

J'espère ne pas trop ré-inventer la roue en "inventant" ce format de fichier amélioré. D'une certaines façons, Wesnoth a déjà fait à sa sauce le WML, alors je pense que ce genre d'outil de validation est de toute façon indispensable.

Néanmoins je reste quand même dubitatif quant à stocker le protocole dans un fichier. Au départ, mon idée part d'une "bonne" intention, je me dis, on pourra modifier le protocole sans modifier le code... Mais non car le protocole est trop lié à la logique applicative. Du coup, je pense que je vais créer l'arbre de validation en "dur".

Qu'en pensez-vous ?

Merci encore pour votre aide.

[ternel]

éventuellement, il doit être possible de paramétrer le protocole en dur avec un fichier. Mais dans ce cas, il faut que les clients puissent recevoir ce fichier...

[Emmanuel Deloget]

Merci Klaim, c'est une piste à creuser, mais j'ai l'impression que c'est trop fort lié au XML.

Pas illogique

Maintenant, je vais étaler ma pensée, et vous me direz ce que vous en pensez.

Le format WML est une version simplifié de XML comme vous l'aurez compris. Je pense alors simplement décrire les protocoles dans des fichiers WML "améliorés", qui permettront de décrire facilement ce que j'exprimais au premier post. La lecture de ces fichiers se fera une fois pour toute au démarrage du serveur et "l'arbre de validation" sera construit grâce à Boost.spirit.

J'espère ne pas trop ré-inventer la roue en "inventant" ce format de fichier amélioré. D'une certaines façons, Wesnoth a déjà fait à sa sauce le WML, alors je pense que ce genre d'outil de validation est de toute façon indispensable.

Néanmoins je reste quand même dubitatif quant à stocker le protocole dans un fichier. Au départ, mon idée part d'une "bonne" intention, je me dis, on pourra modifier le protocole sans modifier le code... Mais non car le protocole est trop lié à la logique applicative. Du coup, je pense que je vais créer l'arbre de validation en "dur".

Qu'en pensez-vous ?

Merci encore pour votre aide.

Est-ce que tu es sûr de ça ? je veux dire : est-ce que le fichier ne stocke pas les paramètres du protocole plutôt que le protocole lui-même ?

Je vais me pencher sur le code source, et je devrais avoir une vision plus claire du problème.

[Trademark]

Est-ce que tu es sûr de ça ? je veux dire : est-ce que le fichier ne stocke pas les paramètres du protocole plutôt que le protocole lui-même ?

Il faudrait définir ce que sont les paramètres d'un protocole, est-ce que tu considères que ce sont les valeurs véhiculées, ou en tout cas leur sémantique ? Et si c'est le cas, est-ce qu'on ne peut pas considérer que les paramètres du protocole sont liés trop fortement pour pouvoir créer une description de protocole "générique" ?

Je vais me pencher sur le code source, et je devrais avoir une vision plus claire du problème.

Il se peut qu'on se soit mal compris... Nous ne parlons pas d'un code source existant (sauf pour la partie WML qui existe depuis un moment). Je suis juste en phase de conception, d'où ces questions.

Merci de votre aide, n'hésitez pas à proposer et discuter de cela