Colas.

    Mientras que los grupos y publicación-suscripción proporcionan un estilo de comunicación de uno a varios, las colas de mensajes proporcionan un servicio punto a punto utilizando el concepto de cola de mensajes como una indirección, logrando así las propiedades deseadas de desacoplamiento de espacio y tiempo. Son punto a punto en el sentido de que el remitente coloca el mensaje en una cola y luego es eliminado por un solo proceso. Las colas de mensajes también se conocen como Middleware orientado a mensajes.

  Modelo de programación

    El modelo de programación, figura 1, que ofrecen las colas de mensajes es muy sencillo. Ofrece un acercamiento a la comunicación en sistemas distribuidos a través de colas. En particular, los procesos productores pueden enviar mensajes a una cola específica y otros procesos (consumidores) pueden recibir mensajes de esta cola. Se admiten tres estilos de recepción: 

• una recepción con bloqueo, que se bloqueará hasta que esté disponible un mensaje apropiado; 
• una recepción sin bloqueo (una operación de sondeo), que verificará el estado de la cola y devolverá un mensaje si está disponible, o una indicación de no disponible en caso contrario; 
• una operación de notificación, que emitirá una notificación de evento cuando un mensaje esté disponible en la cola asociada. 

Figure 1: Modelo de Programación.

 Características

    Entre sus características: 

• Varios procesos pueden enviar mensajes a la misma cola y, del mismo modo, varios receptores pueden eliminar mensajes de una cola.  
• La política de colas es el primero en entrar, primero en salir (FIFO), pero la mayoría  de las implementaciones de colas de mensajes también admiten el concepto de prioridad, con los mensajes de mayor prioridad entregados primero. Los procesos de consumidor también pueden seleccionar mensajes de la cola según las propiedades de un mensaje.  
• Un mensaje consta de un destino ( un identificador único que designa la cola de destino), metadatos asociados con el mensaje, incluidos campos como la prioridad del mensaje y el modo de entrega, y también el cuerpo del mensaje.  Los mensajes son persistentes, es decir, las colas de mensajes almacenarán los mensajes indefinidamente (hasta que se consuman) y también enviarán los mensajes al disco para permitir una entrega confiable. 
• Cualquier mensaje enviado se recibe eventualmente (validez) y el mensaje recibido es idéntico al enviado, y ningún mensaje se entrega dos veces (integridad). Por lo tanto, los sistemas de cola de mensajes garantizan que los mensajes se entregarán (y se entregarán una vez), pero no pueden decir nada sobre el momento de la entrega.

 

Bibliografia:

[1] Sasu Tarkoma. Publish/Subscribe Systems: Design and Principles. Edited by Joe

Sventek David Hutchison Serge Fdida. 2012. 

