Transferencia de Datos Serie a la Nube

Sí, pero con una advertencia real que debes tener en cuenta en el diseño. Un puerto COM físico es de apertura exclusiva: un proceso a la vez, por lo que una aplicación local y la nube no pueden mantener directamente el mismo puerto real al mismo tiempo. El patrón viable es un par de puertos virtuales en la máquina local: la aplicación local se comunica con un puerto virtual, SEC hace de puente hacia el puerto real, y la conexión en la nube comparte esos mismos datos puenteados.

La advertencia sincera: una vez que tanto una aplicación local como una aplicación en la nube están conectadas a un dispositivo, su tráfico puede mezclarse. Los datos entrantes del dispositivo se distribuyen a ambos consumidores (bien para solo lectura), pero si ambos lados envían comandos, esos comandos se intercalan en la única UART física y se corrompen entre sí. Así que tener "local y nube a la vez" es seguro para lectura compartida; para enviar comandos al dispositivo, asegúrate de que solo un lado escriba a la vez.

Respondido por Nikolai Svarachevsky · Desarrollador principal

Sí — esta es una topología fan-in y funciona bien. En la máquina en la nube se crea un puerto COM virtual por fuente, cada uno alimentado por una conexión de cliente que marca desde su sitio correspondiente (o por servidores en cada sitio a los que la nube se conecta hacia fuera — los tipos de conexión son intercambiables). Su aplicación en la nube verá entonces un puerto COM independiente y limpio para cada dispositivo remoto.

La regla de diseño que mantiene esto razonable: dé a cada fuente su propio puerto virtual en lugar de combinar varios dispositivos en un solo puerto. Si canaliza varios dispositivos en un único puerto, sus bytes llegan entremezclados sin forma de saber cuál provino de cuál. Un puerto por dispositivo remoto — y recuerde que el enlace de cada sitio tiene su propia latencia de internet, así que ajuste los tiempos de espera por fuente, no basándose en una sola suposición.

Respondido por Nikolai Svarachevsky · Desarrollador principal

El rendimiento casi nunca se ve afectado de una manera que notarías, porque las velocidades de datos en serie son minúsculas en comparación con el ancho de banda de la red — incluso un enlace serie rápido es un hilo de agua al lado de una conexión normal a internet, por lo que SEC no está limitado por el ancho de banda. Lo que SEC y la red añaden es latencia, no un límite de rendimiento: una pequeña sobrecarga de software más el tiempo de ida y vuelta de la ruta hacia la nube.

Para una transferencia continua o masiva, esa latencia es un retraso único de la canalización y el rendimiento efectivo se mantiene alto. Donde se hace notar es en el tráfico conversacional de solicitud/respuesta, donde cada intercambio paga el viaje de ida y vuelta y la tasa efectiva cae aunque el ancho de banda bruto sea amplio. Si ese es tu patrón en una ruta larga hacia la nube, reduce el número de viajes de ida y vuelta (agrupa solicitudes, mantén un sondeador local al dispositivo) en lugar de esperar que SEC acelere el enlace.

Respondido por Bohdan Miniv · Ingeniería de QA

El estado de las líneas de señal se transmite cuando usas el modo Telnet (RFC 2217): los cambios de RTS/DTR de la aplicación remota se transmiten y se aplican en el puerto físico, y los estados de línea como CTS/DSR/DCD se informan de vuelta. En modo Raw no se transmite nada de esto: Raw solo mueve datos. Así que para el control de señales, usa el modo Telnet.

El límite real es la temporización, no la capacidad. RFC 2217 transporta los cambios de las líneas de control en banda y sincronizados de forma flexible con el flujo de datos, por lo que a través de un enlace en la nube con almacenamiento en búfer y latencia de internet, el momento exacto en que una línea cambia con respecto a los datos no es determinista. Para señales de estado y configuración, eso está bien. Para usos en tiempo real — conmutación de dirección RS-485 semidúplex controlada por software, o BREAK con temporización precisa — no controles la línea de forma remota a través de internet; gestiona esa temporización localmente en el dispositivo y usa el enlace en la nube solo para los datos.

Respondido por Nikolai Svarachevsky · Desarrollador principal

Sí. En el modo Raw, SEC tiene una pestaña Signal Lines donde puedes configurar qué líneas de señal se activan o desactivan al conectarse, de modo que puedes hacer que una línea se active cuando un cliente de red se conecta y se desactive cuando se desconecta. Eso es exactamente el indicador de "ahora hay un cliente remoto conectado" que estás describiendo, y es una configuración compatible en lugar de algo que tengas que improvisar.

Vale la pena entender la diferencia con el modo Telnet: allí, SEC refleja los estados reales de las líneas de hardware entre ambos extremos, por lo que las líneas siguen al dispositivo en lugar de a la conexión. El comportamiento configurable de las líneas al conectar/desconectar es una función del modo Raw. Configura las líneas específicas y sus estados al conectar / al desconectar en esa pestaña; si tu línea de destino o polaridad no está entre las opciones, describe el objetivo exacto al soporte y confirmaremos lo que permite la compilación actual.

Respondido por Bohdan Miniv · Ingeniería de QA

SEC tiene una configuración de keep-alive que maneja exactamente esto. Comprueba periódicamente que el enlace siga activo, de modo que una conexión que se haya caído silenciosamente se detecte y se cierre en lugar de quedarse ahí aparentando estar activa. Al ajustar el tiempo de keep-alive controlas con qué atención SEC supervisa el enlace: intervalos más cortos detectan una caída más rápido, los más largos son más flexibles.

La razón por la que esto importa es que una ruta de red que se cae silenciosamente — una conexión TCP "half-open" en la que un lado desapareció sin un cierre adecuado — puede parecer conectada hasta que algo realmente intenta enviar datos. La comprobación de keep-alive es lo que hace visible eso rápidamente y permite que la conexión se restablezca limpiamente. Ajusta el tiempo según tus necesidades: lo bastante estricto para detectar una caída real con rapidez, lo bastante flexible para que un dispositivo naturalmente inactivo no se marque durante periodos normales de inactividad.

Respondido por Bohdan Miniv · Ingeniería de QA