¿Impulsar la serialización frente a los buffers del protocolo de Google?[cerrado]

Question

¿Alguien con experiencia con estas bibliotecas tiene algún comentario sobre cuál prefirió?¿Hubo diferencias de rendimiento o dificultades de uso?

Answer 1

He jugado un poco con un poco de ambos sistemas, nada grave, sólo algunas cosas simples hacker, pero sentí que no hay una verdadera diferencia en la forma en que se supone que usar las bibliotecas.

Con impulso :: serialización, escribe su propio structs / clases de primero, y luego añadir los métodos de archivo, pero todavía se queda con algunas clases bonitas "delgado", que se puede utilizar como miembros de datos, heredado, lo .

Con búferes de protocolo, la cantidad de código generado para incluso una estructura simple es bastante sustancial, y las estructuras y el código que se genera es más significado para operar en, y que utiliza la funcionalidad de protocolo buffers' para transportar datos hacia y desde su estructuras internas propias.

Answer 2

He estado usando serialización Boost durante mucho tiempo y sólo se clavaron en búferes de protocolo, y creo que no tienen exactamente el mismo propósito. BS (no vio que viene) ataja el C ++ objetos a un arroyo, mientras que el PP es un formato de intercambio que lea a / de.

modelo de datos de PB es manera más sencilla: se obtiene todo tipo de INT y flotadores, cuerdas, matrices, estructura básica y que es prácticamente todo. BS le permite guardar directamente todos sus objetos en un solo paso.

Esto significa que con la norma BS obtener más datos sobre el alambre, pero que no tiene que reconstruir toda su estructura de objetos, mientras que los tampones protocolo es más compacto pero hay más trabajo por hacer después de leer el archivo. Como su nombre lo dice, uno es para protocolos (independiente del idioma, eficiente del espacio de paso de datos), el otro es para la serialización (objetos obviedad de ahorro).

Entonces, ¿qué es más importante para usted:? / Eficiencia del espacio velocidad o código limpio

Answer 3

Hay un par de preocupaciones adicionales con boost.serialization que voy a añadir a la mezcla. Advertencia:. No tengo ninguna experiencia directa con tampones de protocolo más allá de rozar los documentos

Tenga en cuenta que mientras pienso impulso, y boost.serialization, es grande en lo que hace, he llegado a la conclusión de que los formatos de archivo por defecto que viene con no son una gran opción para un formato de alambre.

Es importante distinguir entre las versiones de su clase (como se ha mencionado en otras respuestas, boost.serialization tiene algún apoyo para el control de versiones de datos) y la compatibilidad entre las diferentes versiones de la biblioteca de serialización .

Las nuevas versiones de boost.serialization no puede generar archivos que las versiones anteriores pueden deserializar (el contrario no es cierto: las versiones más recientes siempre están destinadas a deserializar archivos realizadas por las versiones anteriores).. Esto ha dado lugar a los siguientes problemas para nosotros:

• Tanto nuestro cliente y software de servidor crean objetos serializados que las otras consume, por lo que sólo pueden mover a una nueva boost.serialization si aumentamos el cliente y el servidor al mismo paso. (Esto es todo un reto en un entorno en el que no tiene el control total de sus clientes).
• Boost viene incluido como una biblioteca grande con partes compartidas, y tanto el código de serialización y las otras partes de la biblioteca de impulso (por ejemplo shared_ptr) puede estar en uso en el mismo archivo, no puedo actualizar cualquier partes de impulso porque no puedo actualizar boost.serialization. No estoy seguro de si es posible / seguro / cuerdo para intentar enlazar múltiples versiones de impulso en un solo ejecutable, o si tenemos el presupuesto / energía para refactorizar a cabo bits que necesitan permanecer en una versión anterior del impulso en una separada ejecutable (DLL en nuestro caso).
• La versión antigua de impulso que estamos atrapados en no soporta la última versión del compilador que utilizamos, por lo que estamos atrapados en una versión antigua del compilador también.

Google parece realmente publicar el formato de alambre de búferes de protocolo , y los describe como Wikipedia compatible hacia delante, compatible hacia atrás (aunque creo que Wikipedia se refiere a versiones datos en lugar de protocolo tampón biblioteca de versiones). Mientras que ninguno de ellos es una garantía de delanteros-compatibilidad, se parece como una indicación más fuerte para mí.

