Comment peut-buffers Google Protocole comparer à ASN.1

Question

Quelles sont les différences les plus noticable entre Google Protocol Buffers et ASN.1 (avec PER-encodage)? Pour mon projet, le problème le plus imporant est la taille des données sérialisés. Quelqu'un at-il fait des comparaisons de taille de données entre les deux?

Answer 1

Il y a longtemps que je l'ai fait tout travail ASN.1, mais la taille est très susceptible de dépendre des détails de vos types et les données réelles.

Je fortement vous recommandons de prototyper les deux et mettre un peu de données réelles pour comparer.

Si votre tampon de protocole contienne des types primitifs répétés, vous devriez regarder la dernière source Subversion pour Protocol Buffers - ils peuvent être représentés dans un format « emballé » maintenant qui est beaucoup plus efficace l'espace. (Mon port C # a juste rattrapés cette fonction, un peu de temps la semaine dernière.)

Answer 2

Si vous utilisez ASN.1 avec PER Unaligned et définir vos types de données en utilisant les contraintes appropriées (par exemple, en spécifiant les limites inférieures / supérieures pour les entiers, les limites supérieures pour la longueur des listes, etc.), vos encodages seront très compact. Là, dans le nombre minimum de bits nécessaires pour tenir sa plage autorisée de valeurs sera pas de bits gaspillés pour des choses comme l'alignement ou de remplissage entre les champs, et chaque champ sera codé. Par exemple, un champ de type ENTIER (1..8) est codé en 3 bits (1 = '000', 2 = '001', ..., 8 = '111'); et un choix de quatre alternatives occupera 2 bits (indiquant la variante choisie), plus les bits occupés par l'alternative choisie. ASN.1 a beaucoup d'autres caractéristiques intéressantes qui ont été utilisés avec succès dans de nombreuses normes publiées. Un exemple est le marqueur d'extension ( « ... »), qui, lorsqu'il est appliqué à SEQUENCE, CHOIX, ENUMERATED, et d'autres types, la compatibilité permet arriération et en avant entre les points d'extrémité d'application différentes versions de la spécification.

Answer 3

Lorsque la taille du message emballé / codé est important que vous devez également noter le fait que protobuf ne peut pas emballer les champs de repeated qui ne sont pas d'un primitive numeric type, lire pour plus d'informations.

Ceci est un problème par exemple si vous avez des messages de ce type: (commentaire définit gamme des valeurs)

message P{
    required sint32 x = 1; // -0x1ffff  to  0x20000
    required sint32 y = 2; // -0x1ffff  to  0x20000
    required sint32 z = 3; // -0x319c  to   0x3200
}
message Array{
    repeated P ps = 1;
    optional uint32 somemoredata = 2;
}

Si vous avez une longueur de tableau de, par exemple, 32 que vous entraînerait une taille de message emballé d'environ 250 à 450 octets avec protobuf, en fonction des valeurs que le tableau contient en fait. Cela peut même augmenter à plus de 1000 octets dans le cas où vous utilisez la gamme complète 32bit ou dans le cas où vous utilisez int32 au lieu de sint32 et ont des valeurs négatives.

Le blob de données brutes (en supposant que z peut être définie comme la valeur de int16) ne ferait que consommer 320 octets et donc le ASN.1 message est toujours inférieure à 320 octets étant donné que les valeurs maximales ne sont pas réellement 32 bits, mais 19bit (x, y) et 15 bits (z).

La taille du message protobuf peut être optimisé avec ce message définition:

message Ps{
    repeated sint32 xs = 1 [packed=true];
    repeated sint32 ys = 2 [packed=true];
    repeated sint32 zs = 3 [packed=true];
}
message Array{
    required Ps ps = 1;
    optional uint32 somemoredata = 2;
}

ce qui conduit à des tailles de messages entre environ 100 octets (toutes les valeurs sont des zéros), 300 octets (valeurs à portée max) et 500 octets (toutes les valeurs sont des valeurs 32 bits élevés).