Mejores prácticas de comunicación serie

Sugeriría algunos principios que, si bien no son obligatorios, pueden ahorrarle algo de dolor:

• Defina su protocolo de tal manera que cada vez que se vea una secuencia de bytes en particular, marcará el comienzo de un paquete, sin excepciones. En todo su código de recepción, observe esa secuencia, independientemente de cualquier otra cosa que pueda estar ocurriendo.

• Tener una secuencia de bytes que siempre indique "inicio de paquete" generalmente hará que sea necesario "escapar" a los datos que naturalmente podrían contener esa secuencia de bytes. No es necesario hacer nada absurdamente complicado en el diseño de la lógica de la secuencia de escape, pero puede ser conveniente ponerle un límite al rendimiento en el peor de los casos. Por ejemplo, si uno utiliza la secuencia de caracteres ~ S (7E 53) para indicar el inicio del paquete y reemplaza cualquier tildes que ocurrieron dentro del flujo de datos con ~ T (7E 54), eso funcionaría, pero los flujos de datos que contenían muchos Tildes casi podría duplicar en longitud. Uno podría limitar el comportamiento del caso más desfavorable al 50% de crecimiento reemplazando todas las ocurrencias de dos tildes consecutivos en el flujo de datos con ~ D. Tenga en cuenta que recomendaría contra lo que considero la práctica generalizada de duplicar el carácter de escape para que se indique. Si ~ S indicó el inicio del paquete y ~~ era una tilde literal, el código que recibió la secuencia ~~ S no sería capaz de decir si era una tilde escapada seguida de una S, o si era una tilde de un paquete truncado seguido por un indicador de inicio de paquete.

• Solo un lado de la comunicación debe preocuparse por el tiempo, y cada mensaje de ese lado debe producir una respuesta por parte del otro. Si el maestro le pide información al esclavo y el esclavo la envía, el esclavo no debe preocuparse por si el maestro la recibe; Si el maestro no vuelve a obtener la información, debe volver a solicitarla. Si el maestro no vuelve a solicitar la información, el esclavo debe darse cuenta de que no necesita volver a enviarla.

• Si es posible, el protocolo debe diseñarse de modo que enviar un comando varias veces tenga el mismo efecto que enviarlo una vez. Esto puede requerir agregar números de secuencia a los comandos o dividir los comandos en varias partes.

• Tenga en cuenta el medio a través del cual se enviarán los datos. Algunos medios de comunicación (incluidos algunos enlaces de radio) pueden garantizar bastante bien que, si se envía algo y no se recibe en poco tiempo, nunca se recibirá. Otros medios (por ejemplo, sockets TCP, o algunos otros enlaces de radio) no ofrecen tal promesa. Si una conexión TCP permanece abierta, todos los datos se recibirán en el orden enviado, aunque quizás con algún retraso; algunos enlaces de radio "enredados" pueden intentar enviar mensajes durante un período de segundos, y los mensajes que se envían a través de diferentes rutas pueden llegar fuera de secuencia.

• Casi siempre incluyo un comando "echo" en los protocolos que diseño. Una cosa así es simple, y no solo puede ser una herramienta de diagnóstico útil para identificar si "algo" está funcionando, sino que la capacidad de enviar un comando de eco con una carga aleatoria y escuchar la respuesta es muy útil con cosas como Conexiones TCP que pueden tener retrasos significativos (si el maestro envía una carga útil aleatoria y recupera la misma carga útil, puede estar seguro de que mientras reciba una respuesta a cada comando, cada respuesta será una respuesta al comando que precedió inmediatamente eso). A falta de tal sincronización, uno puede terminar en una situación en la que después de enviar cada comando, uno confunda malinterpreta la respuesta del comando anterior como respuesta al último.