Manera optimizada para hacer RPC en .Net

Question

Estoy considerando mover partes de una aplicación .Net a otras computadoras. La forma obvia de hacerlo es simplemente usar WCF con un protocolo tcp binario, por ejemplo como descriptor en "Easiest way to get fast RPC with .NET?".

Voy a hacer una gran cantidad de llamadas y la latencia es un gran problema. Básicamente, una computadora ejecutará un simulador de física y las demás interactuarán con una API de varios cientos de comandos.

Estoy pensando que la mejor manera es hacer un protocolo binario personalizado donde los comandos API se identifiquen mediante int16 y un número de secuencia, y luego siga los parámetros requeridos. Cablear las clases de enviar y recibir eliminaría cualquier sobrecarga innecesaria.

Pero eso es MUCHO trabajo ya que estamos hablando de varios cientos de comandos API.

¿Alguna idea sobre la mejor manera de implementarla?

Edit: Para aclarar: la serialización de AFAIK en .Net no está optimizada. Hay una penalización relativamente alta al serializar y deserializar objetos en, por ejemplo, el uso interno de Reflection. Esto es algo de lo que quiero evitar, y de ahí mi pensamiento acerca de los métodos de mapeo directo (cableado).

Después de buscar encontré una aplicación que tenía un vago recuerdo de: http://www.protocol-builder.com/

Answer 1

La reducción del tráfico total (lo que sería el principal beneficio de un protocolo personalizado vs utilizando WCF) no va a tener un gran efecto sobre la latencia El problema principal sería mantener al mínimo la cantidad de datos para los "parámetros requeridos", por lo que cada solicitud es relativamente pequeña. La serialización predeterminada en WCF ya es bastante eficiente, especialmente cuando se usa TCP en una red local.

En un escenario como el que está describiendo, con muchos clientes conectados a un servidor centralizado, es poco probable que el transporte de los mensajes sea el cuello de botella; procesar los mensajes específicos será probablemente el cuello de botella y el transporte el mecanismo no importará tanto.

Personalmente, simplemente usaría WCF, y no me molestaría en intentar crear un protocolo personalizado. Si, una vez que lo tiene en ejecución, encuentra que tiene un problema, puede abstraer fácilmente el transporte a un protocolo personalizado en ese momento y asignarlo a las mismas interfaces. Esto requerirá muy poco código adicional frente a solo hacer una pila de protocolos personalizados por adelantado, y probablemente mantendrá el código mucho más limpio (ya que el protocolo personalizado se aislará en una sola asignación a la API "limpia"). Sin embargo, si encuentra que el transporte no es un cuello de botella, se habrá ahorrado una gran cantidad de trabajo y esfuerzo.