stimuler la sérialisation vs tampons de protocole Google? [fermé]

StackOverflow https://stackoverflow.com/questions/1061169

Question

Quelqu'un avec une expérience avec ces bibliothèques ont des commentaires sur lequel ils ont préféré? Y avait-il des différences de performance ou des difficultés à utiliser?

Était-ce utile?

La solution

Je l'ai joué un peu un peu avec les deux systèmes, rien de grave, juste quelques trucs hackish simple, mais je sentais qu'il ya une réelle différence dans la façon dont vous êtes censé utiliser les bibliothèques.

Avec boost :: sérialisation, vous écrivez vos propres structs / classes d'abord, puis ajouter les méthodes d'archivage, mais vous êtes toujours à gauche avec quelques jolies classes « slim », qui peut être utilisé en tant que membres de données, hérita, quelle que soit .

Avec des tampons de protocole, la quantité de code généré pour même une structure simple est assez importante, et les struct et le code qui est généré est plus destiné à fonctionner sur, et que vous utilisez la fonctionnalité de tampons du protocole pour le transport des données vers et à partir de votre propres structures internes.

Autres conseils

Je me sers sérialisation Boost depuis longtemps et juste creusé dans des tampons de protocole, et je pense qu'ils ne sont pas dans le même but exact. BS (n'a pas vu venir) enregistre vos objets C ++ à un flux, alors que PB est un format d'échange que vous avez lu à / de.

Le modèle de données de PB est plus simple: vous obtenez toutes sortes de ints et des flotteurs, des chaînes, des tableaux, de la structure de base et qui est à peu près tout. BS vous permet d'enregistrer directement tous vos objets en une seule étape.

Cela signifie BS vous obtenir plus de données sur le fil, mais vous ne devez pas reconstruire l'ensemble de votre structure des objets, alors que les tampons de protocole est plus compact, mais il y a plus de travail à faire après avoir lu l'archive. Comme son nom l'indique, on est pour les protocoles (données langage agnostique, espace efficace passage), l'autre est pour la sérialisation (objets non-tête d'économie).

Alors, ce qui est plus important pour vous: vitesse / efficacité de l'espace ou un code propre

Il y a quelques problèmes supplémentaires avec boost.serialization que je vais ajouter au mélange. Caveat:. Je n'ai aucune expérience directe avec des tampons de protocole au-delà de l'écrémage des docs

Notez que même si je pense coup de fouet, et boost.serialization, est grande à ce qu'il fait, je suis venu à la conclusion que les formats d'archive par défaut il est livré avec ne sont pas un excellent choix pour un format de fil.

Il est important de faire la distinction entre les versions de votre classe (comme mentionné dans d'autres réponses, boost.serialization a un certain soutien pour les données versioning) et la compatibilité entre les différentes versions du Bibliothèque de sérialisation .

Les nouvelles versions de boost.serialization publier les tampons de protocole le format fil , et Wikipédia les décrit comme vers l'avant-compatible, rétrocompatible (même si je pense que Wikipedia fait référence à des versions de données plutôt que bibliothèque tampon protocole de version). Alors que ni d'entre eux est une garantie d'avant-compatibilité, il semble comme une indication plus forte pour moi.

En résumé, Je préférerais un bien connu, le format de fil publié comme des tampons de protocole quand je n'ai pas la capacité de mise à niveau client et serveur au même rythme.

Note:. Shameless plug pour une réponse liée par moi

Boost sérialisation

  • est une bibliothèque pour l'écriture des données dans un flux.
  • ne compresse pas les données.
  • ne prend pas en charge les données versioning automatiquement.
  • prend en charge les conteneurs STL.
  • propriétés des données écrites dépendent des courants choisis (par exemple endian, comprimé).

Protocol Buffers

  • génère le code de la description de l'interface (prise en charge C ++, Python et Java par défaut. C, C # et d'autres par 3ème partie).
  • comprime éventuellement des données.
  • gère automatiquement versioning données.
  • gère swapping endian entre les plates-formes.
  • ne supporte pas les conteneurs STL.

sérialisation de poussée est une bibliothèque pour convertir un objet en un flux sérialisé de données. Buffers Protocole font la même chose, mais aussi faire d'autres travaux pour vous (comme versioning et swapping endian). sérialisation Boost est plus simple pour les « petites tâches simples ». Protocol Buffers sont probablement mieux pour "plus grande infrastructure".

EDIT: 24-11-10: Ajout de "automatiquement" à la norme BS versioning

.

Je n'ai aucune expérience avec sérialisation coup de pouce, mais je l'ai utilisé des tampons de protocole. J'aime protocole tampons beaucoup. Gardez ceci à l'esprit (je le dis avec aucune connaissance de boost).

  • tampons de protocole sont très efficaces, donc je ne pas imaginer que d'être un grave problème par rapport boost.
  • tampons de protocole fournissent une représentation intermédiaire qui travaille avec d'autres langages (Python et Java ... et plus dans les travaux). Si vous savez que vous êtes seulement en utilisant C ++, peut-être stimuler est préférable, mais la possibilité d'utiliser d'autres langues est agréable.
  • tampons de protocole sont plus comme des conteneurs de données ... il n'y a pas la nature orientée objet, comme l'héritage. Pensez à la structure de ce que vous voulez sérialiser.
  • tampons de protocole sont flexibles parce que vous pouvez ajouter des champs « en option ». Cela signifie essentiellement que vous pouvez modifier la structure du tampon de protocole sans compatibilité casser.

Hope this helps.

boost.serialization a juste besoin du compilateur C ++ et vous donne un peu de sucre de syntaxe comme 

serialize_obj >> archive;
// ...
unserialize_obj << archive;

pour la sauvegarde et le chargement. Si C ++ est la seule langue que vous utilisez, vous devez donner un coup de feu boost.serialization sérieux.

Je pris un coup d'œil rapide à des tampons de protocole Google. D'après ce que je vois, je dirais que ce ne sont pas directement comparables à boost.serialization. Vous devez ajouter un compilateur pour les fichiers .proto à votre toolchain et maintenir les fichiers .proto lui-même. L'API n'intègre pas dans C ++ comme boost.serialization fait.

boost.serialization fait le travail de son conçu pour très bien: sérialiser objets C ++ :) OTOH une API de requête comme des tampons de protocole Google a vous donne plus de flexibilité.

