Cómo Compartir Dispositivos Serie por la Red

Sí, cuando el puerto compartido es una conexión de servidor en modo Raw, permite múltiples clientes, y cada cliente conectado recibe una copia de la salida del dispositivo. Esto es ideal para un dispositivo que emite datos a muchos consumidores (un receptor GPS, una fuente de sensores). Ten en cuenta que el modo Telnet (RFC 2217) es punto a punto — un cliente a la vez — porque el control del puerto por sesión no se puede compartir, por lo que compartir entre varios clientes implica usar el modo Raw y renunciar a la negociación remota de velocidad/señales.

Un límite importante: muchas computadoras pueden leer con seguridad un dispositivo, pero que muchas computadoras escriban comandos a un dispositivo no es seguro. Una línea serie no tiene arbitraje multimaestro, por lo que los comandos superpuestos de distintos clientes se entremezclan en bytes corruptos en el único puerto físico. Distribución a muchos lectores, sí; múltiples escritores sin control, no — arbitra los comandos a través de un único cliente controlador si el dispositivo es de comando/respuesta.

Respondido por Nikolai Svarachevsky · Desarrollador principal

No — y vale la pena dejarlo claro porque es una suposición común. SEC es un reenviador transparente de bytes, no un convertidor de protocolos. Los bytes que entran por el puerto serie salen por el puerto virtual sin cambios; Modbus RTU sigue siendo Modbus RTU. Tu aplicación en el extremo remoto sigue hablando exactamente el protocolo serie que habla el dispositivo — SEC simplemente transporta esa conversación a través de la red.

Si realmente necesitas que el encapsulado RTU se reempaquete en Modbus TCP (encapsulado diferente, sin CRC, un encabezado de transacción TCP adecuado), eso es traducción de protocolos, y en su lugar necesitas una pasarela Modbus dedicada. SEC encaja cuando ambos extremos ya hablan el mismo protocolo serie, y solo necesitas moverlo a través de una red. "Acceder al dispositivo de forma remota" es lo que hacemos; "cambiar lo que habla el dispositivo" no lo es.

Respondido por Nikolai Svarachevsky · Desarrollador principal

La propia capa de software añade poco — generalmente una pequeña sobrecarga de menos de 10 ms en condiciones locales normales. Pero no daremos una única cifra universal, porque el valor que importa está dominado por su red, no por el SEC: en una LAN, la latencia total añadida es mínima; a través de internet o una VPN, el coste real es el viaje de ida y vuelta de la red, y puede variar desde unos pocos milisegundos hasta cientos, según la distancia y la congestión.

El ancho de banda prácticamente nunca es el cuello de botella — las velocidades de datos serie son diminutas en comparación con cualquier red moderna. La latencia es el aspecto para el que hay que diseñar. Si su protocolo lo tolera (streaming, sondeo flexible), nunca lo notará. Si impone ventanas de respuesta ajustadas, mida el viaje real de ida y vuelta en su ruta real antes de comprometerse, y recuerde que los controles de búfer de SEC intercambian un poco de latencia añadida por un enmarcado más limpio cuando lo necesita.

Respondido por Bohdan Miniv · Ingeniería de QA

Sí. La configuración de conexión de SEC incluye controles de paquetización precisamente para esto, incluida una opción de "enviar datos cuando se recibe un carácter con un código determinado". Ajústela al byte de fin de mensaje de su protocolo (un retorno de carro o un salto de línea para ASCII orientado a líneas, por ejemplo) y SEC acumulará los bytes entrantes y los enviará a la red como una sola unidad cuando llegue ese delimitador, en lugar de reenviar los bytes por partes.

Esto es realmente útil para mantener intacta la delimitación de mensajes a través de una red que, de otro modo, dividiría o combinaría un flujo de bytes, y se complementa con los controles relacionados: retener durante un tiempo determinado o enviar una vez que un bloque alcance un tamaño dado. La contrapartida que debe tener en cuenta: cualquier regla de "esperar hasta que…" añade un poco de latencia por diseño, ya que está reteniendo deliberadamente los bytes hasta que se produzca el desencadenante. Para la mayoría de los protocolos con delimitación, ese es exactamente el comportamiento que desea.

Respondido por Nikolai Svarachevsky · Desarrollador principal

El requisito mínimo es simple: instale SEC en la máquina que tiene el puerto serie que desea compartir. Ese lado publica el puerto a través de la red, y el otro extremo puede comunicarse con él como una conexión de red normal; si su aplicación remota puede abrir por sí misma un socket TCP sin formato, se conecta directamente y no necesita SEC instalado. Ese extremo remoto incluso podría ser un dispositivo de hardware (un terminal o servidor de consola) que ya habla el protocolo a través de la red.

Solo necesita SEC en ambos extremos cuando ambos extremos tienen que presentar un puerto COM real a su software local. En ese caso, cada nodo ejecuta SEC para exponer el puerto localmente y SEC transporta los datos entre ellos. En pocas palabras: instale SEC en cada nodo donde una aplicación espere ver un puerto COM, y omítalo en cualquier lugar donde el software ya hable TCP directamente, o donde el extremo sea hardware.

Respondido por Nikolai Svarachevsky · Desarrollador principal