Come condividere i dispositivi seriali su una rete

Sì, quando la porta condivisa è una connessione server in modalità Raw, consente più client e ogni client connesso riceve una copia dell'output del dispositivo. Questo è ideale per un dispositivo che emette dati a molti destinatari (un ricevitore GPS, un flusso di sensori). Nota che la modalità Telnet (RFC 2217) è peer-to-peer — un client alla volta — perché il controllo della porta per sessione non può essere condiviso, quindi la condivisione multi-client significa modalità Raw e rinunciare alla negoziazione remota di baud/segnali.

Un limite importante: molti computer possono leggere in sicurezza da un dispositivo, ma molti computer che scrivono comandi su un dispositivo non è sicuro. Una linea seriale non ha arbitraggio multi-master, quindi i comandi sovrapposti provenienti da client diversi si intrecciano in byte corrotti sull'unica porta fisica. Distribuzione a molti lettori, sì; più scrittori non controllati, no — arbitra i comandi tramite un solo client di controllo se il dispositivo è di tipo comando/risposta.

Risposta di Nikolai Svarachevsky · Lead Developer

No — ed è importante essere chiari perché è un'ipotesi comune. SEC è un inoltratore trasparente di byte, non un convertitore di protocollo. I byte che entrano nella porta seriale escono dalla porta virtuale senza modifiche; Modbus RTU rimane Modbus RTU. La tua applicazione dall'altra parte continua a parlare esattamente lo stesso protocollo seriale del dispositivo — SEC si limita a trasportare quella conversazione attraverso la rete.

Se hai davvero bisogno che il framing RTU venga riconfezionato in Modbus TCP (framing diverso, nessun CRC, un vero header di transazione TCP), allora si tratta di traduzione di protocollo, e ti serve invece un gateway Modbus dedicato. SEC è adatto quando entrambe le estremità parlano già lo stesso protocollo seriale e devi solo spostarlo su una rete. "Raggiungere il dispositivo da remoto" è il nostro compito; "cambiare ciò che il dispositivo parla" non lo è.

Risposta di Nikolai Svarachevsky · Lead Developer

Il livello software in sé aggiunge poco — in genere un piccolo overhead inferiore a 10 ms in normali condizioni locali. Ma non indicheremo un unico numero universale, perché il valore che conta è dominato dalla tua rete, non dal SEC: su una LAN, la latenza totale aggiunta è minima; attraverso internet o una VPN, il vero costo è il round-trip di rete, e può variare da pochi millisecondi a centinaia a seconda della distanza e della congestione.

La larghezza di banda non è praticamente mai il collo di bottiglia — le velocità dei dati seriali sono minuscole rispetto a qualsiasi rete moderna. La latenza è l'aspetto attorno a cui progettare. Se il tuo protocollo la tollera (streaming, polling non serrato), non te ne accorgerai mai. Se impone finestre di risposta strette, misura il round-trip reale sul tuo percorso effettivo prima di impegnarti, e ricorda che i controlli di buffering del SEC scambiano un po' di latenza aggiuntiva con un framing più pulito quando ne hai bisogno.

Risposta di Bohdan Miniv · Ingegneria QA

Sì. Le impostazioni di connessione di SEC includono controlli di packetizzazione proprio per questo, compresa un'opzione "invia i dati quando viene ricevuto un carattere con un determinato codice". Impostala sul byte di fine messaggio del tuo protocollo (ad esempio, un ritorno a capo o un avanzamento riga per ASCII orientato alle righe) e SEC accumulerà i byte in arrivo e li invierà alla rete come un'unica unità quando arriva quel delimitatore, invece di inoltrare i byte a pezzi.

Questo è davvero utile per mantenere intatto il framing dei messaggi attraverso una rete che altrimenti dividerebbe o unirebbe un flusso di byte, e si abbina ai controlli correlati — trattieni per un tempo impostato, oppure invia una volta che un blocco raggiunge una determinata dimensione. Il compromesso da tenere presente è questo: qualsiasi regola "attendi fino a…" aggiunge per definizione un po' di latenza, poiché stai deliberatamente trattenendo i byte fino al trigger. Per la maggior parte dei protocolli con framing, questo è esattamente il comportamento desiderato.

Risposta di Nikolai Svarachevsky · Lead Developer

Il requisito minimo è semplice: installa SEC sulla macchina che ha la porta seriale che vuoi condividere. Quel lato pubblica la porta sulla rete, e l'altro capo può comunicare con essa come con una normale connessione di rete — se la tua applicazione remota può aprire direttamente un socket TCP raw, si connette direttamente e non richiede l'installazione di SEC. Quel capo remoto potrebbe persino essere un dispositivo hardware (un terminale o un server console) che già parla il protocollo sulla rete.

Hai bisogno di SEC su entrambe le estremità solo quando entrambe le estremità devono presentare una vera porta COM al loro software locale. In tal caso ogni nodo esegue SEC per esporre la porta localmente e SEC trasporta i dati tra di loro. In parole semplici: installa SEC su ogni nodo in cui un'applicazione si aspetta di vedere una porta COM, e non installarlo dove il software parla già direttamente TCP — o dove l'endpoint è hardware.

Risposta di Nikolai Svarachevsky · Lead Developer