[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

Implementar sistema Publicación Suscripción.

 Consideraciones para Implementar sistema Publicación Suscripción.

Centralizadas 

    El procesamiento de eventos y notificaciones se puede implementar fácilmente en editores y con un intermediario centralizado, ver Figura 1.

En la implementación centralizada, ocurre que: 

• El enfoque más simple es centralizar la implementación en un solo nodo con un  servidor en ese nodo que actúa como un intermediario de eventos. 
• Los publicadores publican eventos y (opcionalmente) envían anuncios al corredor, y  los suscriptores envían suscripciones al corredor y reciben notificaciones a cambio. 
• La interacción con el corredor se realiza a través de una serie de mensajes punto a punto; esto se puede implementar mediante el paso de mensajes o la invocación remota.

Figura 1: Modelo  Publicación-Susbcripción centralizado.

    Este enfoque es sencillo de implementar, pero el diseño carece de resiliencia y escalabilidad, ya que el nodo centralizado representa un punto único de posibles fallas del sistema y es probable que sea un cuello de botella para el rendimiento.

Distribuidas

     En este esquema, el nodo centralizado es reemplazado por una red de corredores que cooperan para ofrecer la funcionalidad deseada. En la visión distribuida, el sistema pub-sub distribuido se implementa como una red de intermediarios o enrutadores en la capa de aplicación que se comunican mediante el uso de las primitivas de capa inferior, normalmente TCP/IP. En la Figura 2 se esquematiza una red pub-sub distribuida donde cada componente de la red de corredores son componentes intermediarios o enrutadores.

    Dicho enfoque tienen el potencial de sobrevivir a las fallas de los nodos y se ha demostrado que pueden funcionar bien en implementaciones a escala de Internet. Como alternativa, es posible tener una implementación completamente nodo-a-nodo (peer-to- peer)  de un sistema de publicación-suscripción. 

    En este enfoque, no hay distinción entre editores, suscriptores y corredores; todos los nodos actúan como intermediarios, implementando de manera cooperativa la funcionalidad de enrutamiento de los eventos requeridos

Figura 2: Publicación-Subscripción distribuido. Tomado de [2]

 Enfoques de Implementación 

Existe una variedad de enfoques de implementación [1] [2]:

• Inundación (Flooding) el enfoque más simple se basa en Inundación. Opera de la siguiente manera:  
• Se envía una notificación de evento a todos los nodos de la red y luego se realiza el emparejamiento con el suscriptor del evento. 
• Como alternativa, la inundación se puede utilizar para enviar suscripciones a todos los posibles publicadores; la coincidencia se realiza en el publicador y los eventos coincidentes se envían directamente a los suscriptores relevantes mediante la comunicación punto a punto. La inundación se puede implementar utilizando una función de difusión o multidifusión subyacente.  
• Alternativamente, los intermediarios pueden organizarse en un gráfico acíclico en el que cada uno envía notificaciones de eventos entrantes a todos sus vecinos.  

Este enfoque tiene el beneficio de la simplicidad, pero puede resultar en una gran cantidad innecesaria de tráfico de red. 

• Filtrado : Se conoce como enrutamiento basado en filtrado. Los corredores envían notificaciones a través de la red solo donde hay una ruta a un suscriptor válido. Funciona así: 
• La propagación de la información de suscripción se realiza a través de la red hacia los editores potenciales y luego se almacena el estado asociado en cada corredor. 
•  Específicamente, cada nodo debe mantener una lista de vecinos que contenga a todos los vecinos conectados en la red de corredores, una lista de suscripción que contenga todos los suscriptores conectados directamente atendidos por este nodo, y una tabla de enrutamiento. Esta tabla de enrutamiento mantiene una lista de vecinos y suscripciones válidas para ese camino. 
• Este enfoque exige una implementación de la coincidencia en cada nodo en la red de corredores: en particular, en la función de coincidencia lleva a cabo la notificación de eventos y una lista de nodo junto con la suscripción y las devoluciones asociadas en el conjunto de nodos donde la notificación coincide con la suscripción.  

El algoritmo específico para este enfoque de filtrado se captura en las Figura 3 y opera de la siguiente manera:

• Cuando un corredor recibe en la solicitud de publicación de un nodo dado, debe pasar esta notificación a todos los nodos conectados donde hay una suscripción con coincidencia al evento y también decide dónde propagar este evento a través de la red de corredores.
• Las  líneas 2 y 3 logran el primer objetivo al igualar el evento contra la lista de suscripción y luego reenviar el evento a todos los nodos con suscripciones coincidentes (la lista de coincidencias). 
• Las  líneas 4 y 5 luego usan la función de coincidencia nuevamente, esta vez coincide con el evento contra la tabla de enrutamiento y reenvía solo a las rutas que conducen a una suscripción (la Lista FWD).  
• Los corredores también deben lidiar con los eventos de suscripción entrantes.  Si el evento de suscripción es de un suscriptor inmediato conectado, entonces esta suscripción se registra en la tabla de suscripciones (líneas 7 y 8).  
• De  lo contrario, el corredor es un nodo intermediario; Este nodo ahora sabe que existe un camino hacia esta suscripción y, por lo tanto, se agrega una entrada apropiada a la tabla de enrutamiento (línea 9).
• En ambos casos, este evento de suscripción se pasa a todos los vecinos aparte del nodo de origen (línea 10).

Figura 3: Algoritmo de Filtrado. Tomado de [2]

 

• Encuentros (Rendezvous) :

Para comprender este enfoque, es necesario ver el conjunto de todos los eventos posibles como un espacio de eventos y dividir la responsabilidad de este espacio de eventos entre el conjunto de agentes de la red. En particular, este enfoque define los nodos de encuentro, que son nodos intermediarios responsables de un subconjunto determinado del espacio de eventos. Para lograr esto, un algoritmo de enrutamiento basado en encuentros debe definir dos funciones: 

• En primer lugar, SN toma una suscripción determinada, s, y devuelve uno o más nodos de encuentro que asumen la responsabilidad de esa suscripción. Cada uno de estos nodos de encuentro mantiene una lista de suscripción como en el método de filtrado anterior, y reenvía todos los eventos coincidentes al conjunto de nodos de suscripción. 
• En segundo lugar, cuando se publica un evento e, la función EN(e) también devuelve uno o más nodos de encuentro, esta vez que corresponde a la coincidencia del evento e con las suscripciones en el sistema. 
• Tenga en cuenta que tanto SN(s) como EN(e) devuelven más de un nodo si la confiabilidad es un problema.  
• Tenga en cuenta también que este enfoque solo funciona si la intersección de SN(s) y EN(e) no está vacía para una e dada que coincide con s. El código correspondiente para el enrutamiento basado en citas se muestra en la Figura 4. 

Figura 4: Algoritmo de Encuentros. Tomado de [2]

Bibliografia:

[1] Sasu Tarkoma. Publish/Subscribe Systems: Design and Principles. Edited by Joe

Sventek David Hutchison Serge Fdida. 2012. 

[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

 Publicación - Suscripción

    Las principales entidades en un sistema publicación-suscripción son los editores y suscriptores de contenido [1]. Un publicador (publisher) detecta un evento y luego lo publica en forma de notificación. Una notificación encapsula información relacionada con el evento observado. La notificación denota que ha ocurrido un evento observado. Un evento representa cualquier transición de estado discreta que ha ocurrido y se señala desde una entidad a un número de otras entidades.

    Un suscriptor, por ejemplo, podría expresar interés en todos los eventos relacionados con este libro de texto, como la disponibilidad de una nueva edición o actualizaciones del sitio web relacionado. La tarea del sistema de publicación y suscripción es hacer coincidir las suscripciones con los eventos publicados y garantizar la entrega correcta de las notificaciones de eventos. Un evento dado se entregará potencialmente a muchos suscriptores y, por lo tanto, en publicación y suscripción se usan paradigmas de comunicaciones de uno a muchos.

Aplicaciones de los sistemas de publicación-suscripción

Los sistemas de publicación-suscripción se utilizan en una variedad de dominios de aplicación, en particular los relacionados con la difusión de eventos a gran escala. Ejemplos  incluyen [1]:

• GUI, en las que los sistemas pub/sub se aplica como el pegamento que conecta los diversos componentes entre sí. Un ejemplo es el patrón de diseño MVC (Modelo Vista Controlador) muy utilizado en GUIs y su componente el patrón de observador.  

• Push de información, en el que se publica el contenido al usuario. Este es un requisito para aplicaciones que dependen de datos en tiempo real o casi en tiempo real. 

• Filtrado de información y entrega dirigida utilizada por los servicios de alerta y presencia (Google Alerts, etc.), tiendas de aplicaciones, servicios de corretaje de RSS, etc. Los ejemplos incluyen XMPP Pub/sub, Pubsubhubbub, Facebook  Messenger and Chat y Twitter.  

• Plano de señalización, en el que pub/sub asegura que los eventos asíncronos se entregan en en tiempo real o casi en tiempo real desde la publicación de componentes hasta la suscripción de componentes. Las aplicaciones de ejemplo incluyen sistemas industriales y tácticos. DDS (Data Distribution Systems) es el estándar clave para estos sistemas.  

• La arquitectura orientada a servicios (SOA) y las aplicaciones comerciales se basan en publicación/suscripción en el bus de servicios empresariales (ESB). El ESB normalmente se implementa con un broker de mensaje XML.  

• Procesamiento de Eventos Complejos (CEP) para análisis de datos. CEP se utiliza ampliamente en varios aplicaciones comerciales, por ejemplo, comercio algorítmico y detección de fallas. 

• Computación en la nube, en la que pub/sub y colas de mensajes se utilizan para conectar los componentes de la nube. 

• Internet de las cosas, en el que pub/sub conecta los sensores y actuadores entre sí con recursos de Internet.  

• Juegos multijugador en línea, en los que pub/sub se usa para sincronizar el estado del juego en jugadores y servidores

Modelo de Programación

    El modelo de programación en los sistemas de publicación-suscripción se basa en un pequeño conjunto de operaciones, ver Figura 1. Los editores difunden un evento e a  través de una operación de publicacion(e) y los suscriptores expresan su interés en un conjunto de eventos a través de suscripciones. En particular, logran esto a través de una operación de suscripcion( f ) donde f se refiere a un filtro, es decir, un patrón definido sobre el conjunto de todos los eventos posibles.

Figura 1: Paradigma Publicación Suscripción

    La expresividad de los filtros está determinada por modelo de la suscripción. Los suscriptores pueden revocar este interés mediante la correspondiente operación de cancelacion−suscripcion( f ). Cuando los eventos llegan a un suscriptor, los eventos se entregan usando una operación de notificacion(e).

    Algunos sistemas complementan el conjunto de operaciones anuncios. Con los anuncios, 

los editores tienen la opción de declarar la naturaleza de los eventos futuros a través de una operación de anuncios( f ). 

Modelo de Subscripción 

    La expresividad de los sistemas de publicación-suscripción está determinada por el modelo de suscripción, que cuentan con una serie de esquemas o filtros [1] [2]:

• Basado en canales : en este enfoque, los editores publican eventos en canales con nombre y los suscriptores luego se suscriben a uno de estos canales para recibir todos los eventos enviados a ese canal. Este esquema es el único que se define en un canal físico. 

• Basado en temas : se asume que cada notificación se expresa en términos de varios campos, con un campo que denota el tema. Las suscripciones se definen en función del tema de interés. Este enfoque es equivalente a los enfoques basados en canales con la diferencia de que los temas se definen implícitamente, pero se declaran como parte de un campo en el enfoque basados en temas. 

• Basado en contenidos : son una generalización de enfoques basados en temas que permiten la expresión de suscripciones en una variedad de campos en solo una notificación del evento. Más específicamente, un filtro basado en contenido es una consulta definida en términos de composiciones de restricciones sobre los valores de los atributos del evento. Por ejemplo, un suscriptor podría expresar interés en eventos relacionados con el tema de los sistemas de publicación-suscripción, donde el sistema en cuestión es el Servicio de eventos CORBA y el autor es Tim Kindberg o Gordon Blair.  

• Basado en tipo : las suscripciones se definen en términos de tipos de eventos y la coincidencia se define en términos de tipos o subtipos del filtro dado. Este enfoque puede expresar una variedad de filtros, desde un filtrado basado en nombres de tipo generales hasta consultas más detalladas que definen atributos y métodos de un objeto dado. Estos filtros detallados son similares en expresividad a los enfoques basados en contenido.

Bibliografia:

[1] Sasu Tarkoma. Publish/Subscribe Systems: Design and Principles. Edited by Joe

Sventek David Hutchison Serge Fdida. 2012. 

[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

 Grupos.

    La comunicación grupal es una abstracción sobre la comunicación de multidifusión y se

puede implementar a través de multidifusión IP o una red de superposición equivalente,

teniendo como valor adicional la gestión de pertenencia al grupo, detección de fallas y

garantía de confiabilidad y pedidos, [1] [2].

Modelo de Programación

    En la comunicación grupal, el concepto central es el de un grupo con una membresía de

grupo asociada y con los procesos de unirse o salir del grupo ver Figura 1. Los procesos pueden enviar un mensaje a este grupo y hacer que se propague a todos los miembros (o a un miembro) del grupo con ciertas garantías en términos de confiabilidad y orden. Así, la comunicación de grupo implementa la comunicación de multidifusión, así como también la comunicación unidifusión.

    El uso de una única operación de envío permite un uso eficiente del ancho de banda. También es relevante en términos de garantías de entrega del mensaje ya que la operación de envío del mensaje se asocia a un proceso. Si ocurre una falla y algún mensaje no se entrega, se puede implementar el reenvio de mensajes. 

Figure 1: Modelo de Programación. Adaptado de [2]

 Membresía del Grupo

Un servicio de membresía grupal tiene cuatro tareas principales:

• Interfaz para cambios de membresía de grupo : el servicio de membresía proporciona operaciones para crear/destruir grupos de procesos y para agregar/retirar un proceso hacia o desde un grupo. En la mayoría de los sistemas, un solo proceso puede pertenecer a varios grupos al mismo tiempo (grupos superpuestos ).  

• Detección de fallas : el servicio monitorea a los miembros del grupo no solo en caso de que se bloqueen, sino también en caso de que se vuelvan inaccesibles debido a una falla de comunicación. El detector marca los procesos como sospechosos o no sospechosos. El servicio utiliza el detector de fallas para tomar una decisión sobre la situación de la membresía del grupo: excluye un proceso de la membresía si se sospecha que ha fallado o si se ha vuelto inalcanzable. 

• Notificación de cambios en la membresía del grupo : el servicio notifica al los miembros del grupo cuando se agrega un proceso, o cuando se excluye un proceso (por falla o cuando el proceso se retira deliberadamente del grupo). 

• Difusión de direcciones de grupo : cuando un proceso difunde un mensaje en forma múltiple, proporciona el identificador de grupo en lugar de una lista de procesos del grupo. El servicio de administración de membresía expande el identificador a la membresía del grupo actual para su entrega. El servicio puede coordinar la entrega de multidifusión con cambios de membresía controlando la expansión de direcciones. Es decir, puede decidir sistemáticamente dónde enviar un mensaje determinado, aunque la membresía pueda cambiar durante la entrega

Características de la arquitectura de Grupos

• Grupos de procesos La mayor parte del trabajo en servicios grupales se centra en grupos donde las entidades comunicantes son Procesos. El nivel de servicio proporcionado por los grupos de procesos es similar al de los sockets. 

• Grupos de objetos Es una colección de objetos (instancias de la misma clase) que procesan el mismo conjunto de invocaciones al mismo tiempo, y cada una devuelve respuestas. Los clientes invocan operaciones en un único objeto local, que actúa como proxy del grupo. El proxy utiliza un sistema de comunicación grupal para enviar las invocaciones a los miembros del grupo de objetos. Los parámetros de objeto y los resultados se empaquetan como en RMI y las llamadas asociadas se envían automáticamente a los objetos/métodos de destino. 

• Grupos abiertos Un grupo está abierto si los procesos fuera del grupo pueden enviarle mensajes, Figura 2. Los grupos abiertos son útiles, por ejemplo, para entregar mensajes a grupos de procesos interesados.  

• Grupos cerrados Se dice que el grupo está cerrado si solo los miembros del grupo pueden enviar mensajes multidifusión. Un proceso en un grupo cerrado se entrega a sí mismo cualquier mensaje que difunde al grupo, ver Figura 2. Los grupos cerrados de procesos son útiles, por ejemplo, para servidores que cooperan para enviarse mensajes entre sí que solo ellos deberían recibir.  

• Grupos Superpuestos Entidades (procesos u objetos) pueden ser miembros de varios grupos  

• Grupos no Superpuestos Implican que la membresía no se superpone (es decir, cualquier proceso pertenece como máximo a un grupo)

Figure 2: Grupos cerrados y abiertos. Adaptado de [2]

Confiabilidad y ordenamiento en multidifusión

Otras características atribuida a los grupos esta la confiabilidad y el ordenamiento de los

mensajes:

• Confiabiliad La confiabilidad en la comunicación se ha definido en términos de las siguientes propiedades:
• Integridad El mensaje recibido es el mismo que el enviado, y no se entregan dos veces. Validez Cualquier mensaje saliente es eventualmente entregado. La interpretación de multidifusión confiable se basa en estas propiedades, con integridad definida en términos de entregar el mensaje correctamente como máximo una vez, y la validez interpretado como que garantiza que un mensaje enviado finalmente será entregado. 
• Acuerdo Para extender la semántica y cubrir la entrega a múltiples receptores, la propiedad acuerdo indica que si el mensaje se entrega a un proceso, entonces se entrega a todos los procesos del grupo. 

• Ordenamiento Además de las garantías de fiabilidad, la comunicación grupal exige garantías adicionales en términos del orden relativo de los mensajes entregados a múltiples destinos. Para contrarrestar los retrasos y desorden en la entrega, los servicios de comunicación grupal ofrecen multidifusión ordenada, con la opción de una o más de las siguientes propiedades: 
• Orden FIFO : ordenamiento primero en entrar, primero en salir (FIFO) se ocupa de preservar el pedido desde la perspectiva del remitente del proceso, en el sentido de que si un proceso envía un mensaje antes que otro, se entregará en este orden en todos los procesos del grupo.  
• Ordenamiento causal : el ordenamiento causal tiene en cuenta las relaciones causales entre mensajes, en el sentido de que si un mensaje ocurre antes que otro mensaje en el sistema distribuido, esta relación causal se conservará en la entrega de los mensajes asociados en todos los procesos  
• Ordenamiento total : En el orden total, si un mensaje se entrega antes que otro mensaje en un proceso, se conservará el mismo orden en todos los procesos.

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

Comunicación Indirecta. 

    En la comunicación indirecta la naturaleza del intermediario y del acoplamiento varían de

un enfoque a otro y entre sistemas: se puede establecer conceptos de acoplamiento tanto

temporal como espacial que determinan como el receptor y el emisor coinciden o no en el

tiempo y en espacio.

    En la tabla 1 se plasman las posibles variantes en este tipo de enfoque. Por ejemplo,

las técnicas consideradas hasta ahora se basan en un acoplamiento directo o sistemas fuertemente

acoplado, como las arquitecturas clientes-servidor. Son arquitecturas acopladas en tiempo y espacio. Por otra parte, las aplicaciones como el correo electrónico, son arquitecturas desacopladas en tiempo y acopladas en espacio, ver descripción en la parte superior, derecha de la tabla 1.

Tabla 1. Acoplamiento en Espacio y Tiempo. Adaptado de [2]

    Mientras que la multidifusión puede catalogarse como arquitecturas acoplada en tiempo,

desacopladas en espacio, descrita en la parte inferior e izquierda de la tabla 1. Y las arquitecturas que calzan en la categoría de desacoplamiento en espacio y tiempo, como las arquitecturas Pub-sub y colas de mensajes, ubicada en la parte inferior, derecha.

Acoplamiento

    El acoplamiento se define como la fuerza de la interconexión entre dos módulos de software:

cuanto mayor es la fuerza de la interconexión, mayor es el acoplamiento. Para que el software sea más fácil de entender, corregir y mantener, un sistema debe estar dividido de modo que el acoplamiento entre los módulos sea lo más flojo o débil posible.

    Un sistema débilmente acoplado es aquel sistema donde  cada componente tiene poco o ningún conocimiento de las partes internas de los otros componentes. Por su parte,  el sistema tiene acoplamiento fuerte si cada componente de un sistema tiene conocimiento de partes de los otros componentes, como memoria común, almacenamiento secundario, entrada y salida de datos.

    El concepto de Acoplamiento fue propuesto por Yourdon y Constantine en su libro,

Structured Design: Fundamentals of a Discipline of Computer Program and Systems

Design.

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

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