Duración de la sesión de IoT


7

Un cuadro de Linux envía mediciones a AWS-RDBMS. Un script de python abre y cierra la conexión solo el tiempo suficiente para cargar datos en la base de datos (las sesiones se cierran inmediatamente después de la actualización). La alternativa es que el cuadro abre una sesión indefinida a la base de datos y actualiza el RDBMS: no estoy seguro de qué problemas tendría esto si fallara la conexión a Internet y no estoy seguro del grado de `` persistencia '' de la conexión ante una conexión a Internet inestable. A escala, podría haber cientos de cuadros de medición cargando datos al RDBMS.

¿Cuál es la mejor práctica con respecto a la duración de la conexión de sesión de Python IoT? ¿Es mejor cerrar la sesión después de transmitir los datos? Tal vez defina un tiempo de inactividad que comience después de que se transmitan los datos: si el tiempo de inactividad alcanza más de una cantidad de tiempo predefinida, cierre el canal. Bonificación por cualquier explicación del por qué detrás de la mejor práctica.

¿Quizás esta pregunta depende de la plataforma? es decir, RDBMS vs AWS Greengrass?


2
Podría ayudarlo a obtener respuestas más específicas si explica exactamente lo que está buscando cuando dice mejores prácticas: no siempre está claro qué significan realmente las "mejores prácticas". ¿Tiene una preocupación específica sobre su configuración (por ejemplo, "¿funcionará bien?") Que podría editar para incluir?
Aurora0001

Con este tipo de preguntas, siempre ayuda dar un poco más de contexto sobre por qué haces la pregunta. Tal como está, está bastante fuera de contexto (y en cualquier otra pila podría parecer una pregunta de tarea, aunque no estoy sugiriendo que en realidad sea esta vez)
Sean Houlihane

Agradezco los comentarios para agregar más detalles / contexto: cualquier 'empujón' en forma de preguntas específicas sería apreciado y aceleraría la configuración de la pregunta.
gatorback

Estoy votando para cerrar esta pregunta como fuera de tema porque es solo otra pregunta genérica de codificación de socket, con las dos alternativas bien explicadas en cientos, si no miles, de sitios web, incluidas muchas respuestas en SO
Mawg dice que reinstalar a Monica el

Respuestas:


2

Las variables que IoT trae a la fiesta aquí son, como mínimo, escala y energía. También puede considerar que la seguridad / resistencia está sujeta a diferentes restricciones en comparación con la forma en que esta pregunta podría haberse respondido hace 5 años. La pregunta 'raíz' sobre SO ya tiene 7 años y no es muy popular.

La frecuencia de las transacciones y el costo de establecer una conexión autenticada es probablemente el principal impulsor, tanto en términos de ancho de banda de datos como de costos de energía.

¿Hay algún costo por dejar abierta la conexión? ¿Cuánto más esfuerzo necesitará para administrar una conexión 'en su mayoría persistente' en comparación con la más trivial 'abrir-usar-cerrar'? ¿Qué enfoque resultará en una contención de recursos más rápida (suponiendo que su producto esté planeado para escalar masivamente)?

¿Es probable que migre su código / protocolo más allá del borde de la red (o migre la funcionalidad de la nube más cerca del borde) en el futuro? Estas migraciones potenciales pueden cambiar sus limitaciones, o puede preferir diferir la inversión potencial en software.


1

Aunque está utilizando la sesión para IOT, esta * no es una pregunta IOT, solo una pregunta general de sockets y, como tal, hay muchas, muchas, muchas respuestas en Google y en Stack Overflow .

Básicamente, no hay una respuesta "correcta", solo necesita considerar su situación.

En términos generales, es más fácil implementar el código "cerrar después de cada transacción", ya que no necesita tanto código "ooops, mi sesión actualmente abierta se cerró inesperadamente". Ese es el enfoque que siempre adopto, y que he visto con más frecuencia en la industria.

Sin embargo, si necesita enviar paquetes frecuentes (el tamaño no es importante, solo la frecuencia), la sobrecarga de cerrar y reabrir después de cada paquete puede generar problemas de rendimiento.

Pagas tu dinero, eliges :-)

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.