¿Cómo diseñaría un nuevo protocolo de red?

Answer 1

Como con todos los demás, miraría los requisitos. Como no tiene sentido reinventar la rueda (excepto cuando la rueda es un octágono morado), también me gustaría saber si podría superponer este nuevo protocolo sobre otro protocolo existente. Las características tienen que ser correctas para esto, no usaría IPv4 TCP si necesitara un campo de etiqueta más amplio, si la latencia iba a ser un problema o si esto debía ser multidifusión.

Una vez que eliminé todo lo que existe en un protocolo que puedo superponer, suponiendo que haya uno, podría comenzar a diseñar el protocolo en sí.

Aquí, depende de otras cualidades del protocolo. Si fuera a diseñar un protocolo en el que todos los comportamientos tuvieran que especificarse formalmente junto con todos los casos, estaría mirando Redes de Petri de colores y Máquinas de estado abstracto para modelar ese protocolo con el fin de demostrar que todos los casos se contabilizaron. La lógica de la pila de protocolos se escribiría en Z u otra notación formal, en tales casos, de modo que la lógica de la versión de referencia estuviera 100% garantizada correcta.

En la mayoría de los casos, no necesitas nada como ese nivel de formalismo. Incluso el CCITT / ITU nunca documentó nada más allá de la notación EBNF para los protocolos X.nnn. El protocolo del IETF desarrolla listas de correo que a veces entran en notación formal para denotar cambios de estado, pero honestamente no puedo recordar que alguna vez haya entrado en notación CPN o pruebas formales.

De acuerdo, hay que decir que algunos protocolos terminaron teniendo resultados inesperados (RSVP me viene a la mente) y el ático IETF parece estar bastante lleno, lo que el formalismo podría haber evitado. Dicho esto, los gastos generales a tiempo para un enfoque totalmente formal probablemente habrían excedido el tiempo dedicado a desarrollar un protocolo en las reuniones y reuniones del BOF en el pub más cercano.

También hay que decir que cuando diseñé el protocolo de red Lightfleet original, trabajé completamente de lo que sabía que funcionaba y lo que sabía que no funcionaba. Se necesitó una sesión de lluvia de ideas de 24 horas para lograr que todo se concretara (y una muy mala elección de contratación para que todo volviera a funcionar), pero allí las necesidades eran muy similares a las necesidades que ya existían, aunque en un momento muy difícil. diferente tipo de tela, por lo que solo era cuestión de ver lo que se hizo antes y copiar los principios básicos. El formalismo no habría agregado nada.

Answer 2

Como dice Tony Li, identifique la necesidad de diseñar un nuevo protocolo basado en los requisitos, y especialmente aquellos que no cumplen los protocolos existentes. Identifique por qué el (los) protocolo (s) de conexión no pueden cumplir el propósito y asegúrese de que lo que está proponiendo sea factible en el marco de las capas de la infraestructura de red que necesita para trabajar. Concéntrese en los aspectos específicos de los protocolos que se acercan pero no cumplen con sus requisitos, e identifique por qué se quedan cortos. Busque alguna limitación fundamental que deberá superar y determine si se puede hacer sin cruzar los límites de la capa en la que está trabajando.

Diseñar la interfaz de software para el protocolo; probablemente un lenguaje vinculante API. Diseñe el sistema de mensajería, identificando especialmente todas las formas en que el protocolo puede fallar y lo que deberá hacerse para manejar las fallas. Cada modo de falla individual. Cree o adquiera herramientas que puedan instrumentar su nuevo protocolo para ver y registrar cómo funciona y cómo no funciona. Identifique formas de ejercer el protocolo e introduzca errores que puedan usarse para evaluar qué tan bien el protocolo los maneja.

Answer 3

Comenzaría con los requisitos. Y muy específicamente, comenzaría con requisitos que los protocolos existentes no cumplen. Y luego pasaría a mirar el caso de negocios. Sin un caso de negocios, ya estás muerto.

Y luego, aplica la creatividad … 😉