Como Compartilhar Dispositivos Serial em uma Rede

Sim, quando a porta partilhada é uma ligação de servidor em modo Raw, permite vários clientes, e cada cliente ligado recebe uma cópia da saída do dispositivo. Isto é ideal para um dispositivo que emite dados para muitos consumidores (um recetor GPS, um fluxo de sensor). Note que o modo Telnet (RFC 2217) é ponto a ponto — um cliente de cada vez — porque o controlo da porta por sessão não pode ser partilhado, por isso a partilha por vários clientes significa modo Raw e abdicar da negociação remota de baud/sinal.

Um limite importante: muitos computadores podem ler com segurança a partir de um dispositivo, mas muitos computadores a escrever comandos para um dispositivo não é seguro. Uma linha série não tem arbitragem multi-master, por isso comandos sobrepostos de diferentes clientes misturam-se em bytes corrompidos na única porta física. Distribuição para muitos leitores, sim; múltiplos escritores sem controlo, não — arbitre os comandos através de um único cliente controlador se o dispositivo for de comando/resposta.

Respondido por Nikolai Svarachevsky · Programador Principal

Não — e vale a pena ser claro, porque é uma suposição comum. O SEC é um encaminhador transparente de bytes, não um conversor de protocolo. Os bytes que entram na porta série saem inalterados pela porta virtual; Modbus RTU continua a ser Modbus RTU. A sua aplicação no outro extremo continua a falar exatamente o protocolo série que o dispositivo fala — o SEC apenas transporta essa comunicação pela rede.

Se o que precisa realmente é de enquadramento RTU reempacotado em Modbus TCP (enquadramento diferente, sem CRC, um cabeçalho de transação TCP adequado), isso é tradução de protocolo, e nesse caso precisa de um gateway Modbus dedicado. O SEC é adequado quando ambas as extremidades já falam o mesmo protocolo série, e só precisa de o transportar por uma rede. “Aceder ao dispositivo remotamente” é connosco; “mudar o que o dispositivo fala” não é.

Respondido por Nikolai Svarachevsky · Programador Principal

A própria camada de software acrescenta pouco — geralmente uma pequena sobrecarga inferior a 10 ms em condições locais normais. Mas não vamos indicar um único número universal, porque o valor que importa é dominado pela sua rede, não pelo SEC: numa LAN, a latência total adicionada é mínima; através da internet ou de uma VPN, o tempo de ida e volta da rede é o custo real, e pode variar de alguns milissegundos a centenas, dependendo da distância e do congestionamento.

A largura de banda praticamente nunca é o estrangulamento — as taxas de dados seriais são minúsculas em comparação com qualquer rede moderna. A latência é o aspeto em torno do qual deve planear. Se o seu protocolo a tolerar (streaming, sondagem menos frequente), nunca dará por isso. Se impuser janelas de resposta apertadas, meça o tempo real de ida e volta no seu percurso efetivo antes de avançar, e lembre-se de que os controlos de buffering do SEC trocam um pouco de latência adicional por um enquadramento mais limpo quando precisa disso.

Respondido por Bohdan Miniv · Engenharia de QA

Sim. As definições de ligação do SEC incluem controlos de packetização precisamente para isto, incluindo uma opção de "enviar dados quando for recebido um carácter com um determinado código". Defina-o para o byte de fim de mensagem do seu protocolo (por exemplo, um carriage return ou line-feed para ASCII orientado por linhas) e o SEC irá acumular os bytes recebidos e enviá-los para a rede como uma única unidade quando esse delimitador chegar, em vez de encaminhar os bytes aos poucos.

Isto é genuinamente útil para manter o enquadramento das mensagens intacto numa rede que, de outra forma, dividiria ou agregaria um fluxo de bytes, e combina com os controlos relacionados — reter durante um tempo definido, ou enviar assim que um bloco atingir um determinado tamanho. O compromisso a ter em conta: qualquer regra de "esperar até…" acrescenta um pouco de latência por definição, uma vez que está deliberadamente a reter bytes até ao acionador. Para a maioria dos protocolos com enquadramento, este é exatamente o comportamento que pretende.

Respondido por Nikolai Svarachevsky · Programador Principal

O requisito mínimo é simples: instale o SEC na máquina que tem a porta série que pretende partilhar. Esse lado publica a porta na rede, e a outra extremidade pode comunicar com ela como uma ligação de rede comum — se a sua aplicação remota conseguir abrir diretamente um socket TCP bruto, liga-se diretamente e não precisa do SEC instalado. Essa extremidade remota pode até ser um dispositivo de hardware (um terminal ou servidor de consola) que já comunica o protocolo pela rede.

Só precisa do SEC em ambas as extremidades quando ambas as extremidades têm de apresentar uma porta COM real ao seu software local. Nesse caso, cada nó executa o SEC para expor a porta localmente e o SEC transporta os dados entre eles. Em termos simples: instale o SEC em cada nó onde uma aplicação espera ver uma porta COM, e ignore-o onde o software já comunica TCP diretamente — ou onde a extremidade é hardware.

Respondido por Nikolai Svarachevsky · Programador Principal