Redirecionar Dados da Porta Serial por Telnet

Em princípio, sim — a RFC 2217 é uma norma publicada, por isso a SEC pode interoperar com implementações de terceiros compatíveis, incluindo servidores de consola/terminal em hardware de fornecedores como Digi, Lantronix e Moxa que expõem a opção Telnet COM-port-control, e com endpoints de software, como um servidor Linux ser2net/pySerial. Essa interoperabilidade é uma das razões para preferir o modo Telnet quando está a fazer bridge para equipamento não-SEC.

A ressalva honesta: teste sempre em bancada o emparelhamento específico antes de confiar nele. As implementações diferem nos comandos opcionais da RFC 2217 que suportam e no rigor com que seguem a especificação, por isso um determinado servidor de hardware pode lidar com a negociação da taxa de transmissão, mas não com algum comando de linha de sinal, ou vice-versa. Normalmente funciona — mas “é uma norma” não substitui a confirmação de que os seus dois dispositivos específicos concordam na prática.

Respondido por Bohdan Miniv · Engenharia de QA

Os sinais de controlo de fluxo são representados: o RFC 2217 transporta o estado da linha de controlo (RTS/CTS e o modo de controlo de fluxo) entre as extremidades, pelo que o protocolo compreende o handshaking por hardware em vez de o ignorar, como acontece no modo Raw. Para configuração e para dispositivos em que o controlo de fluxo depende de uma configuração correta, isto funciona.

A limitação é a capacidade de resposta através de uma rede. O controlo de fluxo por hardware existe para abrandar um emissor rápido no instante em que o buffer de um recetor fica cheio — uma reação em tempo real medida em tempos de carácter. Através de uma ligação de rede, a alteração de CTS tem de regressar por TCP com a sua latência e buffering, pelo que pode não chegar a tempo de impedir um overrun num fluxo de elevado débito. Numa LAN de baixa latência, normalmente funciona bem; pela internet, não confie no controlo de fluxo por hardware remoto para evitar buffer overruns num dispositivo rápido. Sempre que possível, deixe o controlo de fluxo atuar localmente na porta física e transporte apenas os dados pela ligação.

Respondido por Nikolai Svarachevsky · Programador Principal

Porque o RFC 2217 negocia e controla os parâmetros da porta para uma única sessão. O objetivo do modo Telnet é que um cliente ligado possa definir a taxa de transmissão, alternar linhas de sinal e ler o estado da porta — e não há uma forma coerente de dois clientes manterem, cada um, essa autoridade sobre uma única porta física ao mesmo tempo. Se dois clientes solicitassem taxas de transmissão diferentes, qual prevaleceria? O protocolo não tem resposta, por isso o modo é definido como ponto a ponto.

É exatamente por isso que o modo Raw existe para o caso de um para muitos: o Raw não controla os parâmetros da porta, apenas bytes, por isso pode duplicar com segurança o fluxo para muitos clientes. A contrapartida é o outro lado da mesma moeda — o Raw dá-lhe vários clientes, mas nenhum controlo remoto da porta; o Telnet dá-lhe controlo total da porta, mas um único par. Escolha o modo que corresponde ao facto de precisar de controlo ou de distribuição para vários clientes.

Respondido por Nikolai Svarachevsky · Programador Principal

Porque o RFC 2217 é definido como uma opção sobre o Telnet, que funciona sobre TCP — e depende exatamente das garantias que o TCP fornece. Os comandos de controlo da porta (definir baud, definir linhas de sinal) são negociados in-band e dependem de o fluxo chegar de forma fiável, por ordem, com as duas extremidades capazes de se reconhecer mutuamente. Essa é uma conversa orientada à ligação.

O UDP não oferece nada disso: sem ligação, sem ordenação, sem garantia de entrega, sem confirmação. Uma negociação que assume entrega fiável e ordenada simplesmente não pode funcionar sobre um transporte que pode perder ou reordenar o próprio comando que define a taxa de baud. Assim, os dois modos separam-se claramente pelo transporte: a sinalização RFC 2217 pertence ao TCP, e o UDP é apenas para dados brutos unidirecionais. Se precisar de controlo de sinal/parâmetros, terá de usar TCP por necessidade.

Respondido por Nikolai Svarachevsky · Programador Principal