¿Qué debo saber antes de diseñar mi propio protocolo de comunicación?

Como dice Tony Li, esto ya se ha hecho antes. Una y otra vez.

Había una vez algo llamado el “Protocolo de comunicaciones de Michigan”, que era un protocolo enmarcado (relativamente) simple con sumas de verificación (CRC-16, creo). Era un protocolo cliente-servidor como TCP en ese lado (el cliente) establecería hasta la conexión con otro. Creo que las longitudes de los paquetes se limitaron a 254 octetos. La mayoría de las implementaciones del lado del servidor se realizaron en sistemas operativos especiales que se ejecutan en máquinas con arquitectura PDP-11 (algunas con controladores de comunicaciones asíncronas especializadas capaces de manejar 8, 16, 32 o más puertos a la vez). Hubo versiones del lado del cliente para muchos 8 y CPU de 16 bits de la década de 1980. Apple] [s, MS-DOS, CP / M, TRS-DOS, varios sistemas operativos DEC.

Una variación llamada MCP2 permitió el paso de la información de control, así como los datos del usuario.

Kermit fue diseñado originalmente como un protocolo de transferencia de archivos. Hubo otros protocolos de transferencia de archivos diseñados para funcionar sobre RS-232, pero Kermit se destacó al trabajar con texto que podría sobrevivir a la traducción de códigos como ASCII a EBCDIC, y a través de interfaces de asincronización primitivas que limitaban el número de caracteres que podrían ser almacenados o utilizados de otra manera señalización en banda (como control de flujo X-ON / X-OFF).

Kermit negocia características, por lo que se debe implementar algún aspecto de la negociación de características (en particular, la parte donde se rechazan las características no implementadas).

Hay una versión de Kermit escrita en C llamada “C-Kermit”. Creo que está dirigido principalmente a * nix como los sistemas operativos. Kermit para otros sistemas operativos a menudo se escribía en ensamblador o en el lenguaje de programación de sistemas nativos del sistema operativo (como BLISS para VAX / VMS).

Si realmente necesita IP sobre comunicaciones asincrónicas, mire PPP. (SLFP y SLIP también son posibles).

RS-232 tiene 40 años y se ha implementado en prácticamente todas las plataformas producidas desde su inicio. Con una historia como esa, debes saber que, literalmente, todo lo que se puede hacer con él ya se ha hecho. Y en muchos casos, el mismo objetivo se ha logrado de múltiples maneras. Y logró alguna medida de estandarización. En múltiples plataformas y en múltiples lenguajes de programación. A menos que esto sea simplemente un ejercicio académico, utilice un estándar existente. Especialmente si esto se va a incrustar en un producto con el que alguien tendrá que comunicarse.

  • Que esto se ha hecho antes. Ver Kermit (protocolo)
  • Las ventanas correderas son tu amigo.
  • La detección de errores es esencial.