Invocación a Métodos Remotos

 Invocación a Métodos Remotos- RMI

Los puntos en común entre RMI y RPC son los siguientes:

•  Ambos admiten programación con interfaces. 
• Están construidos sobre protocolos de solicitud-respuesta y pueden ofrecer un rango de semántica de llamadas como al menos una vez y como máximo una vez. 
• Ambos ofrecen un nivel similar de transparencia, es decir, las llamadas locales y remotas emplean la misma sintaxis, pero las interfaces remotas suelen exponer la distribución de la llamada subyacente, por ejemplo, admitiendo excepciones remotas.

Las siguientes diferencias conducen a una mayor expresividad cuando se trata de programación de aplicaciones y servicios distribuidos complejos:

• El programador puede utilizar todo el poder expresivo de la programación orientada a objetos para el desarrollo de software de sistemas distribuidos.  
• Todos los objetos en un sistema basado en RMI tienen referencias de objeto únicas (ya sean locales o remoto), tales referencias de objeto también se pueden pasar como parámetros, ofreciendo así semántica de paso de parámetros significativamente más rica que en RPC.

Los siguientes conceptos están presentes en el modelo de objeto distribuido:

• Referencias a objetos remotos: otros objetos pueden invocar los métodos de un objeto remoto si tienen acceso a su referencia de objeto remoto. 
• Interfaces remotas: cada objeto remoto tiene una interfaz remota que especifica qué de sus métodos se pueden invocar de forma remota.

 Arquitectura RMI

La arquitectura se muestra en la Figura 1 ([1], [2], [3]):

• Módulo de Comunicación. Proporcionan semántica de invocación, como ejemplo, al-menos- uno.  Transmite mensaje de solicitud/respuesta entre cliente y servidor Solicitud es (tipo de mensaje, IdSolicitud, ref objeto remoto, IdOperacion, Argumentos). En el servidor selecciona el despachador para la clase de objeto que se invoca.  El despachador ubica la referencia local del objeto en el Módulo de Referencia Remota 
• Módulo de Referencia Remota. Responsable de trasladar referencias de objetos locales a remotas y creación de referencias remotas. Contiene una tabla de objetos remotos y una tabla para cada proxy local Actúa de la manera siguiente:

1. 1era vez cuando se pasa un objeto remoto, el módulo de referencia remota crea una referencia al objeto remoto y se añade a la tabla de objetos remotos 
2. Cuando llega referencia a un objeto remoto, el módulo de referencia obtiene referencia al objeto local, la cual es un proxy o un objeto remoto. 
3. Si el objeto remoto no está en la tabla se crea el proxy y se añade el módulo de referencia remota

• Criado. (servant) Instancia de una clase que proporciona el cuerpo de un objeto remoto. Maneja el requerimiento remoto pasado por el esqueleto correspondiente. Se crea cuando se instancia el objeto remoto. 
• Proxy. Proporciona que los métodos de invocación remota sean transparente al usuario comportandose como un objeto local. Esconde los detalles del empaquetamientos-desempaquetamiento de las referencias a objetos remotos. 
• Despachador.  Un servidor tiene un despachador y un esqueleto. Recibe la petición desde el módulo de comunicación. Usa el IdOperacion para seleccionar el método adecuado en el esqueleto. 
• Esqueleto. Implementa el método en la interface remota. Desempaqueta los argumentos e invoca el método correspondiente en el criado. Espera que la invocación se complete  y empaqueta los resultados

Figure 1: Arquitectura RMI.

 Colector de Basura Distribuida.

Es un algoritmo distribuido cuya función es recolectar la basura distribuida. Establece una cooperación entre el colector local y un módulo añadido que colecciona la basura distribuida

Algoritmo Colector de basura distribuida:

1.  Cada proceso servidor mantiene un conjunto de nombres de los procesos que proporcionan referencias a objetos remotos por cada uno de sus objetos remotos. Este conjunto se puede almacenan en una columna adicional de la tabla de objetos remotos.
2. Cuando un cliente C recibe una referencia remota a un objeto remoto en particular, B, hace una invocación AddRef (B) al servidor de ese objeto remoto y luego crea un proxy; el servidor agrega un apuntador C a B.
3.  Cuando recolector de basura de un cliente C nota que un proxy de un objeto remoto B no está accesible, hace una invocación removeRef (B) al servidor correspondiente y luego borra el proxy; el servidor elimina apuntador C de B.
4.  Cuando apuntador B está vacío, el recolector de basura local del servidor recuperará el espacio ocupado por B a menos que existan apuntadores locales.

Bibliografia:

[1] M van Steen and A.S. Tanenbaum. Distributed Systems. Edited by Pearson Prentice

Hall. Third. distributed-systems.net, 2017 

[2]  George Coulouris et al. Distributed Systems: Concepts and Design. 5th. USA:

Addison-Wesley Publishing Company, 2011. ISBN: 0132143011 

[3] Roberto Vitillo. Understanding Distributed Systems. 2021

Llamadas a Procedimientos Remotos

 Llamadas a Procedimientos Remotos- RPC

Se analizan tres aspectos que son importante para comprender este concepto:

• el estilo de programación promovido por RPC - programación con interfaces; 
• la semántica de llamadas asociada con RPC; 
• la transparencia y su relación con las llamadas a procedimientos remotos.

  Programación con Interfaces

La interfaz de un módulo especifica los procedimientos y las variables a las que se pueden acceder a través de otros módulos. En sistemas distribuidos las interfaces son programas distribuidos donde los módulos se ejecutan en procesos separados. En el modelo clienteservidor, en particular, cada servidor proporciona un conjunto de procedimientos que están disponibles para uso de los clientes, [1] [2].

• No hay detalle de implementación lenguaje de programación. Hay una evolución del software 
• No hay acceso a variables mediante ejecución de procesos remotos ni mecanismos pase de parámetros (llamada por valor o referencia) 
• Direcciones en procesos locales no son válidas en los procesos remotos  
• Mecanismo RPC se integra con el lenguaje de programación e incluye la notación para la definición de interfaces con mensajes input/output 
• Escrita en variedades de lenguajes, C++, Java, Python 
• Lenguajes de definición de interfaces (IDL) están diseñados para permitir que los procedimientos implementados en distintos lenguajes puedan ser invocados por otros

 Semántica de llamadas de RPC

La operación doOperation se puede implementar de diferentes maneras para proporcionar diferentes garantías de entrega en el mensaje (Figura 1). Las principales opciones son: 

• Reintentar mensaje de solicitud: controlar si se retransmite el mensaje de solicitud hasta se recibe una respuesta o supone que el servidor ha fallado. 
• Filtrado duplicado: controlar cuándo se usan las retransmisiones y si se debe filtrar solicitudes duplicadas en el servidor.  
• Retransmisión de resultados: controlar si se debe mantener un historial de mensajes de resultados para permitir que los resultados perdidos se retransmitan sin volver a ejecutar las operaciones en el servidor.

