Diseño de un protocolo de aplicación [cerrado]

Question

Tengo una aplicación independiente existente que será extendida por un tercero, utilizando un protocolo de red. Las capacidades ya están implementadas, todo lo que necesito es exponerlas al exterior.

Suponiendo que el protocolo de transporte ya está elegido (UDP), ¿hay algún recurso que me ayude a diseñar mi protocolo de aplicación?

Parece que hay mucha información sobre el diseño de software, pero no sobre el diseño del protocolo. Ya he visto Diseño del protocolo de aplicación .

Answer 1

Consulte Pautas de diseño de protocolos Jabber y RFC 4101 . Aunque su objetivo es hacer que los RFC sean más fáciles de entender para los revisores, este RFC ofrece algunos consejos interesantes.

Answer 2

¿Ha visto Google Protocol Buffer ? Parece una buena forma de resolver este problema.

Puede crear un punto final que se comunique con su aplicación existente y luego responda desde 'afuera' usando el protocolo protobuffer. Es binario, por lo que es pequeño y rápido y no tiene que escribir su propio administrador de protocolos, porque puede usar los de Google. La desventaja es que debe implementarse en ambos lados del sistema (en el lado del 'servidor' y en el lado del consumidor / cliente).

Answer 3

Otra recomendación para búferes de protocolo : un buen binario ajustado con poco esfuerzo. Sin embargo, tenga en cuenta que, si bien el protocolo binario está bien definido, aún no existe un estándar RPC acordado ( varios están en progreso , tienden a inclinarse hacia TCP o HTTP).

La especificación hace que sea muy fácil tener el cliente y el servidor en arquitecturas diferentes , que es bueno, además es extensible.

Advertencia: soy el autor de una de las versiones .NET , así que bien puedo estar sesgado ;-p

Answer 4

Primero, UDP es principalmente un método de transporte de difusión unidireccional. Además, es potencialmente con pérdidas , por lo que debe ser capaz de manejar los paquetes faltantes y los paquetes fuera de servicio. Si necesita algún nivel de confiabilidad de UDP, o requiere conexiones bidireccionales, terminará necesitando casi todo de TCP, por lo que también podría comenzar con eso y dejar que la pila de red se encargue de ello.

A continuación, si sus datos son potencialmente más grandes que un solo paquete IP, necesitará alguna forma de identificar el inicio y el final de cada paquete, y un medio para manejar paquetes ilegales o corruptos. Recomendaría algún tipo de encabezado con longitud de paquete, algún tipo de pie de página y tal vez una suma de comprobación.

Entonces necesita alguna forma de codificar los mensajes y las respuestas. Hay muchos protocolos RPC alrededor. Puede mirar SOAP o diseñar un protocolo personalizado basado en XML o uno binario.

Answer 5

Realmente debería pensar mucho si realmente desea diseñar, documentar y mantener su propio protocolo o utilizar algo que ya existe. Es probable que ya exista un protocolo documentado que coincida con sus necesidades. Dependiendo de lo que esté haciendo, al principio parecerá excesivo e implementar todas las especificaciones parecerá tedioso y mucho menos divertido que escribir el suyo propio, pero si tiene la intención de que su aplicación aún se desarrolle activamente en unos pocos años, debería ahorrarle mucho tiempo y dinero para usar algo que ya existe y que es conocido por terceros. Además, si puede usar una biblioteca existente para ese protocolo, la parte de implementación debería ser mucho más rápida.

Diseñar un nuevo protocolo es más divertido que implementar uno, pero menos que mantener uno, ya que tiene que vivir con todos los defectos. Ningún protocolo es perfecto, pero si nunca ha diseñado uno, puede estar seguro de que cometerá más errores al diseñarlo que las personas que diseñaron el conocido protocolo existente que podría utilizar en su lugar.

En resumen, aproveche lo que ya existe siempre que sea posible.

Answer 6

Si no desea construir su protocolo desde cero, debería echar un vistazo a JABÓN . El soporte varía para diferentes lenguajes de programación, pero se recomienda explícitamente la comunicación entre idiomas.

Desafortunadamente, UDP y SOAP parecen haberse estancado en su infancia, HTTP se usa con mayor frecuencia.

Answer 7

Si elige XML, tenga en cuenta que tendrá una sobrecarga gigante de marcado.

Un protocolo binario simple también necesitará no tantos recursos para analizar en comparación con xml.

Answer 8

  

Tengo una aplicación independiente existente que será extendida por un tercero, utilizando un protocolo de red.

Sería útil saber un poco más sobre lo que hace su programa y cuál es la naturaleza de estas extensiones de terceros. ¿Quizás alguna razón para usar UDP?