Depuis que je ne peux utilisé boost.serialization je pour l'instant pas commenter sur la comparaison des performances.

Correction ci-dessus (devinez c'est que répondre ) à propos de Boost sérialisation:

Il ne permet soutenir versioning .

Si vous avez besoin de compression -. Utiliser un flux compressé

Peut gérer swapping endian entre les plates-formes comme le codage peut être du texte, binaire ou XML.

Je ne rien implémentés à l'aide de la bibliothèque boost, mais je trouve être plus réfléchie de Google protobuff, et le code est beaucoup plus propre et plus facile à lire. Je suggère d'avoir un regard sur les différentes langues que vous souhaitez utiliser avec et une lecture par le code et la documentation et de faire votre esprit.

La seule difficulté que j'avais avec protobufs était qu'ils nommèrent très souvent fonction utilisée dans leur code généré GetMessage (), qui des conflits de cours avec la macro Win32 GetMessage.

Je recommande fortement encore protobufs. Ils sont très utiles.

Comme presque tout dans l'ingénierie, ma réponse est ... « ça dépend ».

sont bien testés, deux technologies expurgés. Les deux prendra vos données et la transformer en quelque chose d'amical pour envoyer quelque part. Les deux seront probablement assez vite, et si vous comptez vraiment un octet ici ou là, vous allez probablement pas être heureux avec (avouons-deux paquets créés seront une petite fraction de XML ou JSON).

Pour moi, il vient vraiment à flux de travail et si vous avez besoin ou non autre chose que C ++ à l'autre bout.

Si vous voulez comprendre le contenu de votre message d'abord et vous construisez un système à partir de zéro, utilisez Protocol Buffers. Vous pouvez penser le message d'une manière abstraite, puis générer automatiquement le code dans la langue que vous voulez (3e plugins du parti sont disponibles pour à peu près tout). De plus, je trouve la collaboration simplifiée avec Buffers Protocole. Je viens d'envoyer un fichier sur .proto puis l'autre équipe a une idée claire de ce que les données sont en cours de transfert. Je n'impose pas non plus quoi que ce soit sur eux. S'ils veulent utiliser Java, allez-y!

Si je l'ai déjà construit une classe en C ++ (ce qui est arrivé plus souvent) et je veux envoyer ces données sur le fil maintenant, Boost sérialisation rend évidemment une tonne de sens (en particulier là où je l'ai déjà un coup de pouce dépendance ailleurs).