En resumen, Yo preferiría un formato de alambre conocido, publicado como búferes de protocolo cuando no tienen la capacidad de actualizar el cliente y servidor al mismo paso.

Nota al pie:. Descarado enchufe para una respuesta por mí

Answer 4

Boost serialización

• es una biblioteca para escribir datos en un flujo.
• no comprime los datos.
• no soporta las versiones de datos de forma automática.
• soporta contenedores STL.
• propiedades de los datos escritos dependen de corrientes elegidas (por ejemplo endian, comprimido).

búferes de protocolo

• genera código de descripción de la interfaz (soporta C ++, Python y Java por defecto. C, C # y otros por tercera parte).
• opcionalmente comprime los datos.
• se encarga de versiones de datos de forma automática.
• maneja el intercambio entre plataformas endian.
• no soporta contenedores STL.

serialización Boost es una biblioteca para convertir un objeto en una secuencia serializada de datos. Los tampones protocolo hacen lo mismo, sino que también lo hacen otros trabajos para usted (como el control de versiones e intercambio endian). serialización impulso es más simple para las "pequeñas tareas simples". Los tampones de protocolo son probablemente mejor para "infraestructura más grande".

EDIT: 24-11-10: Añadido "automáticamente" a versiones BS

.

Answer 5

No tengo ninguna experiencia con el impulso de serialización, pero he utilizado búferes de protocolo. Me gusta protocolo amortigua mucho. Mantenga en mente lo siguiente (lo digo con ningún conocimiento de impulso).

• búferes de protocolo son muy eficientes, así que no imagino que siendo un problema grave vs impulso.
• búferes de protocolo proporcionan una representación intermedia que trabaja con otros lenguajes (Python y Java ... y más en las obras). Si sabe que sólo está utilizando C ++, tal vez impulsar es mejor, pero la opción de utilizar otros idiomas es agradable.
• tampones protocolo son más como contenedores de datos ... no hay naturaleza orientada a objetos, tales como la herencia. Piense en la estructura de lo que desea realizar una serie.
• búferes de protocolo son flexibles porque se puede añadir campos "opcionales". Básicamente, esto significa que puede cambiar la estructura de búfer de protocolo sin romper la compatibilidad.

Espero que esto ayude.

Answer 6

boost.serialization sólo necesita el compilador de C ++ y le da un poco de azúcar sintaxis como

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

para guardar y cargar. Si C ++ es el único idioma que usa usted debe dar un tiro boost.serialization grave.

Me echó un vistazo rápido a Google búferes de protocolo. Por lo que veo yo diría que no es directamente comparable con boost.serialization. Usted tiene que agregar un compilador para los archivos .proto a su cadena de herramientas y mantener los archivos .proto sí. La API no se integra en C ++ como boost.serialization hace.

boost.serialization hace el trabajo diseñado para su muy bien: para serializar objetos C ++ :) Otoh una consulta de la API de Google como búferes de protocolo que se da más flexibilidad.

Dado que sólo se utiliza boost.serialization hasta ahora no puedo comentar sobre la comparación de rendimiento.

Answer 7

Corrección a la anterior (supongo que esto es que responder ) sobre serialización Boost:

Sí permite que los datos de apoyo de versiones .

Si necesita compresión -. Usan un flujo comprimido

Puede manejar el intercambio entre plataformas endian como la codificación puede ser texto, binario o XML.

Answer 8

Nunca he implementado nada utilizando la biblioteca de impulso, pero me encontré de Google protobuff a ser más pensada, y el código es mucho más limpio y más fácil de leer. Yo sugeriría echar un vistazo a los diferentes idiomas que desee utilizarlo con y tener una lectura a través del código y la documentación y tomar una decisión.

La única dificultad que tuve con protobufs fue que llamaron una función muy comúnmente utilizado en su GetMessage código generado (), que, por supuesto, entra en conflicto con la macro Win32 GetMessage.

Yo lo recomendaría altamente protobufs. Son muy útiles.

Answer 9

Como con casi todo en la ingeniería, mi respuesta es ... "depende".

