design - que - Diseñando un protocolo de aplicación
protocolos de aplicación (8)
Tengo una aplicación independiente existente que va a ser extendida por una tercera parte, usando un protocolo de red.
Ayudaría saber un poco más sobre lo que hace su programa y cuál es la naturaleza de estas extensiones de terceros. Tal vez alguna razón para usar UDP?
Tengo una aplicación independiente existente que va a ser extendida por una tercera parte, usando 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 del software, pero no sobre el diseño del protocolo. Ya he analizado el diseño de protocolo de aplicación .
Otra recomendación para los búferes de protocolo : 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 de RPC acordado ( varios están en curso , tendiendo a inclinarse hacia TCP o HTTP).
La especificación hace que sea muy fácil tener el cliente y el servidor en diferentes arquitecturas , lo cual es bueno, además es extensible.
Advertencia: soy el autor de una de las versiones de .NET , por lo que puede ser parcial ;-p
Si elige XML, tenga en cuenta que tendrá una sobrecarga general de marcado.
Un simple protocolo binario también necesitará menos recursos para analizar en comparación con xml.
Si no desea construir su protocolo desde cero, debe echar un vistazo a SOAP . El soporte varía según los diferentes lenguajes de programación, pero se recomienda explícitamente la comunicación entre idiomas.
Desafortunadamente UDP y SOAP parecen haberse quedado en su infancia, HTTP es el más comúnmente utilizado.
Ver las pautas de diseño de los protocolos de Jabber y RFC 4101 . A pesar de que su objetivo es hacer que los RFC sean más fáciles de entender para los revisores, este RFC brinda algunos consejos interesantes.
Realmente debería pensar si realmente desea diseñar, documentar y mantener su propio protocolo o usar algo que ya existe. Es probable que ya haya un protocolo documentado que coincida con sus necesidades. Dependiendo de lo que esté haciendo, probablemente se vea excesivo al principio y la implementación de todas las especificaciones parecerá tediosa y mucho menos divertida que escribir la suya propia, pero si desea que su aplicación se desarrolle activamente en unos 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 tienes que vivir con todos los defectos. Ningún protocolo es perfecto, pero si nunca ha diseñado uno, puede estar seguro de que va a cometer más errores al diseñarlo que las personas que diseñaron el conocido protocolo existente que podría usar en su lugar.
En resumen, aproveche lo que ya existe siempre que sea posible.
En primer lugar, UDP es principalmente un método de transporte de transmisión de ida. Además, es potencialmente con pérdida , por lo que debe ser capaz de manejar los paquetes faltantes y paquetes fuera de orden. Si necesita cualquier nivel de confiabilidad de UDP, o requiere conexiones bidireccionales, terminará necesitando prácticamente todo, desde TCP, por lo que también debería ir con eso para empezar y dejar que la pila de red se encargue de eso.
A continuación, si sus datos son potencialmente más grandes que un paquete IP único, entonces 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 necesitas una forma de codificar los mensajes y las respuestas. Hay muchos protocolos RPC alrededor. Puede ver SOAP o diseñar un protocolo personalizado basado en XML o uno binario.
¿Has mirado el Buffer de Protocolo de Google ? Parece una buena manera 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 es necesario que escriba su propio administrador de protocolo, porque puede usar los Google. La desventaja es que debe implementarse en ambos lados del sistema (en su lado ''servidor'' y en el lado consumidor / cliente).