Figura 1. Semántica de llamadas RPC. Adaptado de [2]

Por ejemplo, con una semántica Puede-ser, el invocador de la llamada recibe un  resultado, en cuyo caso el invocador de la llamada sabe que el procedimiento se ejecutó al menos una vez, o una excepción que le informa que no se recibió ningún resultado. La semántica Al-menos-una-vez, puede ser lograda mediante la retransmisión de  mensajes de solicitud, que enmascara las fallas de omisión del mensaje de solicitud o resultado. La semántica puede sufrir lo siguiente tipos de falla:

• fallas de bloqueo cuando falla el servidor que contiene el procedimiento remoto; 
• fallas arbitrarias: en los casos en que el mensaje de solicitud se retransmite, el servidor puede recibirlo y ejecutar el procedimiento más de una vez, posiblemente causando valores incorrectos para ser almacenados o devueltos.

Con una semántica como-máximo-una-vez, la persona que llama recibe un resultado, en cuyo caso la persona que llama sabe que el procedimiento se ejecutó exactamente una vez, o una excepción que le informa que no se recibió ningún resultado, entonces el procedimiento ha sido ejecutados ya sea una vez o no lo ha sido.

Transparencia

La elección de si el RPC debe ser transparente también está disponible para los diseñadores de IDL (Interface Definition Language). Por ejemplo, en algunos IDL, una invocación remota puede generar una excepción cuando el cliente no puede comunicarse con un procedimiento remoto. Esto requiere que el programa cliente maneje tales excepciones, permitiéndole lidiar con tales fallas. Un IDL también puede proporcionar una facilidad para especificar la semántica de llamada de un procedimiento. Esto puede ayudar al diseñador del servicio; por ejemplo, si se elige la semántica de llamada al menos una vez para evitar los gastos generales de una vez como máximo, las operaciones deben diseñarse para que sean idempotentes.

Implementación de RPC

La llamada a procedimiento remoto (RPC) es una técnica orientada a la construcción de aplicaciones distribuidas basadas en cliente-servidor. Se basa en la extensión de la llamada de procedimiento local de manera que el procedimiento llamado no necesita existir en el mismo espacio de direcciones que el procedimiento de llamada. Los dos procesos pueden estar en el mismo sistema, o pueden estar en diferentes sistemas con una red que los conecta.

En la Figura 3 se muestra lo que ocurre cuando se hace una llamada a un proceso remoto:

Figure 3: Llamada a Procedimiento Remoto.

1. El entorno de llamada se suspende, los parámetros del procedimiento se transfieren a través de la red al entorno donde se ejecutará el procedimiento. 
2. Cuando finaliza el procedimiento y produce sus resultados, estos se transfieren de vuelta al entorno de llamada, donde se reanuda la ejecución como si regresara de una llamada de procedimiento regular.

Arquitectura RPC

En la Figura 4 se muestra un esquema de los componentes de la arquitectura de RPC. El cliente que accede a un servicio incluye un procedimiento stub para cada procedimiento definido en la interfaz de servicio. El procedimiento stub se comporta como un procedimiento local para el cliente, pero en lugar de ejecutar la llamada, ordena (empaqueta) el identificador del procedimiento y los argumentos en un mensaje de solicitud, que envía a través de su módulo de comunicación al servidor.

Figure 3: Arquitectura de RPC

 

Cuando llega el mensaje de respuesta, el módulo de comunicación desarma (desempaqueta) los resultados. El proceso del servidor contiene un despachador junto con un procedimiento de código auxiliar del servidor y un procedimiento de servicio para cada procedimiento en la interfaz de servicio. El despachador selecciona uno de los procedimientos stub del servidor, según el identificador de procedimiento en el mensaje de solicitud.

El procedimiento de stub del servidor luego desarma (desempaqueta) los argumentos en el mensaje de solicitud, llama al procedimiento del servicio correspondiente y calcula los valores de retorno para el mensaje de respuesta.

 Los procedimientos de servicio implementan los procedimientos en la interfaz de servicio. Los procedimientos de stub de cliente y servidor y el despachador puede ser generado automáticamente por un compilador de interfaz a partir de la definición de interfaz del servicio.

RPC puede implementarse para tener una de las opciones de semántica de invocación o llamadas, generalmente se elige al menos una vez o como máximo una vez. Para lograr esto, el módulo de comunicación implementará las opciones de diseño deseadas en términos de retransmisión de solicitudes, tratamiento de duplicados y retransmisión de resultados.

Bibliografia:

[1] M van Steen and A.S. Tanenbaum. Distributed Systems. Edited by Pearson Prentice

Hall. Third. distributed-systems.net, 2017 

[2]  George Coulouris et al. Distributed Systems: Concepts and Design. 5th. USA:

Addison-Wesley Publishing Company, 2011. ISBN: 0132143011 

96 Chapter 5. Comunicación entre Procesos Remotos

 Protocolo Solicitud-Respuesta

El protocolo solicitud-respuesta está diseñada para apoyar los roles e intercambios de mensajes en interacciones cliente-servidor. El protocolo solicitud-respuesta  [1] [2], que se describe en la Figura 1,  se basa en un trío de primitivas de comunicación:

Figure 1: Protocolo Solicitud Respuesta.

doOperation,getRequest y sendReply:

• doOperation: los clientes invocan operaciones remotas. Sus argumentos especifican el servidor remoto y la operación a invocar, junto con información adicional (argumentos) requerida por la operación. 
• getRequest es utilizado por un proceso de servidor para adquirir solicitudes de servicio. Envía un mensaje de solicitud al servidor remoto y devuelve la respuesta.  
• sendReply Cuando el servidor ha invocado la operación especificada, usa sendReply para enviar el mensaje de respuesta al cliente. Cuando el cliente recibe el mensaje de respuesta doOperation original se desbloquea y la ejecución del programa cliente continúa.

Ejemplo del protocolo solicitud-respuesta es HTTP y TCP stream ([1], [2]).

 Estructura del Mensaje

La información a transmitir en un mensaje del protocolo solicitud-respuesta, se muestra en la Figura 2

•  El primer campo indica si el mensaje es una Solicitud o un mensaje de Respuesta 
• El camporequestId, contiene un identificador de mensaje generado por una operación en el cliente por cada mensaje de solicitud; el servidor copia estos ID en los mensajes de respuesta correspondientes. Esto permite que doOperation verifique que la respuesta es el resultado de la solicitud actual.  
• El tercer campo es una referencia remota, es el identificador del objeto remoto. 
• El cuarto campo es el conjunto de argumentos que definen las operaciones que se van a invocar.

Figure 2: Estructura del mensaje protocolo Solicitud-Respuesta.

Fallas

Si el protocolo solicitud-respuesta se implementan sobre datagramasUDP, entonces sufren de los mismos fallos de comunicación que UDP. Es decir:

