Reindirizzamento dei dati della porta seriale su Telnet

In linea di principio sì — RFC 2217 è uno standard pubblicato, quindi SEC può interoperare con implementazioni di terze parti conformi, inclusi server hardware console/terminal di fornitori come Digi, Lantronix e Moxa che espongono l'opzione Telnet COM-port-control, e con endpoint software come un server Linux ser2net/pySerial. Questa interoperabilità è uno dei motivi per preferire la modalità Telnet quando si effettua il bridging verso apparecchiature non SEC.

La precisazione onesta: esegui sempre un test pratico della specifica combinazione prima di farvi affidamento. Le implementazioni differiscono per quali comandi RFC 2217 opzionali supportano e per quanto rigorosamente seguono la specifica, quindi un determinato server hardware potrebbe gestire la negoziazione del baud rate ma non qualche comando della linea di segnale, o viceversa. Di solito funziona — ma "è uno standard" non sostituisce la conferma che i tuoi due dispositivi specifici siano effettivamente compatibili nella pratica.

Risposta di Bohdan Miniv · QA Engineering

I segnali di controllo di flusso sono rappresentati: RFC 2217 trasporta lo stato delle linee di controllo (RTS/CTS e la modalità di controllo di flusso) tra le estremità, quindi l'handshaking hardware è compreso dal protocollo invece di essere ignorato come avviene in modalità Raw. Per la configurazione iniziale e per i dispositivi in cui il controllo di flusso riguarda una configurazione corretta, questo funziona.

Il limite è la reattività su una rete. Il controllo di flusso hardware esiste per rallentare immediatamente un mittente veloce nel momento in cui il buffer di un ricevitore si riempie — una reazione in tempo reale misurata in tempi di carattere. Attraverso un collegamento di rete, la variazione di CTS deve tornare indietro tramite TCP con la sua latenza e il buffering, quindi potrebbe non arrivare abbastanza rapidamente da impedire un overrun su un flusso ad alta velocità. Su una LAN a bassa latenza di solito va bene; su internet, non fare affidamento sul controllo di flusso hardware remoto per prevenire i buffer overrun su un dispositivo veloce. Dove possibile, lascia che il controllo di flusso agisca localmente sulla porta fisica e trasporta solo i dati sul collegamento.

Risposta di Nikolai Svarachevsky · Lead Developer

Perché RFC 2217 negozia e controlla i parametri della porta per una singola sessione. L'intero scopo della modalità Telnet è che un client connesso possa impostare il baud rate, commutare le linee di segnale e leggere lo stato della porta — e non esiste un modo coerente perché due client detengano ciascuno tale autorità sulla stessa porta fisica nello stesso momento. Se due client richiedessero baud rate diversi, quale prevarrebbe? Il protocollo non ha una risposta, quindi la modalità è definita come peer-to-peer.

Questo è esattamente il motivo per cui esiste la modalità Raw per il caso uno-a-molti: Raw non comporta il controllo dei parametri della porta, ma solo byte, quindi può duplicare in sicurezza il flusso verso molti client. Il compromesso è l'altro lato della stessa medaglia — Raw ti offre più client ma nessun controllo remoto della porta; Telnet ti offre il pieno controllo della porta ma un solo peer. Scegli la modalità che corrisponde al fatto che tu abbia bisogno di controllo o di distribuzione.

Risposta di Nikolai Svarachevsky · Lead Developer

Poiché RFC 2217 è definito come un'opzione sopra Telnet, che funziona su TCP — e dipende esattamente dalle garanzie che TCP fornisce. I comandi di controllo della porta (impostare il baud, impostare le linee di segnale) vengono negoziati in-band e si basano sul fatto che il flusso arrivi in modo affidabile, in ordine, con le due estremità in grado di confermarsi a vicenda. Questa è una conversazione orientata alla connessione.

UDP non offre nulla di tutto questo: nessuna connessione, nessun ordinamento, nessuna garanzia di consegna, nessun riconoscimento. Una negoziazione che presuppone una consegna affidabile e ordinata semplicemente non può funzionare su un trasporto che può perdere o riordinare proprio il comando che imposta il baud rate. Quindi le due modalità si separano nettamente in base al trasporto: la segnalazione RFC 2217 appartiene a TCP, e UDP è solo per dati grezzi unidirezionali. Se hai bisogno del controllo di segnali/parametri, sei necessariamente su TCP.

Risposta di Nikolai Svarachevsky · Lead Developer