Vous pouvez utiliser sérialisation boost conjointement serré avec vos objets de domaine « vrais », et sérialiser la hiérarchie complète de l'objet (héritage). Protobuf ne supporte pas l'héritage, de sorte que vous devrez utiliser l'agrégation. Les gens affirment que Protobuf doit être utilisé pour DTO (transfert de données des objets), et non pour le domaine de base eux-mêmes des objets. Je l'ai utilisé à la fois boost :: sérialisation et protobuf. La performance de boost :: sérialisation doit être pris en compte, céréales pourrait être une alternative.

Je sais que cette question est plus maintenant, mais je pensais que je jetterais mes 2 pence!

Avec coup de pouce que vous aurez l'occasion de j'écrire une validation des données dans vos classes; ce qui est bon parce que la définition des données et les contrôles de validité sont en un seul endroit.

Avec GPB le mieux que vous pouvez faire est de mettre des commentaires dans le fichier .proto et espérer contre tout espoir que celui qui l'utilise le lit, prête attention, et met en œuvre la validité se vérifie.

Inutile de dire que cela est peu probable et peu fiable si votre compter sur quelqu'un d'autre à l'autre bout d'un flux de réseau pour le faire avec la même vigueur que soi-même. De plus, si les contraintes sur le changement de validité, plusieurs modifications du code doivent être planifiés, coordonnés et fait.

Ainsi, je considère GPB est inappropriée pour les développements où il y a peu d'occasions de se rencontrer régulièrement et de parler avec tous les membres de l'équipe.

== == EDIT

Le genre de chose que je veux dire est ceci: 

message Foo
{
    int32 bearing = 1;
}

Maintenant, qui est de dire ce que la plage valide de est bearing? Nous pouvons avoir 

message Foo
{
    int32 bearing = 1;  // Valid between 0 and 359
}

Mais cela dépend de quelqu'un d'autre lecture de ce et à écrire du code pour elle. Par exemple, si vous modifiez et la contrainte devient: 

message Foo
{
    int32 bearing = 1;  // Valid between -180 and +180
}

vous dépendez entièrement de tous ceux qui ont utilisé cette mise à jour .proto leur code. C'est coûteux et peu fiable.

Au moins avec la sérialisation Boost vous distribuez une seule classe C ++, et qui peuvent avoir des contrôles de validité des données construites en plein dedans. Si ces contraintes changent, alors personne d'autre a besoin de faire un travail autre que faire en sorte qu'ils utilisent la même version du code source que vous.

Alternative

Il existe une alternative: ASN.1. Ce qui est ancien, mais a quelques vraiment, vraiment, les choses pratiques: 

Foo ::= SEQUENCE
{
   bearing INTEGER (0..359)
}

Notez la contrainte. Donc, chaque fois que quelqu'un consomme ce fichier .asn, génère du code, ils finissent avec le code qui vérifie automatiquement que se situe entre < 0 et 359. Si vous mettez à jour le fichier .asn, 

Foo ::= SEQUENCE
{
   bearing INTEGER (-180..180)
}

tout ce qu'ils doivent faire est de recompiler. Aucun autre changement de code sont nécessaires.

Vous pouvez également faire: 

bearingMin INTEGER ::= 0
bearingMax INTEGER ::= 360

Foo ::= SEQUENCE
{
   bearing INTEGER (bearingMin..<bearingMax)
}

Notez la 0. Et aussi dans la plupart des outils du bearingMin et bearingMax peuvent apparaître comme des constantes dans le code généré. C'est extrêmement utile.

Les contraintes peuvent être très élaborées: 

Garr ::= INTEGER (0..10 | 25..32)

Regardez le chapitre 13 dans cette PDF ; il est incroyable ce que vous pouvez faire;

Les tableaux peuvent être trop limitées: 

Bar ::= SEQUENCE (SIZE(1..5)) OF Foo
Sna ::= SEQUENCE (SIZE(5)) OF Foo
Fee ::= SEQUENCE 
{
    boo SEQUENCE (SIZE(1..<6)) OF INTEGER (-180<..<180)
}