• Fallas por omisión del mensaje. 
• No se garantiza que los mensajes se entreguen en el orden del remitente.

Características del Protocolo solicitud-respuesta

• Tiempos de Espera. Para las ocasiones en que un servidor falla o que se descarta una solicitud o un mensaje de respuesta, la doOperation usa un timeout mientras está esperando obtener mensaje de respuesta del servidor. Para compensar la posibilidad de pérdida de mensajes, doOperation puede reenvíar el mensaje de solicitud repetidamente hasta que recibe una respuesta.  
• Mensajes Duplicados. En los casos en que el mensaje de solicitud sea retransmitido, el servidor puede recibirlo más de una vez. Esto puede llevar a que el servidor ejecute una operación más de una vez para la misma solicitud. Para evitar esto, el protocolo está diseñado para reconocer mensajes sucesivos (del mismo cliente) con el mismo identificador de solicitud, para filtrar los duplicados. 
• Mensajes Perdidos. Si el servidor ya ha enviado la respuesta cuando recibe una solicitud duplicada, deberá ejecutar la operación nuevamente para obtener el resultado , a menos que haya almacenado el resultado de la ejecución original. 
• Historial. Para los servidores que requieren una retransmisión de respuestas sin repetir la ejecución de las operaciones, se puede usar un historial de los mensajes transmitidos. Una entrada en un historial contiene un identificador de solicitud, un mensaje y un identificador del cliente al que se envió la respuesta. Su propósito es permitir que el servidor retransmita los mensajes de respuesta cuando los procesos del cliente los soliciten.

Estilos del protocolo

Se pueden describir tres estilos de protocolos relacionados al protocolo Solicitud-Respuesta,

que producen diferentes comportamientos:

• El protocolo Solicitud (R). El cliente envía un mensaje de solicitud único al servidor. El cliente puede procesar inmediato después de que se envíe el mensaje de solicitud, ya que no es necesario esperar un mensaje de respuesta. Este protocolo se implementa a través de los datagramas de UDP y, además, sufre de las mismas falles de comunicación. 
• El protocolo de solicitud-respuesta (RR). El protocolo RR es útil para la mayoría de los intercambios de clientes-servidores. No se requieren mensajes de acuse de recibo especial, ya que el mensaje de respuesta de un servidor se considera un acuse de recibo del mensaje de solicitud del cliente. 
• El protocolo Solicitud-Respuesta (RRA). El protocolo RRA se basa en el intercambio de tres mensajes: Solicitud, respuesta y reconocimiento. El mensaje de reconocimiento contiene el requestId del mensaje de respuesta. Esto permitirá al servidor descartar las entradas de su historial.

Bibliografia:

[1] M van Steen and A.S. Tanenbaum. Distributed Systems. Edited by Pearson Prentice

Hall. Third. distributed-systems.net, 2017 

[2]  George Coulouris et al. Distributed Systems: Concepts and Design. 5th. USA:

Addison-Wesley Publishing Company, 2011. ISBN: 0132143011 

96 Chapter 5. Comunicación entre Procesos Remotos

Protocolos Capa de Transporte. Multidifusion

 Multidifusión

    Una operación de multidifusión (multicast) es una operación que envía un mensaje de un proceso a cada uno de los miembros de un grupo de procesos, de manera que la membresía del grupo es transparente para el remitente. Hay un abanico de posibilidades en el comportamiento de una multidifusión. El protocolo de multidifusión más simple no ofrece garantías sobre envío de mensajes o mensajes perdidos.

Los mensajes de multidifusión proporcionan una infraestructura para construir sistemas distribuidos con las siguientes características: 

1. Tolerancia a fallas basada en servicios replicados: un servicio replicado consta de un grupo de servidores para suplir un servicio en particular. Las solicitudes de los clientes se envían por multidifusión a todos los miembros del grupo de servidores, cada uno de los cuales realiza una operación idéntica. Cuando algunos de los miembros falla, los clientes aún pueden ser atendidos. 
2.  Descubrimiento de servicios en redes espontáneas: En el descubrimiento de servicios, se usan los mensajes de multidifusión por servidores y clientes para localizar los servicios de disponibles con el fin de registrar sus interfaces o buscar las interfaces de otros servicios en el Sistema distribuido. 
3. Mejor rendimiento a través de datos replicados: los datos se replican para aumentar el rendimiento de un servicio: en algunos casos, las réplicas de los datos se colocan  en los computadores de usuarios. Cada vez que cambian los datos, el nuevo valor se envía por multidifusión a los procesos que gestionan las réplicas. 
4. Propagación de notificaciones de eventos: la multidifusión a un grupo se puede utilizar para notificar a procesos cuando algo sucede. Por ejemplo, en Facebook, cuando alguien cambia su estado, todos sus amigos reciben notificaciones.

 La multidifusión IP

La multidifusión IP se basa en el Protocolo de Internet (IP). Multidifusión IP permite al remitente transmitir un solo paquete IP a un conjunto de computadoras que forman un grupo de multidifusión. La multidifusión IP tiene las siguientes características:

• Dirección de Grupos. Cada grupo de multidifusión es una direción única de la clase D. Unas pocas direcciones son asignadas por la autoridad única de internet, otras direcciones son de uso privado. 

• Número de Grupos. IP proporciona direcciones hasta para 2 elevado a la 28 grupos de multidifusión. Membresía dinámica a grupos. Un host puede unirse o abandonar un grupo de IP multidifusión cuando lo requiera. 

• Uso del hardware. Si el hardware de la red subyacente soporta IP multidifusión, entonces IP usa el hardware de multidifusión para enviar los mensajes IP multidifusión. En caso contrario, usa difusión(cast) o transmisión (broadcast) 

• Reenvio en Redes. Debido a que miembros de grupos de multidifusión IP son adjuntos a varias redes físicas, se require el uso de enrutadores con la capacidad de multidifusión para el reenvío de multidifusión IP.

• Semántica de la distribución Multidifusión IP usa la semántica mejor-esfuerzo para la distribución de mensajes: significa que un datagrama multidifusión puede perderse, retrasarse, duplicarse, o distribuirse fuera de orden. 

• Membresía y transmisión. Un host arbitrario puede enviar datagramas al grupo de multidifusión. La membresía al grupo solo se usa para determinar si el datagrama recibido por el host puede ser enviado al grupo.

En el nivel de programación de aplicaciones, la multidifusión IP solo está disponible a través de UDP. Un programa de aplicación realiza multidifusión enviando datagramas UDP con multidifusión direcciones y números de puerto ordinarios. Puede unirse a un grupo de multidifusión haciendo que su socket se una al grupo, lo que le permite recibir  mensajes al grupo. A nivel de IP, una computadora pertenece a un grupo de multidifusión cuando uno o más de sus procesos tiene sockets que pertenecen a ese grupo. Cuando llega un mensaje de multidifusión a una computadora, las copias se reenvían a todos los sockets locales que se han unido a la dirección de multidifusión especificada y están vinculados a el número de puerto especificado.

