Como rápido ou leve Buffer de protocolo é?

Question

buffer de protocolo é para .NET vai ser leve / mais rápido do que Remoting (a SerializationFormat.Binary)? Haverá um suporte de primeira classe para ele em termos de linguagem / framework? ou seja, é tratada de forma transparente como com Remoting / WebServices?

Answer 1

Eu duvido muito que ele nunca vai ter suporte linguagem direta ou suporte quadro ainda. - É o tipo de coisa que é tratado perfeitamente com bibliotecas 3rd party

meu próprio porto do código Java é explícito - você tem que chamar métodos para serializar / desserializar. (Existem topos RPC que irá automaticamente serializar / desserializar, mas nenhuma implementação RPC ainda.)

fits projeto de

Marc Gravell em muito bem com o WCF embora - tanto quanto eu estou ciente, você só precisa dizer a ele (uma vez) para buffers uso de protocolo para serialização, eo resto é transparente.

Em termos de velocidade, você deve olhar para a página de referência da Marc Gravell . Meu código tende a ser um pouco mais rápido do que o seu, mas ambos são muito, muito mais rápido do que as outras opções de serialização / desserialização no quadro. Deve ser salientado que buffers de protocolo são muito mais limitados, bem como - eles não tentar serializar tipos arbitrários, apenas os suportados. Nós vamos tentar apoiar mais dos tipos de dados comuns (decimal, DateTime, etc.) de uma forma portátil (como seu próprio protocolo tampão mensagens) no futuro.

Answer 2

Algumas métricas de desempenho e tamanho estão em desta página . Não tenho estatísticas de Jon lá no momento, apenas porque a página é um pouco velho (Jon: precisamos consertar isso!)

.

Re ser transparente; protobuf-net pode ligar para WCF via do contrato; note que ele funciona muito bem com MTOM mais básico-http também. Isso não funciona com o Silverlight, porém, desde que o Silverlight não tem o ponto de injeção. Se você usar svcutil, você também precisa adicionar um atributo a classe (através de uma classe parcial).

Re BinaryFormatter (comunicação remota); sim, isso tem supprt completo; você pode fazer isso simplesmente uma implementação ISerializable trivial (ou seja, apenas chamar o método Serializer com os mesmos argumentos). Se você usar protogen para criar suas classes, então ele pode fazer isso por você: você pode ativar esse na linha de comando por meio de argumentos (que não está habilitado por padrão como BinaryFormatter não funciona em todos os enquadramentos [CF, etc]) .

Note que para objetos muito pequenos (instâncias individuais, etc.) sobre remoting local (IPC), o desempenho BinaryFormatter cru é realmente melhor - mas para não-trivial gráficos ou links remotos (comunicação remota de rede) podem protobuf-net realizar-se -lo muito bem.

Gostaria também de salientar que o formato de fio de buffers de protocolo faz herança não diretamente suporte; protobuf-net pode falsificar isso (mantendo wire-compatibilidade), mas como com XmlSerializer, você precisa declarar as sub-classes up-front.

---

Por que existem duas versões?

As alegrias de código aberto, eu acho ;-p Jon e eu temos trabalhado em projetos conjuntos antes, e discutiram a fusão destes dois, mas o fato é que eles têm como alvo dois cenários diferentes:

• dotnet-protobufs (Jon) é um porto da versão java existente . Isso significa que ele tem uma API muito familiar para qualquer pessoa que já utilizam a versão java, e é construído em construções java típicos (construtor de classes, classes de dados imutáveis, etc.) - com alguns C # torções
• protobuf-net (Marc) é uma sequência re-execução no terreno-up o mesmo formato binário (na verdade, um requisito fundamental é que você pode trocar dados entre diferentes formatos), mas usando expressões típicas NET:
  • classes de dados mutáveis ??(sem construtores)
  • as especificidades membro serialização são expressos em atributos (comparáveis ??ao XmlSerializer, DataContractSerializer, etc)

Se você está trabalhando em Java e .NET clientes, Jon é provavelmente uma boa escolha para a API familiares em ambos os lados. Se você é pura .NET, protobuf-net tem vantagens - o familiar API estilo .NET, mas também:

• você não é forçada ser contrato de primeira (embora você pode, e um gerador de código é fornecido)
• você pode reutilizar os objetos existentes (na verdade, [DataContract] e aulas [XmlType] muitas vezes pode ser usado sem qualquer alteração em tudo)
• tem o suporte completo para herança (que este atinja no fio por falsificação encapsulamento) (possivelmente única para uma aplicação de buffers de protocolo? Nota que sub-classes têm de ser declaradas previamente)
• ele sai do seu caminho para plugue e explorar ferramentas .NET centrais (BinaryFormatter, XmlSerializer, WCF, DataContractSerializer) - permitindo-lhe trabalhar diretamente como um mecanismo de comunicação remota. Este provavelmente seria bastante um grande divisão do tronco principal java para a porta de Jon.

Re fundi-las; Eu acho que nós dois estariam abertos a isso, mas parece improvável que você gostaria ambos os conjuntos de recursos, uma vez que eles têm como alvo tais requisitos diferentes.