Redirigir Datos de Puerto Serie a través de Telnet

En principio sí — RFC 2217 es un estándar publicado, por lo que SEC puede interoperar con implementaciones de terceros compatibles, incluidos servidores de consola/terminal de hardware de proveedores como Digi, Lantronix y Moxa que exponen la opción Telnet de control de puerto COM, y con endpoints de software como un servidor Linux ser2net/pySerial. Esa interoperabilidad es una de las razones para preferir el modo Telnet cuando se hace de puente con equipos que no son de SEC.

La aclaración honesta: siempre prueba en banco la combinación específica antes de confiar en ella. Las implementaciones difieren en qué comandos opcionales de RFC 2217 admiten y en qué tan estrictamente siguen la especificación, por lo que un determinado servidor de hardware podría manejar la negociación de velocidad en baudios pero no algún comando de línea de señal, o viceversa. Por lo general funciona — pero “es un estándar” no sustituye confirmar que tus dos dispositivos concretos coinciden en la práctica.

Respondido por Bohdan Miniv · Ingeniería de QA

Las señales de control de flujo se representan: RFC 2217 transporta el estado de las líneas de control (RTS/CTS y el modo de control de flujo) entre los extremos, por lo que el protocolo entiende el handshaking por hardware en lugar de ignorarlo como ocurre en el modo Raw. Para la configuración y para los dispositivos en los que el control de flujo depende de una configuración correcta, esto funciona.

La limitación es la capacidad de respuesta a través de una red. El control de flujo por hardware existe para ralentizar a un emisor rápido en el instante en que se llena el búfer de un receptor: una reacción en tiempo real medida en tiempos de carácter. A través de un enlace de red, el cambio de CTS tiene que regresar por TCP con su latencia y almacenamiento en búfer, por lo que puede no llegar lo bastante rápido como para evitar un desbordamiento en una transmisión de alto rendimiento. En una LAN de baja latencia suele estar bien; en internet, no confíe en el control de flujo por hardware remoto para evitar desbordamientos de búfer en un dispositivo rápido. Siempre que sea posible, deje que el control de flujo actúe localmente en el puerto físico y transporte solo los datos por el enlace.

Respondido por Nikolai Svarachevsky · Desarrollador principal

Porque RFC 2217 negocia y controla los parámetros del puerto para una sola sesión. El objetivo principal del modo Telnet es que un cliente conectado pueda establecer la velocidad en baudios, cambiar las líneas de señal y leer el estado del puerto, y no hay una forma coherente de que dos clientes tengan cada uno esa autoridad sobre un mismo puerto físico al mismo tiempo. Si dos clientes solicitaran distintas velocidades en baudios, ¿cuál prevalece? El protocolo no tiene respuesta, por lo que el modo se define como punto a punto.

Esa es exactamente la razón por la que existe el modo Raw para el caso de uno a muchos: Raw no controla los parámetros del puerto, solo bytes, por lo que puede duplicar de forma segura el flujo para muchos clientes. La contrapartida es la otra cara de la misma moneda: Raw te da múltiples clientes pero sin control remoto del puerto; Telnet te da control total del puerto pero un solo par. Elige el modo que coincida con si necesitas control o distribución.

Respondido por Nikolai Svarachevsky · Desarrollador principal

Porque RFC 2217 está definido como una opción sobre Telnet, que se ejecuta sobre TCP — y depende exactamente de las garantías que proporciona TCP. Los comandos de control del puerto (establecer baudios, establecer líneas de señal) se negocian en banda y dependen de que el flujo llegue de forma fiable, en orden, y de que ambos extremos puedan reconocerse mutuamente. Esa es una conversación orientada a conexión.

UDP no ofrece nada de eso: no hay conexión, no hay orden, no hay garantía de entrega, no hay acuse de recibo. Una negociación que asume una entrega fiable y ordenada simplemente no puede ejecutarse sobre un transporte que puede descartar o reordenar el mismo comando que establece la velocidad en baudios. Así que los dos modos se dividen claramente por transporte: la señalización RFC 2217 pertenece a TCP, y UDP es solo para datos sin procesar en un solo sentido. Si necesita control de señales/parámetros, está en TCP por necesidad.

Respondido por Nikolai Svarachevsky · Desarrollador principal