Bibliografia:

[1] Douglas Comer. Internetworking with TCP/IP . Volume 1. Sixth edition, Pearson New International Edition. Always learning. Pearson Education Limited, 2014

[2]Larry L. Peterson and Bruce S. Davie. Computer Networks: A Systems Approach. 6th edition. Morgan Kaufmann, 2021

[3] Behrouz A. Forouzan. Data communications & networking with TCP/IP protocol suite. McGraw-Hill Forouzan networking series. McGraw-Hill US Higher Ed ISE, 2021. ISBN

Protocolos Capa de Transporte. TCP

 TCP

    A diferencia del protocolo UDP, TCP es un protocolo que ofrece un servicio de flujos de

bytes, fiable y orientado a la conexión. Dicho servicio ha demostrado ser útil para una

amplia variedad de aplicaciones porque libera a la aplicación de tener que preocuparse

sobre datos perdidos o reordenados, [53].

    El protocolo de control de transmisión (Transmission Control Protocol o TCP) es uno

de los protocolos fundamentales en Internet. Los programas pueden usar TCP para crear

“conexiones” entre sí a través de las cuales puede enviarse un flujo de datos.

TCP da soporte a muchas de las aplicaciones de Internet (navegadores, intercambio de

ficheros, clientes FTP, etc.) y protocolos de aplicación, [2], [3] :

• HTTP. HTTP, protocolo de transferencia de hipertexto, se utiliza para la comunicación entre los navegadores web y servidores web. 

• FTP.  El Protocolo de transferencia de archivos permite que los directorios en una computadora remota naveguen y transferir archivos para ir de una computadora a otra a través de una conexión. 

• Telnet.  Telnet proporciona acceso mediante una sesión de terminal a una computadora remota. 

• SMTP. El Protocolo de transferencia de correo se utiliza para enviar correo entre computadoras.

En la Figura 1 se muestra la posición de IP y de los protocolos de la capa de red, en conjunto con la grupo de protocolos de TCP/IP ya descritos (se han omitido los protocolos por debajo de la capa de Red).

Figure 1: Protocolos TCP/IP

Las características de TCP son las siguientes:

• Tamaños de mensaje: la aplicación puede elegir cuántos datos escribe o lee en un segmento. Puede tratar conjuntos de datos muy pequeños o muy grandes. La implementación de una secuencia o segmento TCP decide cuántos datos recopilar antes de transmitirlo como uno o más paquetes IP. A su llegada, los datos se entregan a la aplicación según lo solicitado. 

• Mensajes perdidos: el protocolo TCP utiliza un esquema de reconocimiento del mensaje. Por ejemplo, el extremo emisor mantiene un registro de cada paquete IP enviado y el extremo receptor reconoce todas las solicitudes recibidas y envía un acuse de recibo. Si el remitente no recibe un acuse de recibo de un mensaje dentro de un tiempo de espera, entonces retransmite el mensaje. 

• Control de flujo: TCP intenta igualar las velocidades de los procesos de lectura y escritura en un segmento. Si el escritor es demasiado rápido para el lector, entonces es bloqueado hasta que el lector haya consumido suficientes segmentos de datos. Duplicación y ordenamiento de mensajes: los identificadores de mensajes están asociados con cada paquete IP, que permite al destinatario detectar y rechazar duplicados, o reordenar los mensajes que no llegan en el orden del remitente. 

• Destinos de mensajes: un par de procesos de comunicación establecen una conexión antes de que puedan comunicarse a través de una secuencia. Una vez que se establece una conexión, Los procesos leen y escriben los stream de datos sin necesidad de utilizar direcciones de Internet o puertos. Establecer una conexión implica una solicitud de conexión del cliente al servidor seguido de una solicitud de aceptación del servidor al cliente antes que cualquier comunicación puede tener lugar.

Figura 2: Intercambio de mensajes en TCP

Mensajes de TCP

    TCP es un protocolo orientado a bytes, significa que el remitente escribe bytes en una

conexión TCP y el receptor lee bytes de la conexión TCP, [1], [2]. TCP no transmite

bytes individuales a través de Internet. En su lugar, TCP en el host origen almacena

suficientes bytes del proceso de envío para llenar un paquete de tamaño razonable y luego

envía este paquete a su par en el host destino. TCP en el host destino vacía el contenido del

paquete en un búfer de recepción, y el proceso de recepción lee de este búfer en su tiempo

libre.

    En la Figura 2, muestra este intercambio de datos en una dirección; aunque, una

única conexión TCP admite flujos de bytes que fluyen en ambas direcciones.

Los paquetes intercambiados entre pares TCP en la Figura 2 son segmentos, ya que

cada uno lleva una parte del flujo de bytes.

    La estructura del segmento se muestra en la Figura 3.

• SrcPort y DstPort identifican el origen y el destino de los puertos, al igual que en UDP. Estos campos, más la dirección de lafuente y las IP de destino, identifican cada conexión TCP.

• El campo número de secuencia contiene el número de secuencia para el primer byte de datos transportado en ese segmento. 

• Los campos Reconocimiento y Ventana de Advertencia llevan información sobre el flujo de datos que van en la dirección contraria. 

• El campo banderas se utiliza para transmitir información de control entre los puntos de conexión TCP. Los indicadores posibles incluyen SYN, FIN, RESET, PUSH, URG y ACK. Por ejemplo, las banderas SYN y FIN se utilizan al establecer y terminar una conexión TCP, respectivamente.

• El campo HdrLen da la longitud del encabezado en palabras de 32 bits. Este campo se conoce como campo de desplazamiento, ya que mide el desplazamiento desde el inicio del paquete hasta el comienzo de los datos. 

• El campo Checksum se usa de la misma manera que para UDP: se calcula sobre el encabezado TCP, los datos TCP y el pseudoencabezado, que se compone de la dirección de origen, la dirección de destino y la longitud campos del encabezado IP. La suma de comprobación es necesaria para TCP tanto en IPv4 e IPv6.

Figure 3: Estructura de mensajes en TCP

Bibliografia:

[1] Douglas Comer. Internetworking with TCP/IP . Volume 1. Sixth edition, Pearson New International Edition. Always learning. Pearson Education Limited, 2014

[2]Larry L. Peterson and Bruce S. Davie. Computer Networks: A Systems Approach. 6th edition. Morgan Kaufmann, 2021

[3] Behrouz A. Forouzan. Data communications & networking with TCP/IP protocol suite. McGraw-Hill Forouzan networking series. McGraw-Hill US Higher Ed ISE, 2021. ISBN

Protocolos Capa de Transporte. Socket

     Esta publicación trata acerca de las interfaces de los programas de aplicación (API), en
particular de las interfaces entre los programas de aplicación y el protocolo TCP/IP.

     En arquitecturas cliente-servidor, cuando se hace una solicitud, por ejemplo obtener una