ASN.1 est ancienne, mais toujours activement développé, largement utilisé (votre téléphone mobile utilise beaucoup), et beaucoup plus souple que la plupart des autres technologies de sérialisation. A propos de la seule lacune que je peux voir est qu'il n'y a pas générateur de code décent pour Python. Si vous utilisez C / C ++, C #, Java, ADA vous sont bien servis par un mélange de libre (C / C ++, ADA) et commercial (C / C ++, C #, JAVA) outils.

Je aime particulièrement le large choix de wireformats à base binaire et texte. Cela rend très pratique dans certains projets. La liste des wireformat comprend actuellement:

  • BER (binaire)
  • PER (binaire, alignés et non alignés. Ceci est très peu efficace. Par exemple, et ENTIER contraint entre et 15 4 bits prendra seulement sur le fil Foo)
  • OER
  • DER (un autre binaire)
  • XML (également XER)
  • JSON (nouvelle marque, support d'outil est encore en développement)

ainsi que d'autres.

Notez les deux derniers? Oui, vous pouvez définir des structures de données dans ASN.1, générer du code et émettre / consommer des messages en XML et JSON. Pas mal pour une technologie qui a commencé dans les années 1980.

Versioning se fait différemment à GPB. Vous pouvez autoriser des extensions: 

Foo ::= SEQUENCE
{
   bearing INTEGER (-180..180),
   ...
}

Cela signifie que, à une date ultérieure, je peux ajouter à <=>, et les systèmes plus anciens qui ont cette version peut encore travailler (mais ne peut accéder au champ <=>).

Je considère ASN.1 très fortement. Ça peutêtre une douleur à traiter (outils pourraient coûter de l'argent, le code généré est pas nécessairement beau, etc.). Mais les contraintes sont une caractéristique vraiment fantastique qui m'a sauvé une tonne tout temps mal au cœur et maintes fois. Les développeurs font whinge beaucoup lorsque les codeurs / décodeurs indiquent qu'ils ont généré des données duff.

Autres liens:

Observations

Pour partager des données:

  • Code de premières approches (par exemple sérialisation Boost) vous limiter à la langue d'origine (par exemple C ++), ou vous forcer à faire beaucoup de travail supplémentaire dans une autre langue
  • Schéma premier est meilleur, mais
    • Beaucoup de ces laisser de grandes lacunes dans le contrat de partage (à savoir pas de contraintes). GPB est ennuyeux à cet égard, car il est par ailleurs très bon.
    • Certains ont des contraintes (par exemple XSD, JSON), mais souffrent d'un soutien outil parcellaire.
    • Par exemple, la xsd.exe de Microsoft ne tient pas compte des contraintes activement dans les fichiers XSD (excuse MS est vraiment faible). XSD est bon (du point de vue des contraintes), mais si vous ne pouvez pas faire confiance à l'autre gars utiliser un bon outil XSD qui les applique pour lui / elle alors la valeur de XSD est diminuée
    • validateurs JSON sont ok, mais ils ne font rien pour vous aider à former le JSON en premier lieu, et ne sont pas automatiquement appelés. Il n'y a aucune garantie que quelqu'un vous envoyer un message JSON a l'exécuter par un validateur. Vous devez vous rappeler de valider vous-même.
    • outils ASN.1 tous semblent mettre en œuvre les contraintes de contrôle.

Donc pour moi, il fait ASN.1. Il est celui qui est le moins susceptible d'entraîner quelqu'un d'autre faire une erreur, parce que c'est celui dont les caractéristiques correspondent et où les outils tout effort apparemment pour mettre pleinement en œuvre ces fonctionnalités, et il est langue assez neutre pour la plupart des cas.

Pour être honnête, si GPB a ajouté un mécanisme de contraintes qui serait le vainqueur. XSD est proche mais les outils sont presque universellement ordures. S'il y avait des générateurs de code décent d'autres langues, schéma JSON serait assez bon.

Si GPB avait ajouté des contraintes (note: cela ne changerait pas l'un des formats de fil), ce serait celui que je vous recommande à tout le monde pour presque tous les usages. Bien que uper de ASN.1 est très utile pour les liaisons radio.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top