Transferir Dados Serial para a Nuvem

Sim, mas com uma ressalva real que precisa de ser considerada no design. Uma porta COM física é de abertura exclusiva — um processo de cada vez — por isso uma aplicação local e a cloud não podem ambas manter diretamente a mesma porta real. O padrão viável é um par de portas virtuais na máquina local: a aplicação local comunica com uma porta virtual, o SEC faz a ponte para a porta real, e a ligação à cloud partilha esses mesmos dados em ponte.

O aviso honesto: assim que uma aplicação local e uma aplicação na cloud estiverem ambas ligadas ao mesmo dispositivo, o respetivo tráfego pode misturar-se. Os dados de entrada do dispositivo são distribuídos para ambos os consumidores (adequado para apenas leitura), mas se ambos os lados enviarem comandos, esses comandos intercalam-se na única UART física e corrompem-se mutuamente. Portanto, "local e cloud ao mesmo tempo" é seguro para leitura partilhada; para comandar o dispositivo, certifique-se de que apenas um dos lados escreve de cada vez.

Respondido por Nikolai Svarachevsky · Programador Principal

Sim — esta é uma topologia fan-in e funciona bem. Na máquina na nuvem, cria uma porta COM virtual por fonte, cada uma alimentada por uma ligação de cliente que entra a partir do respetivo local (ou por servidores em cada local aos quais a nuvem se liga — os tipos de ligação são intercambiáveis). A sua aplicação na nuvem vê então uma porta COM separada e limpa para cada dispositivo remoto.

A regra de conceção que mantém isto sensato: dê a cada fonte a sua própria porta virtual em vez de fundir vários dispositivos numa só porta. Se canalizar vários dispositivos para uma única porta, os seus bytes chegam intercalados sem forma de saber qual veio de qual. Uma porta por dispositivo remoto — e lembre-se de que a ligação de cada local tem a sua própria latência de internet, por isso dimensione os timeouts por fonte, não com base numa única suposição.

Respondido por Nikolai Svarachevsky · Programador Principal

O débito quase nunca é afetado de forma percetível, porque as taxas de dados seriais são minúsculas em comparação com a largura de banda da rede — até uma ligação série rápida é um fio de água ao lado de uma ligação normal à internet, por isso a SEC não é limitada pela largura de banda. O que a SEC e a rede acrescentam é latência, não um limite de débito: uma pequena sobrecarga de software mais o tempo de ida e volta do percurso até à cloud.

Para transferência contínua ou em massa, essa latência é um atraso único do pipeline e o débito efetivo mantém-se elevado. Onde ela se faz notar é no tráfego conversacional de pedido/resposta, em que cada troca paga o tempo de ida e volta e a taxa efetiva diminui, embora a largura de banda bruta seja ampla. Se esse for o seu padrão ao longo de um percurso longo até à cloud, reduza o número de idas e voltas (agrupe pedidos, mantenha um poller local ao dispositivo) em vez de esperar que a SEC acelere a ligação.

Respondido por Bohdan Miniv · Engenharia de QA

O estado da linha de sinal é transportado quando utiliza o modo Telnet (RFC 2217): as alterações de RTS/DTR da aplicação remota são transmitidas e aplicadas na porta física, e estados de linha como CTS/DSR/DCD são comunicados de volta. No modo Raw nada disto é transportado — o Raw move apenas dados. Portanto, para controlo de sinal, utilize o modo Telnet.

O limite real é o timing, não a capacidade. O RFC 2217 transporta alterações das linhas de controlo in-band e de forma pouco sincronizada com o fluxo de dados, por isso, através de uma ligação cloud com buffering e latência da internet, o momento exato em que uma linha muda em relação aos dados não é determinístico. Para sinais de estado e configuração, isso é aceitável. Para utilizações em tempo real — comutação de direção RS-485 half-duplex controlada por software, ou BREAK com temporização precisa — não controle a linha remotamente através da internet; trate esse timing localmente no dispositivo e utilize a ligação cloud apenas para dados.

Respondido por Nikolai Svarachevsky · Programador Principal

Sim. No modo Raw, o SEC tem um separador Signal Lines onde pode configurar quais linhas de sinal são elevadas ou baixadas na ligação — assim, pode ter uma linha ativada quando um cliente de rede se liga e desativada quando se desliga. Isso é exatamente o indicador de "um cliente remoto está agora ligado" que está a descrever, e é uma definição suportada em vez de algo que tenha de improvisar.

Vale a pena compreender a distinção em relação ao modo Telnet: aí, o SEC reflete os estados reais das linhas de hardware entre as duas extremidades, pelo que as linhas seguem o dispositivo em vez da ligação. O comportamento configurável das linhas na ligação/desligação é uma funcionalidade do modo Raw. Defina as linhas específicas e os seus estados ao ligar / ao desligar nesse separador; se a sua linha de destino ou polaridade não estiver entre as opções, descreva o objetivo exato ao suporte e confirmaremos o que a versão atual permite.

Respondido por Bohdan Miniv · Engenharia de QA

SEC tem uma definição de keep-alive que trata exatamente disto. Verifica periodicamente se a ligação ainda está ativa, para que uma ligação que tenha caído silenciosamente seja detetada e encerrada em vez de ficar ali a parecer ativa. Ao ajustar o tempo do keep-alive, controla quão de perto o SEC monitoriza a ligação — intervalos mais curtos detetam uma queda mais rapidamente, enquanto os mais longos são mais permissivos.

A razão pela qual isto importa é que um caminho de rede que caiu silenciosamente — uma ligação TCP "half-open", em que um dos lados desapareceu sem um fecho adequado — pode, de outra forma, parecer ligado até que algo tente realmente enviar dados. A verificação de keep-alive é o que torna isso visível rapidamente e permite que a ligação seja restabelecida de forma limpa. Ajuste o tempo às suas necessidades: suficientemente restrito para detetar uma queda real prontamente, mas suficientemente flexível para que um dispositivo naturalmente silencioso não seja assinalado durante períodos normais de inatividade.

Respondido por Bohdan Miniv · Engenharia de QA