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.