¿Qué tan rápido o liviano es el buffer de protocolo?

Question

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

Answer 1

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

Mi propio puerto del código Java es explícito: debe llame a métodos para serializar / deserializar. (Hay apéndices RPC que se serializarán / deserializarán automáticamente, pero aún no hay implementación RPC).

El proyecto de Marc Gravell encaja muy bien con WCF aunque, por lo que a mí respecta Estoy consciente, solo necesita decirle (una vez) que use buffers de protocolo para la serialización, y el resto es transparente.

En términos de velocidad, debe consultar la página de referencia de Marc Gravell . Mi código tiende a ser un poco 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. Cabe señalar que los búferes de protocolo también son mucho más limitados: no intentan serializar tipos arbitrarios, solo los compatibles. 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 métricas 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 es un poco vieja (Jon: ¡debemos arreglar eso!).

Re ser transparente; protobuf-net puede conectarse a 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 (remoting); sí, esto tiene soporte completo; puede hacerlo 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 habilitarlo en la línea de comandos mediante argumentos (no está habilitado de forma predeterminada como BinaryFormatter no funciona en todos los marcos [CF, etc.]).

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

También debo tener en cuenta que el formato de cable de las memorias intermedias de protocolo no admite directamente la herencia; protobuf-net puede suplantar esto (mientras 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 del código abierto, supongo ;-p Jon y yo hemos trabajado en proyectos conjuntos antes, 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 de Java, y está construida sobre construcciones típicas de Java (clases de construcción, clases de datos inmutables, etc.), con algunos giros de C #.
• protobuf-net (Marc's) es una nueva implementación desde cero el mismo formato binario (de hecho, un requisito crítico es que puede intercambiar datos entre diferentes formatos), pero utilizando expresiones idiomáticas típicas de .NET:
  • clases de datos mutables (sin constructores)
  • los detalles del miembro de serialización se expresan en atributos (comparables a XmlSerializer , DataContractSerializer , etc.)

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

• no está obligado a ser el primero del contrato (aunque puede hacerlo, y se suministra un generador de código)
• puede reutilizar sus objetos existentes (de hecho, las clases [DataContract] y [XmlType] a menudo se pueden usar sin ningún cambio)
• tiene soporte completo para la herencia (que logra en el cable mediante la suplantación de encapsulación) (posiblemente único para una implementación de búferes de protocolo? tenga en cuenta que las subclases deben declararse por adelantado)
• hace todo lo posible para conectarse y explotar las herramientas principales de .NET ( BinaryFormatter , XmlSerializer , WCF, DataContractSerializer ) - permitiendo para que funcione directamente como un motor remoto. Presumiblemente, esto sería una gran separación del tronco principal de Java para el puerto de Jon.

Re fusionarlos; Creo que ambos estaríamos abiertos a él, pero parece poco probable que desee ambos conjuntos de funciones, ya que se dirigen a requisitos tan diferentes.