imagen, image.png de la página web example.com , los pasos que se siguen, a grandes
rasgos, son los siguientes:

1.  Obtener una dirección ip para example.com (Ver como DNS proporciona dirección ip)
2. Abrir un socket a una dirección ip en un puerto determinado 
3.  Abrir una conexión TCP a una dirección ip en un puerto determinado 
4. Hacer la solicitud HTTP GET, de la image.png 
5. Obtener la imagen solicitada, image.png 
6. Cerrar la conexión.

En lo que sigue, se detalla el concepto de socket.

Socket

La abstracción de la interfaz socket es el socket [1], [2]. Un socket es como el punto donde un proceso de aplicación local se conecta a la red. La interfaz define las operaciones de creación del socket, adjuntar el socket a la red, enviar/recibir mensajes a través del socket y cerrar el socket. como se ilustra en la Figura 1.

Figura 1: Socket.

    Para que un proceso reciba mensajes, su socket debe estar vinculado a un puerto local y a una de las direcciones de Internet en la computadora que se ejecuta. Los mensajes enviados a una dirección de Internet y número de puerto en particular solo pueden recibir un proceso cuyo socket está asociado con esa dirección de Internet y número de puerto.

    Los procesos pueden usar el mismo socket para enviar y recibir mensajes. Cualquier proceso puede hacer uso de múltiples puertos para recibir mensajes, pero un proceso no puede compartir puertos con otros procesos en la misma computadora. Cada socket esta asociado con un protocolo particular, ya sea UDP o TCP.

    Veamos como se implementan los socket en los protocolos de la capa de transporte, UDP y TCP.

 UDP

    UDP, User Datagram Protocol, es un protocolo de nivel de transporte basado en el intercambio de datagramas. Permite el envío de datagramas a través de la red sin que se haya establecido previamente una conexión, ya que el propio datagrama incorpora suficiente información de direccionamiento en su cabecera. No tiene confirmación de recepción del mensaje ni control de flujo de transmisión del mensaje, por lo que los paquetes pueden adelantarse unos a otros; y tampoco se sabe si ha llegado correctamente, ya que no hay confirmación de entrega o recepción .

    Un datagrama enviado por UDP se transmite desde un proceso de envío a un proceso de recepción sin reconocimiento ni reintentos. Si ocurre una falla, el mensaje puede que no llegue. Para enviar o recibir mensajes, un proceso primero debe crear un socket vinculado a una dirección de Internet del host local y un puerto local. El servidor enlazará su socket a su puerto: y se da a conocer a los clientes para que puedan enviarle mensajes.

Datagrama

    En la capa de transporte, la unidad de transferencia básica en las llamadas de internet son los datagramas de internet, llamados también datagramas IP o datagrama. La capa de transporte es responsable de brindar servicios a la capa de aplicación: 

• obtener un mensaje de un programa de aplicación que se ejecuta en el host de origen; 
• lo encapsula en un paquete de capa de transporte (llamado datagrama de usuario); y
• entregarlo al programa de aplicación correspondiente en el host de destino. 

Un datagram esta compuesto de dos partes: encabezado y cuerpo, en la Figura 2 se ilustra la estructura.

Figura 2: Estructura del Datagrama

     Revisar más de UDP en documento de IBM: UDP 

Características  de la comunicación con Datagramas

Los siguientes son algunas características relacionada con la comunicación de datagramas  [3]:

• Tamaño del mensaje: la longitud total de un datagrama esta medido en octetos. 

• Longitud del encabezado (HLEN). El campo de longitud del encabezado de 4 bits (HLEN) define la longitud total del encabezado del datagrama en palabras de 4 bytes. El datagrama IPv4 tiene un encabezado de longitud variable. Cuando un dispositivo recibe un datagrama, necesita saber cuándo se detiene el encabezado y comienzan los datos, que están encapsulados en el paquete. Para que el valor de la longitud del encabezado (número de bytes) se ajuste a una longitud de encabezado de 4 bits, la longitud total del encabezado se calcula como palabras de 4 bytes. La longitud total se divide por 4 y el valor se inserta en el campo. 

• Longitud total. Es un campo de 16 bits (encabezado más datos) del datagrama IP en bytes. Un número de 16 bits puede definir una longitud total de hasta 65.535. Sin embargo, el tamaño del datagrama es normalmente mucho menor que esto. Para encontrar la longitud de los datos de un datagrama, reste la longitud del encabezado de la longitud total. La longitud del encabezado se puede encontrar multiplicando el valor en el campo HLEN por 4:

                            Longitud de datos = longitud total - (HLEN) x 4

• Bloqueos: La implementación de sockets con datagramas normalmente proporcionan envíos sin bloqueo y recepciones con bloqueo (una recepción sin bloqueo es una opción en algunos implementaciones): 
• La operación de envío termina cuando ha entregado el mensaje a los protocolos UDP e IP subyacentes, que son responsables de transmitirlo al host de destino 
• A su llegada al destino, el mensaje se coloca en una cola asociada al puerto de destino que esta relacionado con el socket. 
• El mensaje puede ser recogido de la cola por un invocación pendiente o futura a ese socket.
• Los mensajes se descartan en el destino si no hay procesos con un socket vinculado al puerto de destino.

• Tiempos de espera: La recepción con bloqueo es adecuada cuando un servidor está esperando recibir solicitudes de sus clientes. Pero en algunos programas, no es apropiado que en procesos que han invocado una operación de recepción con espera, lo haga indefinidamente. Puede suceder fallas en el proceso de envío o el mensaje esperado puede haberse perdido. Para ello, se pueden establecer tiempos de espera en los sockets. 

• Recibir de cualquiera: el método de recepción no especifica un origen para los mensajes. En cambio, una invocación del método de recepción obtiene un mensaje dirigido a su socket desde cualquier origen. El método de recepción devuelve la dirección de Internet y el puerto local del remitente, permitiendo al destinatario comprobar de dónde procede el mensaje. Es posible conectar un socket de datagrama a un puerto remoto particular y una dirección de Internet, para que el socket pueda enviar mensajes y recibir mensajes de esa dirección.

Uso de UDP

Voz sobre IP y DNS. Es una opción popular porque no causa sobrecarga (overhead) en la

red

Bibliografia:

[1] Douglas Comer. Internetworking with TCP/IP . Volume 1. Sixth edition, Pearson

New International Edition. Always learning. Pearson Education Limited, 2014

[2]Larry L. Peterson and Bruce S. Davie. Computer Networks: A Systems Approach.

6th edition. Morgan Kaufmann, 2021

[3] Behrouz A. Forouzan. Data communications & networking with TCP/IP protocol

suite. McGraw-Hill Forouzan networking series. McGraw-Hill US Higher Ed ISE,

2021. ISBN

La pila de software de Google. Map Reduce

