c# - protobuf - what is protocol buffers

¿Qué tan rápido o liviano es el Protocolo Buffer?

Question

¿El protocolo Buffer para .NET va a ser liviano / más rápido que Remoting (SerializationFormat.Binary)? ¿Habrá un soporte de primera clase en términos de lenguaje / marco? es decir, ¿se maneja de forma transparente como con Remoting / WebServices?

Answer 1

Dudo mucho que alguna vez tenga soporte de lenguaje directo o incluso soporte de marco: es el tipo de cosa que se maneja perfectamente bien con bibliotecas de terceros.

Mi propio puerto del código de Java es explícito: debes llamar a los métodos para serializar / deserializar. (Hay trozos de RPC que se serializarán / deserializarán automáticamente, pero todavía no hay implementación de RPC).

Sin embargo, el proyecto de Marc Gravell encaja muy bien con WCF; por lo que yo sé, solo necesitas decir (una vez) que utilice los búferes de protocolo para la serialización, y el resto es transparente.

En términos de velocidad, debería mirar la página de referencia de Marc Gravell . Mi código tiende a ser ligeramente más rápido que el suyo, pero ambos son mucho, mucho más rápidos que las otras opciones de serialización / deserialización en el marco. Debe señalarse que los búferes de protocolo también son mucho más limitados: no intentan serializar tipos arbitrarios, solo los admitidos. Vamos a tratar de admitir más tipos de datos comunes (decimal, DateTime, etc.) de forma portátil (como sus propios mensajes de buffer de protocolo) en el futuro.

Answer 2

Algunas medidas de rendimiento y tamaño se encuentran en esta página . No tengo las estadísticas de Jon allí en este momento, solo porque la página está un poco vieja (Jon: ¡tenemos que arreglar eso!).

Re ser transparente; protobuf-net puede engancharse en WCF a través del contrato; tenga en cuenta que también funciona bien con MTOM sobre basic-http. Sin embargo, esto no funciona con Silverlight, ya que Silverlight carece del punto de inyección. Si usa svcutil, también necesita agregar un atributo a la clase (a través de una clase parcial).

Re BinaryFormatter (remoto); sí, esto tiene soporte completo; usted puede hacer esto simplemente mediante una implementación trivial ISerializable (es decir, simplemente llame al método Serializer con los mismos argumentos). Si usa protogen para crear sus clases, puede hacerlo por usted: puede habilitar esto en la línea de comando a través de argumentos (no está habilitado por defecto ya que BinaryFormatter no funciona en todos los marcos [CF, etc.]) .

Tenga en cuenta que para objetos muy pequeños (instancias únicas, etc.) en comunicación remota local (IPC), el rendimiento de BinaryFormatter sin BinaryFormatter es realmente mejor, pero para gráficos no triviales o enlaces remotos (conexión remota a la red), protobuf-net puede superarlo bastante bien .

También debería tener en cuenta que el protocolo de buffers no admite directamente la herencia; protobuf-net puede falsificar esto (aunque conserva la compatibilidad con cables), pero al igual que con XmlSerializer, debe declarar las subclases por adelantado.

¿Por qué hay dos versiones?

Las alegrías de la fuente abierta, supongo ;-p Jon y yo hemos trabajado anteriormente en proyectos conjuntos, y hemos discutido la fusión de estos dos, pero el hecho es que apuntan a dos escenarios diferentes:

• dotnet-protobufs (Jon''s) es un puerto de la versión java existente. Esto significa que tiene una API muy familiar para cualquiera que ya esté usando la versión java, y está construida sobre construcciones java típicas (clases de compiladores, clases de datos inmutables, etc.) con algunos giros C #.
• protobuf-net (Marc''s) es una reimplementación básica que sigue el mismo formato binario (de hecho, un requisito fundamental es que se pueden intercambiar datos entre diferentes formatos), pero usando expresiones idiomáticas .NET típicas:
  • clases de datos mutables (sin constructores)
  • las características específicas del miembro de serialización se expresan en atributos (comparable a XmlSerializer , DataContractSerializer , etc.)

Si está trabajando en clientes .NET y java, Jon es probablemente una buena opción para la API familiar en ambos lados. Si eres .NET puro, protobuf-net tiene ventajas: la API familiar estilo .NET, pero también:

• no está obligado a ser contratado por primera vez (aunque puede hacerlo, y se suministra un generador de código)
• puede volver a utilizar sus objetos existentes (de hecho, las clases [DataContract] y [XmlType] menudo se pueden usar sin ningún cambio)
• tiene soporte completo para la herencia (que se logra en el cable mediante la suplantación de la encapsulación) (¿posiblemente solo para una implementación de búferes de protocolo? tenga en cuenta que las subclases deben declararse de antemano)
• hace todo lo posible para conectarse y explotar las herramientas core .NET ( BinaryFormatter , XmlSerializer , WCF, DataContractSerializer ), lo que le permite funcionar directamente como un motor remoto. Supuestamente, esta sería una división bastante grande del tronco principal de Java para el puerto de Jon.

Re fusionándolos; Creo que los dos estaríamos abiertos a esto, pero parece poco probable que desee ambos conjuntos de características, ya que se dirigen a requisitos tan diferentes.