Ambos son bien probado, tecnologías investigados. Ambos tendrán sus datos y convertirlo en algo agradable para el envío de algún lugar. Ambos probablemente será lo suficientemente rápido, y si realmente estás contando un byte aquí o allá, es probable que no va a ser feliz con cualquiera (seamos sinceros ambos paquetes creados serán una pequeña fracción de XML o JSON).

Para mí, lo que realmente se reduce a flujo de trabajo y si se necesita algo distinto de C ++ en el otro extremo.

Si desea averiguar el contenido de su mensaje y la primera está la construcción de un sistema desde cero, utilice Protocol Buffers. Se puede pensar en el mensaje de una manera abstracta y luego generar automáticamente el código en cualquier idioma que desee (3 ª Parte plugins están disponibles para casi todo). Además, me encuentro con la colaboración simplificada Protocol Buffers. Acabo de enviar a través de un archivo .proto y luego el otro equipo tiene una idea clara de lo que está siendo transferido los datos. Asimismo, no se impone nada en ellos. Si quieren utilizar Java, adelante!

Si ya he construido una clase en C ++ (y esto ha sucedido más de las veces) y quiero enviar esos datos a través del cable ahora, Boost serialización, obviamente, hace un montón de sentido (sobre todo cuando ya tengo un Boost la dependencia en otro lugar).

Answer 10

Puede utilizar impulso serialización en conjunción estrecha con sus objetos de dominio "reales", y serializar la jerarquía de objetos completa (herencia). Protobuf no es compatible con la herencia, por lo que tendrá que utilizar la agregación. Las personas opinan que Protobuf se debe utilizar para DTO (objetos de transferencia de datos), y no por sí mismos objetos de dominio de núcleo. He utilizado tanto impulso :: serialización y protobuf. El rendimiento de impulso :: serialización debe ser tomado en cuenta, podría ser una alternativa.

Answer 11

Sé que esta es una pregunta antigua ahora, ¡pero pensé en arrojar mis 2 peniques!

Con boost tienes la oportunidad de escribir alguna validación de datos en tus clases;Esto es bueno porque la definición de datos y las comprobaciones de validez están todas en un solo lugar.

Con GPB lo mejor que puede hacer es poner comentarios en el archivo .proto y esperar contra toda esperanza que quien lo esté usando lo lea, le preste atención e implemente las comprobaciones de validez por sí mismo.

No hace falta decir que esto es poco probable y poco confiable si depende de otra persona en el otro extremo de una red para hacerlo con el mismo vigor que uno mismo.Además, si las restricciones de validez cambian, es necesario planificar, coordinar y realizar múltiples cambios de código.

Por lo tanto, considero que GPB es inadecuado para desarrollos donde hay pocas oportunidades de reunirse y hablar regularmente con todos los miembros del equipo.

==EDITAR==

El tipo de cosas a las que me refiero es esto:

message Foo
{
    int32 bearing = 1;
}

Ahora, ¿quién puede decir cuál es el rango válido de bearing ¿es?Podemos tener

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

Pero eso depende de que alguien más lea esto y escriba el código.Por ejemplo, si lo edita y la restricción se convierte en:

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

usted depende completamente de que todos los que hayan usado este .proto actualicen su código.Eso es poco fiable y caro.

Al menos con la serialización de Boost estás distribuyendo una única clase de C++, y eso puede tener comprobaciones de validez de datos integradas.Si esas restricciones cambian, entonces nadie más necesitará hacer ningún trabajo más que asegurarse de que esté usando la misma versión del código fuente que usted.

Alternativa

Hay una alternativa:ASN.1.Esto es antiguo, pero tiene algunas cosas realmente útiles:

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

Tenga en cuenta la restricción.Entonces, cada vez que alguien consume este archivo .asn y genera código, termina con un código que lo verificará automáticamente. bearing está entre 0 y 359.Si actualiza el archivo .asn,

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

todo lo que necesitan hacer es recompilar.No se requieren otros cambios de código.

También puedes hacer:

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

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

Nota la <.Y también en la mayoría de las herramientas, rodamientoMin y rodamientoMax pueden aparecer como constantes en el código generado.Eso es extremadamente útil.

Las restricciones pueden ser bastante elaboradas:

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

Mire el Capítulo 13 en este PDF;es sorprendente lo que puedes hacer;