La pila de software de Google.

    

    Google [1] publicó tres artículos clave que revelan la arquitectura de su plataforma entre 2003 y 2006. Los artículos de GFS y MapReduce  [2], [3]sirvieron como base para la arquitectura central de Hadoop. El tercer artículo, sobre BigTable [4], sirvió como base para uno de los primeros sistemas formales de bases de datos NoSQL: HBase.

    La arquitectura de Google en ese momento comprendía cientos de miles de servidores de bajo costo, cada uno de los cuales tenía su propio almacenamiento conectado directamente. Para manejar ese cantidad  de servidores  Google desarrolló tres capas principales de software que sirvieron de base para la plataforma de Google. Éstas eran [1]:

Sistema de archivos de Google (GFS): un sistema de archivos de clúster distribuido que permite acceder a todos los discos dentro del centro de datos de Google como un sistema de archivos masivo, distribuido y redundante.

MapReduce: un marco de procesamiento distribuido para paralelizar algoritmos en una gran cantidad de servidores potencialmente poco confiables y ser capaz de manejar conjuntos de datos masivos.

BigTable: un sistema de base de datos no relacional que utiliza el sistema de archivos de Google para almacenamiento.

MapReduce

    MapReduce es un modelo de programación para la paralelización de propósito general del procesamiento intensivo de datos. MapReduce divide el procesamiento en dos fases: una fase de mapeo, en la que los datos se dividen en fragmentos que pueden procesarse mediante subprocesos separados, que potencialmente se ejecutan en máquinas separadas; y una fase de reducción, que combina la salida de los mapeadores en el resultado final.

    El ejemplo  de MapReduce, que se reproduce de [1] es el programa de recuento de palabras, Figura 1. Supongamos que deseamos contar las apariciones de tipos de mascotas en algún archivo de entrada. Dividimos los datos en partes iguales en la fase del mapa. Luego, los datos se mezclan en grupos de tipos de mascotas. Finalmente, la fase de reducción cuenta las ocurrencias para proporcionar un total que se introduce en la salida.

1. Canalización simple de MapReduce. Tomado de [1]

    Las canalizaciones simples de MapReduce como se muestran en la Figura 1 son raras; Es mucho más típico que se encadenen varias fases de MapReduce para lograr resultados más complejos. Por ejemplo, puede haber varios archivos de entrada que deban fusionarse de alguna manera, o puede haber algún procesamiento iterativo complejo para realizar un análisis estadístico o de aprendizaje automático.

    La Figura 2 ilustra una canalización de MapReduce de varias etapas más compleja. En este ejemplo, un archivo que contiene información sobre visitas a varias páginas web de productos se une a un archivo que contiene detalles del producto (para obtener la categoría del producto) y luego a un archivo que contiene detalles del cliente, para determinar el país del cliente. Estos datos combinados luego se agregan para proporcionar un informe de categorías de productos, geografías de clientes y visitas a páginas.

 

2. MapReduce de varias etapas. Tomado de [1]

    Los procesos de MapReduce se pueden ensamblar en canales arbitrariamente complejos capaces de resolver una amplia gama de problemas de procesamiento de datos. Sin embargo, en muchos aspectos, MapReduce representa un enfoque de procesamiento de fuerza bruta y no siempre es la solución más eficiente o elegante. 

    También existe una categoría de problemas computacionales para los cuales MapReduce no puede ofrecer soluciones escalables.  Por todo ello, MapReduce se ha extendido dentro y fuera de Google mediante algoritmos más sofisticados y especializados. Sin embargo, a pesar de la creciente prevalencia de modelos de procesamiento alternativos, MapReduce sigue siendo un paradigma predeterminado y ampliamente aplicable.

Bibliografia

[1] Guy Harrison, Next Generation Database, Apress Berkeley, CA, Edition 1. 2016,  https://doi.org/10.1007/978-1-4842-1329-2

[2] http://research.google.com/arcHive/gfs.html

 

[3]

http://research.google.com/arcHive/mapreduce.html

 

[4].

http://research.google.com/arcHive/bigtable.html

 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

 Virtualización.

La virtualización es una tecnología que se puede usar para crear representaciones virtuales de servidores, almacenamiento, redes y otras máquinas físicas. La virtualización puede ser aplicada en el contexto de la creación de redes superpuesta, que ofrecen soporte para tipos particulares de aplicaciones distribuidas. Otra aplicación es la virtualización de sistemas, que es en el contexto de los sistemas operativos; esta es la que se estudia en esta sección.

El objetivo de la virtualización de sistema [1] es proporcionar múltiples máquinas  virtuales (imágenes de hardware virtual) sobre la arquitectura de la máquina física subyacente, con cada virtual máquina que ejecuta una instancia de sistema operativo separada. 

El concepto surge de la observación de que las arquitecturas informáticas modernas tienen el rendimiento necesario para admitir potencialmente un gran número de máquinas virtuales y recursos multiplexados entre a ellos. Varias instancias del mismo sistema operativo pueden ejecutarse en máquinas virtuales o se puede admitir una gama de diferentes sistemas operativos. El sistema de virtualización asigna los procesadores físicos y otros recursos de una máquina física entre todas las máquinas virtuales que admite.

Tipos de Virtualización 

En La Figura 1 se muestra, de acuerdo a [3], cuatro tipos de interfaces en tres niveles diferentes de las capas de implementación en un sistema informático típico: la arquitectura del conjunto de instrucciones (ISA, instruction set architecture), la interfaz binaria de la aplicación (ABI, application binary interface) y interfaz de programación de aplicaciones (API, application programming interface).

Figure 1: Interfaces en sistemas informáticos. Adaptado de [3]

• ISA. La ISA marca la división entre hardware y software, y consta de las interfaces: 
• (a) la ISA del usuario e incluye aquellos aspectos visibles para un programa de aplicación (interfaz 4); 
• (b) es un superconjunto del usuario ISA e incluye aquellos aspectos visibles solo para el software del sistema operativo responsable de administrar los recursos de hardware, (interfaz 3). 
• ABI. La ABI da acceso a un programa a los recursos y servicios de hardware disponibles en un sistema a través de la ISA de usuario (interfaz 4); y de la interfaz de llamada al sistema (interfaz 2). 
• API. La API le da a un programa acceso a los recursos y servicios de hardware disponibles en un sistema a través del usuario ISA (interfaz 4) complementado con llamadas de biblioteca de lenguaje de alto nivel (HLL) (interfaz 1). Cualquier  llamada del sistema generalmente se realizan a través de bibliotecas.

La esencia de la virtualización estriba en la capacidad de imitación de las interfaces mencionadas. En la Figura 2 se ilustra las formas de virtualización.

