WebSockets - SSL

 

Por fin pude terminar esta primera versión de uso de websockets con UT usando también certificado SSL. Era un tema muy complicado a nivel de uso del certificado y a nivel de planteamiento de cómo hacerlo fácil de usar en nuestras aplicaciones.

Podriamos definir WebSocket como un protocolo de comunicación que permite una conexión bidireccional y persistente entre un cliente y un servidor, facilitando la transmisión de datos en tiempo real. 

A diferencia de Html, que es un lenguaje de marcado utilizado para estructurar y presentar contenido en la web, WebSockets se centra en la comunicación continua y eficiente. Mientras que Html se utiliza para crear la interfaz de usuario, WebSocket permite la actualización dinámica de datos sin necesidad de recargar la página, esta diria que es la diferencia básica a tener en cuenta.

He intentado seguir la linea de UT en cuanto funcionalidad y manejo para poder gestionar muy fácilmente nuestra web. Como bien sabéis nosotros a partir de un evento de algún elemento del nuestro dom, por ejemplo un button, generamos una petición a nuestra api para procesar esa acción, y desde ese api damos una respuesta a la pantalla pudiendo controlar los diferentes controles que tenemos “pintados”

Entiendo que una de las grandes ventajas de websockets a partir de su rapidez es que podamos enviar mensajes rápidamente al cliente independiente de la petición, siempre que tengamos una conexión websocket. Si os fijáis en el esquema puesto anteriormente que hay 3 flechas rojas que responden al cliente, por una de entrada. Y quizás entre las acciones que nos podríamos beneficiar (siempre hablo desde un entorno de aplicaciones de gestión, quizás no enfocado a IoT u otros escenarios) es por ejemplo:

• Notificaciones al cliente cuando procesamos procesos de larga duración, indicando el estado del proceso, dando una sensación de aplicación ‘viva’, en lugar de tener una pantalla congelada y esperando a que termine el proceso
• Notificaciones a varios usuarios a la vez
• Notificaciones continuos en un proceso de monitorización
• ...

Con todo esto debemos saber que el uso de WS implica:

1. Consumo de memoria: Cada conexión WebSocket abierta consume memoria. Si tienes muchas conexiones simultáneas, esto puede llevar a un uso significativo de memoria.
2. Carga de CPU: El manejo de múltiples conexiones y la transmisión de datos en tiempo real puede aumentar la carga de la CPU, especialmente si el servidor realiza operaciones intensivas de procesamiento de datos.
3. Rendimiento: La latencia y el rendimiento pueden verse afectados si el servidor no está optimizado para manejar conexiones persistentes y tráfico de datos en tiempo real.
4. Escalabilidad: A medida que el número de conexiones aumenta, es crucial implementar estrategias de escalabilidad, como el uso de balanceadores de carga y la distribución de conexiones entre múltiples servidores.
5. Optimización: Es necesario optimizar tanto el servidor como el cliente para asegurar una comunicación eficiente y minimizar el impacto en el rendimiento general del sistema.

De todo esto se encargará UT pero siempre siendo conscientes hasta donde podrá aguantar UT la carga de https, wss, gestión del dom, sesiones, procesos, … 🙂

Hemos de pensar que una conexión http se crea, procesa, devuelve y muere. No existe de alguna manera persistencia. Podemos tener en un momento dado en un mismo segundo 5 usuarios dando a la vez a un botón, y aquí UT llega a gestionarlo correctamente, pero si creamos conexiones ws para todos, supondrá una carga en nuestro servidor a nivel cpu y memoria que quizás debamos valorar si tiene sentido. 

Harbour no es un servidor preparado para carga de miles de peticiones websockets, que podamos escalar, balancear,... pero si que nos permitirá tener este tipo de solución para según que escenario planteemos.

Aun así, vamos a dar un margen de confianza a nuestro sistema para que nos ayude en nuestro propósito

1. Configuración del servidor: Necesitábamos que el servidor pudiera dar soporte a SSL. Finalmente implemente el sistema usado en uhttpd
2. Configuración del entorno: Configuración del servidor para un uso óptimo
3. Escritura del servidor WebSocket: Implementa el servidor WebSocket, manejando eventos como conexiones entrantes, mensajes y desconexiones en SSL
4. Gestión de clientes: Mantén un registro de los clientes conectados y gestiona sus estados y gestión de sockets basuras como un recolector de basura que ya tenemos en harbour
5. Seguridad: Implementa medidas de seguridad, como la validación de orígenes y la autenticación de usuarios.
6. Integración con la aplicación: Integra el servidor WebSocket con nuestra aplicación UT  existente, asegurando que los datos se sincronizan correctamente y sobre aquellos módulos que queramos interactuar.
   

A nivel funcional ha de ser muy fácil.

• Cliente. Cuando creemos una pantalla crearemos la conexión WS a nuestro servidor. Podemos tener p.e 10 pantallas, y pongamos que 1 de ellas se encarga de tirar un proceso de larga duración y queremos estar constantemente notificados por donde corre el proceso. A nivel de cliente hemos de  especificar en el código que ese modulo (pantalla) va usar websockets.
• Como siempre, desde nuestra API, podremos crear nuestros procesos, gestión del dom (pantalla) y a partir de ahora… los envíos de notificaciones vía WS. Esto quiere decir, que en el api en este caso iremos corriendo procesos de largo duración y cada x procesos tiramos un ws al cliente notificando de lo que se está realizando

Ha de ser así de fácil.

Y ahora con la ventaja de también podemos usarlo via SSL ! 

Evidentemente, a nivel nativo tenemos ya soluciones para jugar con los WS tanto desde javascript como Harbour, pero en este escenario no entraré por su complejidad. El objetivo es dar acceso a esto solución con 2 líneas de código !

Necesito crear un par de ejemplos que se entienda bien el uso, intentar documentarlo montar la libreria en UT,... en unos dias o par de semanas estará listo, la aprte dura ya ha pasado.

Con esta gran mejora, una vez estabilizado bien creo que podemos pasar a la versión UT 2.0