Duração da sessão da IoT


7

Uma caixa do Linux envia medições para o AWS-RDBMS. Um script python abre e fecha a conexão apenas o tempo suficiente para carregar dados no banco de dados (as sessões são fechadas imediatamente após a atualização). A alternativa é que a caixa abra uma sessão indefinida no banco de dados e atualize o RDBMS: não tenho certeza de quais seriam os problemas com isso se a conexão à Internet falhasse e não tivesse certeza do grau de 'persistência' da conexão diante de uma conexão instável à Internet. Em escala, pode haver centenas de caixas de medição enviando dados para o RDBMS.

Qual é a melhor prática em relação à duração da conexão da sessão IoT do python? É uma boa prática fechar a sessão após transmitir os dados? Talvez defina um tempo ocioso que inicia após a transmissão dos dados: se o tempo ocioso atingir mais do que uma quantidade predefinida de tempo, feche o canal. Bônus por qualquer explicação sobre o porquê das melhores práticas.

Talvez essa pergunta dependa da plataforma? ou seja, RDBMS vs AWS Greengrass?


2
Pode ajudar a obter respostas mais específicas se você explicar exatamente o que procura quando diz as melhores práticas - nem sempre é claro o que realmente significa 'melhores práticas'. Você tem alguma preocupação específica com a sua instalação (por exemplo, "isso funcionará bem?") Que você pode editar para incluir?
— Aurora0001

Com esse tipo de pergunta, sempre ajuda a contextualizar um pouco mais o motivo pelo qual você está fazendo a pergunta. Tal como está, é um pouco fora do contexto (e em qualquer outra pilha pode parecer um pouco como uma pergunta lição de casa - embora eu não estou sugerindo que realmente é neste momento)
— Sean Houlihane

Agradeço os comentários para adicionar mais detalhes / contexto: quaisquer "cutucadas" na forma de perguntas específicas seriam apreciadas e acelerariam a modelagem da questão.
— Gatorback

Estou votando para encerrar esta questão como fora de tópico, porque é apenas mais uma questão genérica de codificação de soquete, com as duas alternativas bem explicadas em centenas, senão milhares, de sites, incluindo muitas respostas sobre SO
— Mawg diz que restabelece Monica

Respostas:


2

As variáveis ​​que a IoT traz para a festa aqui são, no mínimo, escala e energia. Você também pode considerar a segurança / resiliência como sujeita a diferentes restrições em comparação com a forma como essa pergunta pode ter sido respondida há 5 anos. A questão "raiz" do SO já tem 7 anos e não é muito popular.

A frequência das transações e o custo da configuração de uma conexão autenticada provavelmente são os principais fatores, em termos de largura de banda de dados e custos de energia.

Existe um custo para deixar a conexão aberta? Quanto mais esforço você precisará para gerenciar uma conexão 'geralmente persistente' em comparação com o mais trivial 'abrir-usar-fechar'? Qual abordagem resultará na contenção de recursos mais rapidamente (supondo que seu produto esteja dimensionado em grande escala)?

É provável que você migre seu código / protocolo ainda mais para a borda da rede (ou migre a funcionalidade da nuvem para mais perto da borda) no futuro? Essas migrações em potencial podem alterar suas restrições ou você pode preferir adiar o potencial investimento em software.


1

Embora você esteja usando a sessão para IOT, essa * não é uma pergunta sobre IOT, apenas uma questão geral sobre soquetes e, como tal, existem muitas, muitas, muitas respostas no Google e no Stack Overflow .

Basicamente, não há resposta "correta", você só precisa considerar sua situação.

De um modo geral, é mais fácil implementar o código "fechar após cada transação", pois você não precisa de tantos códigos "ooops, minha sessão aberta no momento acabou de fechar inesperadamente". Essa é a abordagem que eu sempre adoto e que tenho visto com mais frequência na indústria.

No entanto, se você precisar enviar pacotes frequentes (o tamanho não é importante, apenas a frequência), a sobrecarga de fechar e reabrir após cada pacote pode levar a problemas de desempenho.

Você paga seu dinheiro, você escolhe :-)

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.