• (a)Conjunto separado de instrucciones, un intérprete/emulador, que se ejecuta sobre un sistema operativo. Se puede construir un sistema en tiempo de ejecución que esencialmente proporcione un conjunto de instrucciones abstractas que se utilizará para ejecutar aplicaciones. Las instrucciones se pueden interpretarse (ejemplo, Java) o emularse (emular SO Windows sobre Linux).
• (b) Instrucciones de bajo nivel, junto con un sistema operativo mínimo básico. Este enfoque se conoce como un monitor de máquina virtual nativo. Se llama nativo porque se implementa directamente en parte superior del hardware subyacente. Tenga en cuenta que la interfaz que ofrece un monitor de máquina virtual se puede ofrecer simultáneamente a diferentes programas. Tendría que proporcionar y regular el acceso a varios recursos, como almacenamiento externo y redes; esto implica que tendrá que implementar controladores de dispositivo para esos recursos. Como resultado, ahora es posible tener múltiples y diferentes sistemas operativos invitados ejecutándose de forma independiente y simultánea en la misma plataforma.
• (c) Instrucciones de bajo nivel, pero delegando la mayor parte del trabajo a un sistema operativo completo. Esta configuración llamada monitor de máquina virtual alojada se ejecutará sobre un sistema operativo alojador (host) de confianza, como se muestra en la Figura 3.8(c). En este caso, el monitor de la máquina virtual puede hacer uso de las instalaciones existentes proporcionadas por ese sistema operativo host.

Figure 3: Formas de Virtualización: (a) VM de proceso,

(b)VMM nativo,

(c)VMM  alojado.

VM y computación en la nube

Tres tipos de servicios en la nube [4]: Infraestructura como servicio que cubre la infraestructura básica, Plataforma como servicio que cubre servicios a nivel de sistema y  Software como servicio que contiene aplicaciones reales

• Infraestructura como servicio (IaaS.) IaaS es la distribución de una infraestructura informática (recursos informáticos, de redes y de almacenamiento) como un servicio. Permite a los clientes escalar (agregar más recursos) o reducir (liberar recursos) cuando sea necesarios (y solo pagan por los recursos consumidos). Esta capacidad es llamado elasticidad y generalmente se logra a través de la virtualización de servidores, una tecnología que permite que varias aplicaciones se ejecuten en el mismo servidor físico que las máquinas virtuales, es decir, como si se ejecutaran en distintos servidores físicos. Luego, los clientes pueden solicitar instancias informáticas como máquinas virtuales y agregar y adjuntar almacenamiento según sea necesario. Un ejemplo de IaaS son los servicios web de Amazon. 

• Software como servicio (SaaS.) SaaS es la entrega de software de aplicación como un servicio. Generaliza el modelo anterior de proveedor de servicios de aplicaciones (ASP)  mediante el cual la aplicación alojada es propiedad exclusiva, operada y mantenida por el ASP. Con SaaS, el proveedor de la nube permite al cliente utilizar aplicaciones alojadas (como con ASP) pero también proporciona herramientas para integrar otras aplicaciones, de diferentes proveedores o incluso desarrollado por el cliente (usando la plataforma en la nube). Ejemplo de una SaaS es el sistema Safesforce CRM. 

• Plataforma como servicio (PaaS.) PaaS es la entrega de una plataforma informática con herramientas de desarrollo y APIs como servicio. Permite a los desarrolladores crear e implementar aplicaciones personalizadas directamente en la infraestructura de la nube e integrarlas con aplicaciones proporcionadas como SaaS. Un ejemplo de PaaS es Google Apps.

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

    [3]J.E. Smith and Ravi Nair. “The architecture of virtual machines”. In: Computer 38.5 (2005), pages 32–38. DOI: 10.1109/MC.2005.173

    [4]Ozsu M.T. and Valduriez P. Principles of distributed database systems. 4th edition. Springer, 2020. ISBN: 9783030262525,9783030262532

 Servidores Multihilos

El uso de clientes multihilos presenta importantes beneficios para los sistemas distribuidos, pero el uso principal de la tecnología multihilos está del lado del servidor. Veamos sus características.

Ventajas y desventajas 

El uso de hilos en el lado del servidor proporciona las siguientes ventajas que redundan en la mejora del rendimiento para las aplicaciones distribuidas:

• Iniciar un hilo es más barato que comenzar un nuevo proceso. 

• Tener un servidor multihilos evita la ampliación a un sistema con multiprocesadores. 

• Un hilo no afecta a otros hilos. En un servidor multihilos, si se produce algún error en cualquiera de los hilos, ningún otro hilo se verá afectado, todos los demás hilos seguirán ejecutándose con normalidad. En un servidor de hilo único, todos los demás clientes tenían que esperar si ocurría algún problema en el hilo. 

• Al igual que con los clientes: oculta la latencia de la red reaccionando a la siguiente solicitud mientras la anterior está siendo respondida. 

• Rápido y eficiente: el servidor multihilo podría responder de manera eficiente y rápida a las crecientes consultas de los clientes rápidamente.

• El tiempo de espera para los usuarios disminuye: en un servidor hilo único, otros usuarios tenían que esperar hasta que se completara el proceso en ejecución, pero en servidores multihilos, todos los usuarios pueden obtener una respuesta a la vez, por lo que ningún usuario tiene que esperar a que finalicen otros procesos.

Pero las ventajas relevantes descansan en que proporciona aplicaciones mejor estructuradas ya que simplifica el flujo de la información:

• La mayoría de los servidores tienen altas demandas de solicitudes E/S. Con las llamadas con bloqueos, se simplifica la estructura general de la aplicación. 

• Los programas multihilos tienden a ser más pequeños y fáciles de entender debido a que se simplifica el flujo de la información.

Las desventajas de esta arquitectura:

• Código complicado: puede resultar difícil escribir el código del servidor multihilo. Estos programas no se crean fácilmente. 

• La depuración es difícil: analizar la razón principal y el origen del error no es fácil de seguir.

Organización del servidor multihilo

En la Figura 1 se ilustra la organización de un servidor multihilos. El servidor espera una petición de entrada para una operación de archivo, posteriormente ejecuta la petición, y luego envía la respuesta de regreso.

Refiriéndonos a  la Figura 1, un hilo servidor, lee las peticiones de entrada para una operación con archivos. Las peticiones son enviadas por clientes hacia un puerto conocido por este servidor. Después de examinar la petición, el hilo en el servidor elije un hilo trabajador sin utilizar (desbloqueado) y le asigna la petición.  

El hilo trabajador procede a realizar una lectura con acción de bloqueo en el sistema de archivos local, ello puede provocar que el hilo se suspenda hasta que los datos sean recuperados desde el disco local. Si el hilo se suspende, se puede selecciona otros hilo para su ejecución. Por ejemplo, el hilo servidor puede seleccionar la adquisición de más hilos trabajadores. 

Figura 1. Servidor MultiHilo

