Eso depende de la capa a la que esté apuntando. Escribir una alternativa a IP requeriría mucho trabajo de fontanería en el núcleo de al menos un sistema operativo. Escribir una alternativa a TCP y UDP sería más fácil (hay un par de otros, como SCTP, por lo que si intenta agregar su nuevo protocolo a Linux o un BSD, tendrá algunos andamios para trabajar).
Escribir un protocolo de capa de aplicación, como HTTP, es mucho más fácil, ya que puede permanecer en el espacio de usuario. En este nivel, un protocolo es solo una descripción de cómo un cliente y un servidor se comunican entre sí, y usted lo implementa escribiendo un cliente y un servidor que lo usan. Siendo realistas, muchos protocolos evolucionan con los programas que los usan, siendo la descripción del protocolo documentación posterior más que un diseño inicial.
Como ejemplo, escribí un truco bastante horrible a principios de este año: un módulo NSS y un pequeño servidor para FreeBSD. NSS es un sistema para convertir entre los nombres de usuario / grupo y sus ID numéricos, por lo que el módulo tiene funciones para responder preguntas como “¿conoce este nombre de usuario y, de ser así, cuál es la ID correspondiente”? Necesitaba que permanecieran sincronizados entre un host y una VM, así que escribí un módulo que reenvía estas preguntas a través de TCP a un servidor. El protocolo fue, con mucho, la parte más fácil de todo el proyecto. Básicamente, el cliente envía un byte que identifica la pregunta, seguido de algunos datos específicos de la pregunta (por ejemplo, una longitud de cadena de 16 bits seguida de una cadena), y el servidor responde con un byte de estado (por ejemplo, 0 = no encontrado, 1 = ok) y algunos datos de preguntas específicas (por ejemplo, un número de 32 bits).
- ¿Por qué los paquetes UDP se pierden en Internet?
- ¿Quién decide si usar TCP o UDP?
- ¿Cómo puede ver una transmisión de paquetes en una red?
- Cómo conectar dos redes (asignando IP)
- ¿Se puede rastrear un teléfono usando una dirección MAC o IP?
Este es un protocolo binario bastante “ajustado”: espera que funcione una serie muy específica de bytes, y si de alguna manera pierde la sincronización (por ejemplo, al estar desconectado por uno en la longitud de su cadena, no es que haya hecho eso * tos * ) no se recuperará. Aún así, la implementación completa es un par de funciones C cortas y una lista de números mágicos.
La alternativa es escribir algo un poco más basado en texto y hablador, más como SMTP o HTTP. En ese estilo, el cliente / servidor se comunica enviando comandos e información como texto (más o menos legible). Esto puede darle un poco más de margen de maniobra en el análisis y es mucho más fácil de depurar; en el peor de los casos, puede hacer telnet en su servidor y hablar con usted mismo. Si hubiera estado escribiendo en un idioma con un manejo agradable de las cadenas, probablemente habría seguido esa ruta. (Me gusta C, pero no lo suficiente como para disfrutar de analizar cadenas en él).
