Trasferisci i dati seriali sul Cloud

Sì, ma con un vero limite che devi considerare nella progettazione. Una porta COM fisica è ad accesso esclusivo — un processo alla volta — quindi un'applicazione locale e il cloud non possono entrambe mantenere direttamente aperta la stessa porta reale. Il modello praticabile è una coppia di porte virtuali sulla macchina locale: l'app locale comunica con una porta virtuale, SEC fa da ponte verso la porta reale e la connessione cloud condivide gli stessi dati collegati tramite ponte.

L'avvertimento sincero: una volta che sia un'app locale sia un'app cloud sono collegate a un dispositivo, il loro traffico può mescolarsi. I dati in ingresso dal dispositivo vengono distribuiti a entrambi i consumer (va bene per la sola lettura), ma se entrambe le parti inviano comandi, questi comandi si intercalano sulla singola UART fisica e si corrompono a vicenda. Quindi "locale e cloud contemporaneamente" è sicuro per la lettura condivisa; per comandare il dispositivo, assicurati che solo una parte scriva alla volta.

Risposta di Nikolai Svarachevsky · Lead Developer

Sì — questa è una topologia fan-in e funziona bene. Sulla macchina cloud si crea una porta COM virtuale per sorgente, ciascuna alimentata da una connessione client in ingresso dal rispettivo sito (oppure da server in ciascun sito a cui il cloud si connette in uscita — i tipi di connessione sono intercambiabili). La tua applicazione nel cloud vedrà quindi una porta COM separata e pulita per ogni dispositivo remoto.

La regola di progettazione che mantiene tutto gestibile è questa: assegna a ogni sorgente la propria porta virtuale invece di unire più dispositivi in un'unica porta. Se convogli più dispositivi in una singola porta, i loro byte arrivano intercalati senza alcun modo di capire quale provenga da quale dispositivo. Una porta per ogni dispositivo remoto — e ricorda che il collegamento di ogni sito ha la propria latenza internet, quindi dimensiona i timeout per ogni sorgente, non sulla base di un'unica ipotesi.

Risposta di Nikolai Svarachevsky · Lead Developer

La velocità effettiva non è quasi mai influenzata in modo percepibile, perché le velocità dei dati seriali sono minuscole rispetto alla larghezza di banda della rete — anche un collegamento seriale veloce è un rivolo rispetto a una normale connessione internet, quindi SEC non è limitato dalla larghezza di banda. Ciò che SEC e la rete aggiungono è la latenza, non un limite alla velocità effettiva: un piccolo overhead software più il tempo di andata e ritorno del percorso verso il cloud.

Per un trasferimento continuo o in blocco, quella latenza è un ritardo iniziale della pipeline e la velocità effettiva rimane elevata. Dove si manifesta è nel traffico verboso di richiesta/risposta, dove ogni scambio paga il tempo di andata e ritorno e la velocità effettiva diminuisce anche se la larghezza di banda grezza è ampia. Se questo è il tuo schema su un lungo percorso cloud, riduci il numero di andate e ritorni (raggruppa le richieste, mantieni un poller locale al dispositivo) invece di aspettarti che SEC acceleri il collegamento.

Risposta di Bohdan Miniv · Ingegneria QA

Lo stato delle linee di segnale viene trasportato quando si utilizza la modalità Telnet (RFC 2217): le modifiche RTS/DTR dell'applicazione remota vengono trasmesse e applicate alla porta fisica, e gli stati delle linee come CTS/DSR/DCD vengono riportati indietro. In modalità Raw nulla di tutto questo viene trasportato — Raw trasferisce solo i dati. Quindi, per il controllo dei segnali, usa la modalità Telnet.

Il limite reale è il timing, non la capacità. RFC 2217 trasporta le modifiche delle linee di controllo in-band e in modo debolmente sincronizzato con il flusso di dati, quindi su un collegamento cloud con buffering e latenza internet, il momento esatto in cui una linea cambia rispetto ai dati non è deterministico. Per i segnali di stato e la configurazione va bene. Per usi in tempo reale — commutazione della direzione RS-485 half-duplex pilotata via software, o BREAK temporizzato con precisione — non pilotare la linea da remoto tramite internet; gestisci quel timing localmente sul dispositivo e usa il collegamento cloud solo per i dati.

Risposta di Nikolai Svarachevsky · Lead Developer

Sì. In modalità Raw SEC ha una scheda Signal Lines in cui puoi configurare quali linee di segnale vengono alzate o abbassate alla connessione — così puoi avere una linea attivata quando un client di rete si collega e disattivata quando si scollega. È esattamente l’indicatore "un client remoto è ora collegato" che stai descrivendo, ed è un’impostazione supportata anziché qualcosa che devi improvvisare.

Vale la pena capire la distinzione rispetto alla modalità Telnet: lì, SEC riflette gli stati effettivi delle linee hardware tra le due estremità, quindi le linee seguono il dispositivo anziché la connessione. Il comportamento configurabile delle linee alla connessione/disconnessione è una funzionalità della modalità Raw. Imposta in quella scheda le linee specifiche e i loro stati on-connect / on-disconnect; se la linea di destinazione o la polarità non sono tra le opzioni, descrivi l’obiettivo esatto al supporto e confermeremo cosa consente la build attuale.

Risposta di Bohdan Miniv · Ingegneria QA

SEC ha un'impostazione keep-alive che gestisce esattamente questo. Controlla periodicamente che il collegamento sia ancora attivo, così una connessione che è caduta silenziosamente viene rilevata e chiusa invece di restare lì apparentemente attiva. Regolando la temporizzazione del keep-alive controlli quanto attentamente SEC monitora il collegamento — intervalli più brevi rilevano una caduta più rapidamente, quelli più lunghi sono più permissivi.

Il motivo per cui questo è importante è che un percorso di rete caduto silenziosamente — una connessione TCP "half-open" in cui un lato è scomparso senza una chiusura corretta — può altrimenti sembrare connesso finché qualcosa non prova effettivamente a inviare dati. Il controllo keep-alive è ciò che fa emergere rapidamente questo problema e consente alla connessione di ristabilirsi in modo pulito. Regola la temporizzazione in base alle tue esigenze: abbastanza stretta da rilevare prontamente una vera caduta, abbastanza permissiva da non segnalare un dispositivo naturalmente silenzioso durante i normali periodi di inattività.

Risposta di Bohdan Miniv · Ingegneria QA