Arquitectura para servidores multihilos.

 En la arquitectura de hilos por solicitud (Figura 2), el hilo de E/S genera un nuevo hilo de trabajo por cada solicitud, y ese hilo trabajador se destruye a sí mismo cuando ha procesado la solicitud contra el objeto remoto designado. Esta arquitectura tiene la ventaja de que los hilos no compiten por una cola compartida y el rendimiento se maximiza potencialmente ya que el hilo de E/S puede crear tantos hilos trabajadores como solicitudes pendientes. La desventaja es la sobrecarga de las operaciones en la creación y destrucción de hilos. 

Figure 2: Servidores multihilos por solicitud

La arquitectura hilo por conexión representado en la Figura 3, asocia un hilo con cada conexión. El servidor crea un nuevo hilo de trabajo cuando un cliente realiza una conexión y destruye el hilo cuando el cliente cierra la conexión. Mientras tanto, el cliente puede realizar muchas solicitudes a través de la conexión, dirigidas a uno o más objetos remotos.

Figure 3: Servidores multihilos por conexión

    La arquitectura hilo por objeto en la Figura 4, asocia un hilo con cada objeto remoto. Un subproceso de E/S recibe solicitudes y las pone en cola para los trabajadores, pero esta vez hay una cola por objeto. En cada una de estas dos últimas arquitecturas, el servidor se beneficia de una gestión de hilos con bajo costo si se compara con la arquitectura de hilos por solicitud. 

Figure 4: Servidores multihilos por objeto

    Su desventaja es que los clientes pueden retrasarse mientras un hilo de trabajo tiene varios solicitudes pendientes pero otro hilo no tiene trabajo que realizar.

Ejemplo de servidor multihilo.

En esta dirección Servidor multihilo puede ver y ejecutar un servidor multihilo

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

Modelos Arquitectónicos. Correspondencia con la infraestructura física distribuida. Parte II

 

Modelos Arquitectónicos. 

Correspondencia con la infraestructura física distribuida II

En esta publicación  se continua la descripción de los patrones de arquitectura. Se exploran otros patrones de arquitectura propuesto por Limoncelli [4].

 

2. Patrones de Arquitectura

Los patrones arquitectónicos [3] dan una descripción de los elementos y el tipo de relación que tienen junto con un conjunto de restricciones. Un patrón arquitectónico expresa un esquema de organización estructural esencial para un sistema de software, que consta de subsistemas, sus responsabilidades e interrelaciones. No son necesariamente soluciones completas en sí mismas, sino que ofrecen conocimientos parciales que, cuando se combinan con otros patrones, llevan al diseñador a una solución para un dominio de problema dado.

Otros Patrones.  Balanceador de carga con réplicas (backend)

 En  [4], el autor presenta una clasificación de las arquitecturas de los sistemas distribuidos basada en patrones. Estos patrones forman parte de la estructura de los sistemas distribuidos, considere que los mismos están compuesto por múltiples componentes que aportan la funcionalidad que presentan los sistemas distribuidos, como la disponibilidad  y escalamiento de servicios. Se detallan tres patrones en particular: 

•  Balanceador de carga con múltiples réplicas  

  Los patrones que se muestran a partir de este, son parte de la estructura de los sistemas distribuidos presentados en [4]. En el patrón de composición del balanceador de carga con múltiples réplicas , ver la Figura 1, las solicitudes se envían al servidor del equilibrador de carga. Para cada solicitud, selecciona una replica (backend) y se reenvía la solicitud allí. La respuesta vuelve al servidor del equilibrador de carga, que a su vez la transmite al solicitante original.  Una solicitud enviada a cualquier réplica debería producir la misma respuesta.

 

Figura 1. Balanceador de Cargas con replicas. Tomado de [4]

• Servidor con varios réplicas

   

  El siguiente patrón de composición es un servidor con múltiples réplicas o  backends. El servidor recibe una solicitud, envía consultas a muchos servidores réplicas y redacta la respuesta final combinando esas respuestas. Este enfoque se utiliza normalmente cuando la consulta original se puede descomponer  en una serie de consultas independientes que se pueden combinar para formar la respuesta final.

 

Figura 2. Balanceador de Cargas. Tomado de [4]

La Figura 2 de la izquierda ilustra cómo un motor de búsqueda simple procesa una consulta con la ayuda de múltiples respaldos. La interfaz recibe la solicitud. Transmite la consulta a varios servidores respaldos.

 

Si la búsqueda es textual, el corrector ortográfico responde con información para que el motor de búsqueda sugiera ortografías alternativas. Los backends de búsqueda de imágenes y web responden con una lista de sitios web e imágenes relacionadas con la consulta.  Una vez que se reciben las respuestas, la interfaz utiliza esta información para construir el HTML que forma la página de resultados de búsqueda para el usuario, que  se envía como respuesta.

 La Figura [2],esquina derecha,  ilustra la misma arquitectura con backends replicados y con equilibrio de carga. Se aplica el mismo principio, pero el sistema puede escalar y sobrevivir mejor a las fallas.

 

• Árbol de servidores.

  El otro patrón de composición fundamental es el árbol de servidores. Como ilustra la Figura 3, en este esquema varios servidores trabajan en cooperación con uno como la raíz del árbol, los servidores padres debajo de él y los servidores hoja en la parte inferior del árbol. 

 

Este patrón se utiliza para acceder a un gran conjunto de datos o corpus. Cada hoja almacena una fracción de los datos. La raíz recibe la consulta original y la reenvía a los padres, quienes la reenvían  a los servidores hoja. Cada hoja envía sus hallazgos a los padres, que clasifican y filtran los resultados antes de enviarlos a la raíz. La raíz toma las respuestas, combina los resultados y responde.

 

Figura 3. Servidores Replicados. Tomado de [4]

3.Soluciones basadas en middleware.

La tarea del  middleware es proporcionar un nivel superior abstracción de programación para el desarrollo de sistemas distribuidos y, con las capas,  abstraer la heterogeneidad en la infraestructura subyacente para promover  interoperabilidad y portabilidad. Ademas de la soluciones de middleware presentados ,  también  hay arquitecturas más complejas como las siguientes:  

• Objetos Distribuidos: Corba, Java RMI;   
• Componentes distribuidos: Fractal; 
• Servidores de aplicaciones: Sun EJB, JBoss
• Servicios Web: Apache Axis
• Publicación-suscripción: Event Service, JMS
• Colas de mensajes: Websphere MQ
• Peer-to-peer: PASTRY, Tapestry, OceanStore, Gnutella

 

Bibliografía

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

    [2]Christina J. Hogan Thomas A. Limoncelli Strata R. Chalup. The Practice ofCloud System Administration: Designing and Operating Large Distributed Systems. Volume 2. Addison Wesley, 2014.

    [3]Roger S. Pressman and Bruce R. Maxim. Software Engineering: A Practitioner’s Approach. 9th edition. McGraw-Hill Education, 2019.

    [4] Christina J. Hogan Thomas A. Limoncelli Strata R. Chalup. The Practice of Cloud System Administration: Designing and Operating Large Distributed Systems. Volume 2. Addison Wesley, 2014.