Clientes Multihilos

En el contexto de arquitecturas cliente-servidor, la implementación de hilos en el lado del cliente proporciona los siguientes beneficios [2]:

• Ocultar latencias de red: El navegador web escanea una página HTML entrante y encuentra que hay más archivos que necesita, entonces continúa con el proceso de recuperación de los mismos. Los archivos recuperados se despliegan conforme van llegando. De esta manera, el usuario no necesita esperar hasta que todos los componentes de la página sean recuperados por completo.

• Cada archivo es recuperado por un hilo: La programación de la configuración de una conexión y la lectura desde el servidor pueden llevarse a cabo mediante una solicitud de tipo HTTP(bloqueo). Las llamadas de este tipo no suspende el proceso por completo.

• Conexiones simultáneas: Cuando se utiliza cliente multihilos, las conexiones pueden configurarse como réplicas diferentes lo cual permite que los datos sean transferidos en paralelo asegurando efectivamente que se despliega la página web completa en un tiempo más corto que con un servidor no replicado.

Ejemplo: Múltiples llamadas a RPC  

Un cliente realiza varias llamadas al mismo tiempo a procesos remotos, cada una por una diferente hilo. Luego, espera hasta que se hayan devuelto todos los resultados. Si las llamada son a diferentes servidores, podemos tener una rapidez lineal en la respuesta a la solicitud.

Interfases de Usuario en la Red 

Las interfases de usuario en la red pueden implementarse a nivel de aplicación y a nivel de middleware. Este ejemplo, tomado de [2], ilustra la diferencia de la implementación de interfases a nivel del cliente o en el middleware. Aqui se ilustra el comportamiento de una agenda que se ejecuta en una PDA de un usuario y que requiere sincronizarse con una agenda compartida remota. 

En este caso, un protocolo a nivel de aplicación manipulará esta sincronización, como podemos ver en la Figura 1 parte (a). En la parte (b) de la Figura 1 se muestra una solución donde se proporciona acceso directo a servicios remotos solamente por medio de la oferta en la interfaz de usuario. Esto significa que la máquina cliente sólo se utiliza como terminal sin necesidad de almacenamiento local. En este caso de interfaces de usuario en red, todo es procesado y almacenado en el servidor. Este método de cliente ligero llamado también clientes delgados, recibe mayor atención al incrementarse la conectividad a internet, y a medida que los dispositivos portátiles (hand-held) se han vuelto más sofisticados. 

Figura 1: (a) Aplicación en red con su protocolo.  Adaptado de [2]
 

Figura 1:   (b) Aplicación con acceso a aplicaciones remotas. Adaptado de [2]

            

Software del lado del Cliente para transparencia en la distribución.

 Un cliente no solo consta de una interfaz de usuario y de la aplicación, el software del cliente tiene los componentes necesarios para lograr la transparencia en el acceso, migración, distribución y fallas. A continuación se menciona cada una de este tipo de transparencia [2]:

• Transparencia de acceso: Implementando stubs (apéndices o conectores) del lado del cliente para las llamadas a procedimientos remotos (RPC). La transparencia en el acceso es gestionada a partir de una definición de interfaz donde se muestra lo que el cliente tiene que ofrecer.

• Transparencia de ubicación/migración: deje que el software del lado del cliente realice un seguimiento de ubicación actual. Para ello es importante el uso de un adecuado sistema de nombres, 

• Transparencia de replicación: múltiples invocaciones manejadas por el código auxiliar del cliente. El software del lado del cliente puede recopilar de manera transparente todas las respuestas y pasar solamente una respuesta a la aplicación del cliente. Esquema de este comportamiento se muestra en la Figura 2.

• Transparencia de falla: El enmascaramiento de las fallas de la comunicación con un servidor se hace a través del middleware del cliente: ejemplo, la configuración del middleware del cliente para intentar repetidamente la conexión a un servidor, o tratar con otro servidor después de varios intentos fallidos; también cuando middleware del cliente devuelve datos que tenía en caché durante una sesión previa.

Figura 2: Transparencia de replicación de un servidor mediante una solución del lado del 

cliente. Adaptado de [2]

Bibliografía

    [1]George Coulouris et al. Distributed Systems: Concepts and Design. 5th. USA: Addison-Wesley Publishing Company, 2011

    [2]M van Steen and A.S. Tanenbaum. Distributed Systems. Edited by Pearson Prentice Hall. Third. distributed-systems.net, 2017