Conectividade Simultânea a Várias Portas COM

Sim. Como os tipos de ligação de servidor e cliente são intercambiáveis, a imagem espelhada de "muitos clientes, um servidor" é totalmente suportada: uma máquina executa várias ligações de cliente, cada uma ligando-se a um servidor diferente, e cada uma mapeada para a sua própria porta COM virtual localmente. Este é o fan-in padrão — trazer vários dispositivos remotos para um computador central.

A regra de conceção que mantém isto organizado é uma porta virtual por fonte remota. A sua aplicação lê então cada dispositivo numa porta separada e inequívoca. Evite a tentação de fundir vários servidores remotos numa única porta local — os seus fluxos de bytes iriam intercalar-se sem forma de os distinguir, a menos que as cargas úteis sejam explicitamente autoidentificáveis. Portas separadas, fontes separadas.

Respondido por Nikolai Svarachevsky · Programador Principal

Sim, e é mais simples do que parece. Cada máquina publica a sua própria porta real como uma ligação de servidor e, em seguida, cria portas virtuais que se ligam a todas as outras ligações de servidor das outras máquinas (todas exceto a si própria). Faça isso em cada nó e os dados de cada dispositivo ficam disponíveis em todas as outras máquinas — essa é a sua estrela. O modelo intercambiável de servidor/cliente é o que permite compô-lo de forma limpa, por isso não há nenhum "modo mesh" especial para procurar; basta construí-lo a partir das mesmas ligações que já utiliza.

A única coisa que precisa de ser planeada são as escritas, não as leituras. Distribuir a saída de cada dispositivo para todos funciona perfeitamente. Mas, se várias máquinas enviarem comandos para o mesmo dispositivo, essas escritas intercalam-se nessa única porta física — o serial não tem arbitragem para vários escritores — por isso, mantenha o tráfego de comandos com um único escritor por dispositivo, ou faça a arbitragem ao nível da aplicação. Se a configuração ficar grande, uma porta virtual por cada origem remota (em vez de juntar várias numa só) mantém cada fluxo claramente separado.

Respondido por Nikolai Svarachevsky · Programador Principal

Porque o RFC 2217 dá a um cliente autoridade sobre os parâmetros da porta — taxa de transmissão, linhas de sinal, estado da porta — e essa autoridade não pode ser partilhada de forma coerente. Se dois clientes estivessem ligados ao mesmo tempo e cada um tentasse definir uma taxa de transmissão diferente ou controlar o RTS de forma diferente, a porta física não teria como satisfazer ambos. Por isso, o protocolo é definido como peer-to-peer: exatamente um cliente detém a sessão RFC 2217 de cada vez.

É por isso que a partilha por vários clientes usa o modo Raw, que não transporta propriedade sobre os parâmetros da porta e, por isso, pode duplicar com segurança um fluxo de bytes para muitos clientes. Os dois modos são complementares por conceção: Telnet/RFC 2217 para um único par que precisa de controlo total da porta, Raw para muitos pares que apenas precisam dos dados. Se precisar de controlo e distribuição simultaneamente, dê ao consumidor que controla a sua própria ligação Telnet dedicada, separada da distribuição Raw.

Respondido por Nikolai Svarachevsky · Programador Principal