Las matrices también se pueden restringir:

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á pasado de moda, pero aún se desarrolla activamente, se usa ampliamente (su teléfono móvil lo usa mucho) y es mucho más flexible que la mayoría de las otras tecnologías de serialización.La única deficiencia que puedo ver es que no existe un generador de código decente para Python.Si está utilizando C/C++, C#, Java, ADA, entonces contará con una combinación de herramientas gratuitas (C/C++, ADA) y comerciales (C/C++, C#, JAVA).

Me gusta especialmente la amplia variedad de formatos de cable binarios y basados ​​en texto.Esto lo hace extremadamente conveniente en algunos proyectos.La lista de formatos de cable incluye actualmente:

• BER (binario)
• PER (binario, alineado y no alineado.Esto es ultra poco eficiente.Por ejemplo, y INTEGER restringido entre 0 y 15 ocupará sólo 4 bits En el alambre)
• REA
• DER (otro binario)
• XML (también XER)
• JSON (completamente nuevo, el soporte de herramientas aún está en desarrollo)

además de otros.

¿Ten en cuenta los dos últimos?Sí, puede definir estructuras de datos en ASN.1, generar código y emitir/consumir mensajes en XML y JSON.Nada mal para una tecnología que comenzó en la década de 1980.

El control de versiones se realiza de forma diferente a GPB.Puede permitir extensiones:

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

Esto significa que en una fecha posterior puedo agregar a Foo, y los sistemas más antiguos que tienen esta versión aún pueden funcionar (pero solo pueden acceder a la bearing campo).

Califico muy bien a ASN.1.Puede ser complicado lidiar con esto (las herramientas pueden costar dinero, el código generado no es necesariamente hermoso, etc.).Pero las limitaciones son una característica realmente fantástica que me ha ahorrado un montón de dolor de corazón una y otra vez.Hace que los desarrolladores se quejen mucho cuando los codificadores/decodificadores informan que han generado datos inútiles.

Otros enlaces:

• buena introducción
• Compilador C/C++ de código abierto
• Compilador de código abierto, ADA también AFAIK
• Comercial, bueno
• Comercial, bueno
• Pruébelo usted mismo en línea

Observaciones

Para compartir datos:

• Primeros enfoques del código (p. ej.Impulsar la serialización) lo restringen al idioma original (p. ej.C++), o obligarte a hacer mucho trabajo extra en otro idioma
• El esquema primero es mejor, pero
  • Muchos de estos dejan grandes vacíos en el contrato compartido (es decir,sin restricciones).GPB es molesto en este sentido, porque por lo demás es muy bueno.
  • Algunos tienen limitaciones (p. ej.XSD, JSON), pero sufren soporte de herramientas irregular.
  • Por ejemplo, xsd.exe de Microsoft ignora activamente las restricciones en los archivos xsd (la excusa de MS es realmente débil).XSD es bueno (desde el punto de vista de las restricciones), pero si no puedes confiar en que el otro use una buena herramienta XSD que las aplique, entonces el valor de XSD disminuye.
  • Los validadores JSON están bien, pero no hacen nada para ayudarle a formar el JSON en primer lugar y no se llaman automáticamente.No hay garantía de que alguien que le envíe un mensaje JSON lo haya pasado por un validador.Tienes que acordarte de validarlo tú mismo.
  • Todas las herramientas ASN.1 parecen implementar la verificación de restricciones.

Entonces, para mí, ASN.1 lo hace.Es el que tiene menos probabilidades de provocar que otra persona cometa un error, porque es el que tiene las características correctas y donde todas las herramientas aparentemente intentan implementar esas características por completo, y es lo suficientemente neutral en el lenguaje para la mayoría de los propósitos.

Para ser honesto, si GPB agregara un mecanismo de restricciones, ese sería el ganador.XSD está cerca, pero las herramientas son casi universalmente basura.Si hubiera generadores de código decentes de otros lenguajes, el esquema JSON sería bastante bueno.

Si GPB tuviera restricciones agregadas (nota:esto no cambiaría ninguno de los formatos de cable), ese sería el que recomendaría a todos para casi cualquier propósito.Aunque el uPER de ASN.1 es muy útil para enlaces de radio.