Computación Orientada a Servicios

Un servicio [1] es una abstracción que representa un componente autodescriptivo e independiente de la plataforma y que puede realizar cualquier función, desde una función simple hasta un proceso comercial complejo. Prácticamente cualquier pieza de código que realice una tarea se puede convertir en un servicio y exponer sus funcionalidades a través de un protocolo accesible en red. 

Las características relevante del servicio es que está débilmente acoplado, es reutilizable, es independiente del lenguaje de programación y tiene una ubicación transparente. El bajo acoplamiento permite que los servicios sirvan a diferentes escenarios más fácilmente y los hace reutilizables. La independencia de una plataforma específica aumenta la accesibilidad de los servicios. Por lo tanto, se puede atender a una gama más amplia de clientes, que pueden buscar servicios en registros globales y consumirlos de manera transparente en cuanto a la ubicación. 

La orientación a servicios [2] es un paradigma de diseño destinado a la creación de unidades de soluciones lógicas que tienen forma individual, para que puedan utilizarse colectiva y repetidamente  con el propósito de respaldar la realización de los objetivos y beneficios estratégicos específicos asociados con la arquitectura orientada a servicios SOA y la informática orientada a servicios. La solución lógica diseñada de acuerdo con la orientación a servicios se puede calificar como orientada a servicios, y las unidades de solución  lógica orientada a servicios se denominan servicios.

Los servicios se componen y agregan en una arquitectura orientada a servicios (SOA), que es una forma lógica de organizar los sistemas de software para proporcionar a los usuarios finales u otras entidades distribuidas en la red servicios a través de interfaces publicadas y detectables. SOA establece un modelo arquitectónico orientado a mejorar la eficiencia, la agilidad y la productividad de una empresa mediante el uso de la informática orientada a servicios. Una implementación de SOA puede consistir en una combinación de tecnologías, productos, API, infraestructura de soporte y otros elementos.

La  computación orientada a servicios (COS) [2] representa una plataforma informática distribuida de nueva generación.  Como tal, abarca muchas cosas, incluido su propio paradigma de diseño y principios de diseño, catálogos de patrones de diseño, lenguajes de patrones, un modelo arquitectónico distinto y conceptos, tecnologías y marcos relacionados. COS introduce y difunde dos conceptos importantes, que también son fundamentales para la computación en la nube[1]: la calidad de servicio (QoS) y el software como servicio (SaaS):

• QoS identifica un conjunto de atributos funcionales y no funcionales que se pueden utilizar para evaluar el comportamiento de un servicio desde diferentes perspectivas. Estas podrían ser métricas de rendimiento como el tiempo de respuesta o los atributos de seguridad, la integridad transaccional, la confiabilidad, la escalabilidad y la disponibilidad.
• SaaS  introduce un nuevo modelo de entrega de aplicaciones.  El enfoque de SaaS alcanza su pleno desarrollo con la computación orientada a servicios (SOC), donde los componentes de software débilmente acoplados pueden exponerse y cotizarse individualmente, en lugar de aplicaciones completas. Esto permite la entrega de procesos comerciales complejos y transacciones como un servicio, al tiempo que permite que las aplicaciones se compongan sobre la marcha y los servicios se reutilicen desde cualquier lugar y por cualquier persona.

La orientación al servicio es el modelo de referencia central para los sistemas de computación en la nube. Este enfoque adopta el concepto de servicios como los principales componentes básicos del desarrollo de aplicaciones y sistemas. La computación orientada a servicios  admite el desarrollo de aplicaciones y sistemas rápidos, de bajo costo, flexibles, interoperables y evolutivos.

Una de las expresiones más populares de orientación a servicios está representada por los servicios web (WS)[1] . Estos introducen los conceptos de COS  en la World Wide Web, haciéndola consumible por aplicaciones y no solo por humanos. Los servicios web son componentes de software que exponen funcionalidades accesibles mediante un patrón de invocación de métodos que pasa por el Protocolo de transferencia de hipertexto (HTTP). La interfaz de un servicio web se puede inferir programáticamente mediante metadatos expresados ​​a través del lenguaje de descripción de servicios web (WSDL); este es un lenguaje XML que define las características del servicio y todos los métodos, junto con los parámetros, descripciones y tipo de retorno, expuestos por el servicio.  La interacción con los servicios web ocurre a través del Protocolo simple de acceso a objetos (SOAP). Este es un lenguaje XML que define cómo invocar un método de servicio web y recopilar el resultado.

 Usando SOAP y WSDL sobre HTTP, los servicios web se vuelven independientes de la plataforma y accesibles para la World Wide Web. Los estándares y especificaciones relativos a los servicios web están controlados por el World Wide Web Consortium (W3C). 

Referencias

1. Buyya, R., Vecchiola, C., & Selvi, S. T.,  Mastering Cloud Computing, Mc Graw Hill India, 2013, ISBN 9781259029950.
2. Thomas Erl, Service Oriented Architecture: Principles of Service Design. The Prentice Hall Service-Oriented Computing Series by Thomas Erl. 2007 
3. Coulouris, George F. Distributed Systems: Concepts and Design. Boston: Addison-Wesley, 2012.
4. Tanenbaum, Andrew S., and Maarten van Steen. Distributed Systems: Principles and Paradigms. Upper Saddle River, NJ: Pearson Prentice Hall, 2007. 
5. Rodrigues, Luís and Veríssimo, Paulo. Advances in Distributed Computing and Middleware. 
6. Salas, A., Marquez, A. Arquitectura orientada a Microservicios aplicada a un sistema de Comercio Electrónico. Trabajo de Grado de Pregrado, UNEG. 2017.

Cola de Mensajes y Microservicios

 Cola de Mensajes

Una cola de mensaje es un protocolo de comunicaciones asíncrono, el cual consiste en comunicar dos procesos separados mediante una cola (de mensajes) la cual incluye una secuencia de objetos creados por el emisor (productor)  esperando ser procesados por el proceso que lo consumirá (consumidor). Un sistema que pone un mensaje en una cola de mensajes no requiere una respuesta inmediata para continuar el procesamiento. 

 Una cola de mensajes ofrece un búfer ligero que almacena temporalmente los mensajes, y puntos de enlace que permiten a los componentes de software conectarse a la cola para enviar y recibir mensajes.  ver Figura 1.

1. Cola de Mensajes

Existen varias soluciones para protocolos de colas de mensajes: AMQP, MQTT, STOMP. Veamos las características de AMQP.

Protocolos de Colas de Mensaje AMQP

AMQP (Advanced Message Queuing Protocol). El protocolo AMQP opera de la siguiente manera: por un lado, el protocolo (en colaboración con un bróker de mensajería) se encarga de una transmisión de datos. Por otro, AMQP permite almacenar mensajes en una cola. Esto, a su vez, permite una comunicación asíncrona: transmisor y receptor no deben actuar al mismo ritmo. El receptor (consumidor) recuperará el mensaje de la cola cuando tenga capacidad disponible para ello ( el receptor  no tiene por qué aceptar el procesamiento de la información  ni la confirmación de la recepción al emisor).  Esto ofrece al productor (publicador), entre otras cosas, la posibilidad de seguir trabajando y se evitan los tiempos de inactividad.  Ver Figura 2.

2. Protocolo AMQP

En AMQP. el mensaje es el elemento central de comunicación y además de una serie de elementos:

• El productor o publicador (publisher) crea un mensaje, lo envía y es publicado en un buzón (exchange).
• El servidor (bróker de mensajería) distribuye o enruta el mensaje desde el buzón de acuerdo con unas reglas definidas (bindings) en diferentes colas (queue).
• El consumidor (consumer) recupera el mensaje de la cola a la que está suscrito.

El buzón o intercambiador (exchange) recibe los mensajes y dirige los datos a una cola utilizando una vinculación (binding) que le permite decidir cuál es la correcta. 

El bróker interrumpe la difusión del mensaje una vez más: el intercambiador recibe los mensajes y dirige los datos a la cola correcta. La vinculación informa al intercambiador sobre la cola a la que pertenece el mensaje. 

Cola de Mensajes y Microservicios

Una cola de mensajes es una forma de comunicación asíncrona que se usa en arquitecturas de microservicios. Los mensajes se almacenan en la cola hasta que se reciben y, luego se eliminan,  siendo cada mensaje procesado una sola vez.

Esta estructura intermedia permite ajustar la velocidad y disponibilidad de diferentes microservicios de forma que puedan trabajar conjuntamente y puedan recuperarse de los errores, lo que aumenta el nivel de tolerancia a fallos. 

La siguiente figura, Figura 3, muestra la arquitectura propuesta para una aplicación de comercio electrónico, usando microservicios. Los microservicios proyectados son: Facturación, Notificaciones, Pagos, Gestión de Cuenta, Archivos y Reportes. Cada microservicio tiene una  interfaz pública, API. El API Gateway, es un microservicio adicional que opera como un balanceador de cargas.

3.  Arquitectura de Aplicación de Comercio Electrónico. Tomado de  [4].

Cuando se usa el patrón de mensaje publicador/subscriptor y la topología de comunicación AMQP , el publicador envía un mensaje al destinatario con un tópico. La habilidad del publicador de poner el mensaje es independiente de la disponibilidad de la aplicación subscriptora. 

La cola de mensaje actúa como intermediario, y es responsable de entregar el mensaje a los subscriptores.  En cualquier momento, el subscriptor podría no estar disponible, por lo que la cola de mensaje puede retener el mensaje hasta que el subscriptor sea capaz de consumirlo, esto puede servir como un mecanismo de comunicación resistente a fallas entre los servicios involucrados.

Si un proceso en un sistema desacoplado falla  al procesar mensajes de la cola, otros mensajes pueden agregarse a la cola y procesarse cuando el sistema se haya recuperado.  

En la figura 3, el API Gateway y  Orden, poseen un adaptador para trabajar con cola de mensajes ( con RabbitMQ ). Este adaptador les provee acceso a un servidor de cola de mensajes, en el cual pueden publicar información en caso de que ocurra algún error en la comunicación. En tal sentido, el API Gateway al recibir un mensaje de error cuando se comunica con  Orden, guarda la información en la cola. Dicha información será leída de la cola de mensaje cuando el microservicio Orden esté disponible nuevamente, y de esta manera pueda continuar con el flujo del proceso.

El mismo mecanismo de cola de mensaje se utiliza entre el microservicio de Notificación y el de Usuario:  cuando el microservicio de Notificación hace el llamado asíncrono a un método del microservicio de Usuario  , y por algún error o falla el microservicio de Usuario no está disponible, el microservicio Notificación publicará un mensaje en la cola de mensajes. Cuando el microservicio Usuario esté disponible, automáticamente leerá la cola de mensaje para resolver las llamadas a funciones que estén en la cola.

Referencias

1. Coulouris, George F. Distributed Systems: Concepts and Design. Boston: Addison-Wesley, 2012.
2. Tanenbaum, Andrew S., and Maarten van Steen. Distributed Systems: Principles and Paradigms. Upper Saddle River, NJ: Pearson Prentice Hall, 2007. 
3. Rodrigues, Luís and Veríssimo, Paulo. Advances in Distributed Computing and Middleware. 
4. Salas, A., Marquez, A. Arquitectura orientada a Microservicios aplicada a un sistema de Comercio Electrónico. Trabajo de Grado de Pregrado, UNEG. 2017.
5. Protocolo AMQP
6. Microservicios y Colas de Mensajes
7. Cola de Mensajes

Memoria Compartida Distribuida

La memoria compartida distribuida (DSM) [1] es una abstracción utilizada para compartir datos entre computadoras que no comparten memoria física. Los procesos acceden a DSM mediante lecturas y actualizaciones de lo que parece ser la memoria ordinaria dentro de su espacio de direcciones. Sin embargo, un sistema de tiempo de ejecución subyacente garantiza de manera transparente que los procesos que se ejecutan en diferentes computadoras observen las actualizaciones realizadas entre sí. Es como si los procesos accedieran a una única memoria compartida, pero en realidad la memoria física está distribuida.

 La memoria compartida distribuida (DSM) es un paradigma intuitivo [3] que emula el entorno de ejecución de un multiprocesador de memoria compartida en un sistema distribuido. El modelo es intuitivo en el sentido de que los paradigmas que son válidos para la programación concurrente en sistemas de memoria compartida siguen siendo válidos en sistemas distribuidos.  Un área de aplicación donde los paradigmas de memoria compartida distribuida son útiles es el área de computación de alto rendimiento. 

Arquitecturas DSM

El comportamiento más intuitivo para la memoria es el de un sistema centralizado donde todas las operaciones son atómicas. Este modelo se denomina consistencia atómica o linealizabilidad: todas las operaciones de escritura están totalmente ordenadas (obedeciendo el orden en tiempo real de las operaciones) y las operaciones de lectura siempre devuelven el último valor escrito en la memoria. Estos modelos de consistencia de memoria  se etiquetan como modelos de consistencia fuerte. 

La implementación más simple de DSM, se ilustra en la figura 1. En esta arquitectura, un servidor central mantiene las páginas de memoria y los accesos a los datos, por parte de los clientes, se realizan a través de una invocación remota al servidor. El servidor serializa todas las solicitudes, asegurando así el orden total en los mensajes que son  necesario para mantener una consistencia fuerte. El sistema se comporta como si se dispusiera de una única memoria central.

En la arquitectura anterior, si todos los accesos a la memoria tuvieran que ser remotos el rendimiento sería bajo. 

Arquitectura Centralizada. Adaptada de [3]

Afortunadamente, los programas presentan cierto grado de localidad en los accesos a datos. Localidad significa que si se lee o escribe una posición de memoria determinada, es probable que también se acceda a otras posiciones de memoria adyacentes. En lugar de forzar la ejecución remota de todos los accesos, simplemente se puede migrar una parte de la memoria (por ejemplo, una página) del servidor al cliente, como se ilustra en la figura 2. El cliente puede realizar accesos locales posteriores a esa misma página. Si otro cliente quiere acceder a la misma página, la página se vuelve a migrar. Dado que una página determinada se encuentra en una única ubicación en un momento determinado, también se garantiza la coherencia.

Migraciones. Adaptada de [3]

La arquitectura anterior funciona mucho mejor que una centralizada ya que permite que la mayoría de los accesos se ejecuten localmente, en la máquina del cliente. Sin embargo, no permite que dos clientes accedan a la misma página al mismo tiempo. Siempre se debe migrar la página antes de que otro sitio pueda acceder a ella. 

Dado que las lecturas suelen ser mucho más comunes que las escrituras, y dado que muchas aplicaciones se basan en estructuras compartidas que pueden ser leídas en paralelo por hilos  diferentes, es aconsejable permitir varias copias idénticas del mismo página para ser replicada en el sistema.  La variante ilustrada en la figura 3 tiene réplicas de solo lectura que se leen simultáneamente. Cada vez que un cliente solicita, se crea una nueva réplica. Las solicitudes de escritura son coordinadas por el servidor. Naturalmente, si existen varias réplicas de una misma página, hay que garantizar que se comporten como una sola página. Se pueden usar dos enfoques para garantizar que las réplicas se mantengan con contenidos similares en una escritura: uno es propagar la actualización a todas las réplicas; la otra es invalidar las copias obsoletas y mantener actualizada una única copia.

Replicación con solo lectura. Adaptada de [3]

 La figura 4 muestra el enfoque de replicación completa, donde las réplicas de páginas de lectura y escritura se pueden mantener en varios clientes. Los clientes pueden realizar solicitudes de acceso, que son coordinadas por un secuenciador. La intercalación de operaciones y comandos locales del secuenciador depende de la semántica de coherencia del DSM. La función de secuenciador se puede distribuir, por ejemplo, realizada por un protocolo descentralizado ejecutado por todos los clientes interesados.

Replicación Lectura-Escritura. Adaptada de [3]

Referencias

1. Coulouris, George F. Distributed Systems: Concepts and Design. Boston: Addison-Wesley, 2012.
2. Tanenbaum, Andrew S., and Maarten van Steen. Distributed Systems: Principles and Paradigms. Upper Saddle River, NJ: Pearson Prentice Hall, 2007. 
3. Rodrigues, Luís and Veríssimo, Paulo. Advances in Distributed Computing and Middleware. 

¿Cómo implementar un sistema Pub Sub?

Paradigma Pub-Sub

El paradigma de publicación-suscripción (Pub-Sub) [1]  es simple y fácil de entender:

• No requiere que el publicador y el suscriptor estén activos al mismo tiempo. Por lo tanto, admite lo que a menudo se denomina interacción asíncrona.
•  Es útil cuando los participantes tienen baja o esporádica conectividad. 
• Los componentes de la aplicación no se acoplan directamente, sino que se acoplan a través del bus de mensajes ( red de corredores) , resultando más fácil reconfigurar el sistema. Se puede cambiar el número, la identidad o la ubicación de los suscriptores sin cambiar los publicadores y viceversa. 

Un bus de mensajes [3] es una abstracción que permite que los procesos intercambien mensajes indirectamente, a través de un componente intermedio, llamado bus. En este modelo, los publicadores generan mensajes para el bus, mientras que los suscriptores consumen mensajes del bus. La mayoría de los buses de mensajes permiten que se produzca un mensaje en un momento, pero que solo se consuma más adelante. El bus de mensajes mantiene el mensaje en un almacén no volátil hasta que se consume.

¿Cómo implementar un sistema Pub Sub?

Para ejemplificar cómo se puede implementar el modelo pub-sub, se usa la arquitectura más simple, donde la abstracción del bus de mensaje se materializa en un servidor central, como se ilustra en la Figura  1.

Arquitectura Pub Sub. Adaptado de [3]

La actividad de publicación es muy sencilla:

• El publicador  envía un mensaje al servidor que lo almacena en la memoria no volátil. 

La suscripción de mensajes se puede implementar utilizando dos alternativas diferentes: 

• push: los suscriptores  registran en el servidor el interés en recibir una determinada clase de mensajes, y el servidor es responsable de difundir estos mensajes a los suscriptores interesados. Se puede usar  comunicación por multidifusión  para difundir los  mensajes de manera eficiente, cuando muchos suscriptores están interesados ​​en los mismos mensajes.
• pull:  depende del suscriptor ponerse en contacto con el servidor periódicamente para obtener los mensajes. Este segundo esquema puede parecer menos eficiente, pero tiene sus ventajas en sistemas donde los suscriptores no están permanentemente conectados y quieren recolectar los mensajes de forma diferida (no sincronizada).

 El problema con la arquitectura ejemplificada en la Figura 1, con  el servidor centralizado, es que el rendimiento puede verse afectado debido a que esta disposición representa un  cuello de botella  como un único punto de falla. Mediante el uso de la replicación, se pueden mejorar tanto el rendimiento como la confiabilidad de la aplicación.

Referencias

1. Coulouris, George F. Distributed Systems: Concepts and Design. Boston: Addison-Wesley, 2012.
2. Tanenbaum, Andrew S., and Maarten van Steen. Distributed Systems: Principles and Paradigms. Upper Saddle River, NJ: Pearson Prentice Hall, 2007. 
3. Rodrigues, Luís and Veríssimo, Paulo. Advances in Distributed Computing and Middleware. 

Llamadas a Procedimientos Remotos

 Llamadas a Procedimientos Remotos son técnicas de comunicación entre procesos. Es una paradigma de procesamiento distribuido que consiste en que un proceso local invoque la ejecución de una función o un procedimiento en una máquina remota. Los procesos locales y remotos se denominan por ello procesos del cliente y procesos del servidor respectivamente, y el paradigma de programación que utiliza este principio es la arquitectura cliente-servidor.  

RPC

La secuencia de acciones relacionadas con la ejecución de un RPC (Remote Procedure Call) se ilustra en la Figura 1:

•  El stub del cliente es responsable de enviar una solicitud al servidor y esperar una respuesta:
• Para enviar la solicitud, el stub primero debe crear el mensaje correspondiente. 
• El stub convierte los parámetros de entrada en un formato adecuado para ser transmitido por la red y  ser reconocible por el servidor. Este proceso se conoce como linealización o serialización.
•  Después de formatearse, el mensaje se envía al servidor a través de algún protocolo de nivel de sesión utilizando el sistema de comunicación. 
• Ese protocolo se encarga de retransmitir la solicitud, esperar respuestas, descartar respuestas duplicadas u obsoletas, etc.
• En el lado del servidor, el mensaje sigue una ruta simétrica:
•  Es recibido y procesado por el protocolo de sesión, que identifica el servicio de destino y lo entrega al stub del servidor correspondiente. 
• El stub del servidor extrae los parámetros del mensaje (deserializa) y realiza una llamada local a la función real que hace el trabajo. 
• Cuando esta función regresa, el stub del servidor crea un mensaje de respuesta y lo entrega al protocolo de sesión para que sea devuelto al cliente, siguiendo los mismos pasos que antes, en la dirección opuesta. 
• En el lado del cliente, el stub del cliente finalmente devuelve la llamada original al cliente, con cualquier resultado relevante.

1. Mecanismo de RPC

La primera vez que se invoca el stub del cliente, este se pone en contacto con un servidor de nombres para determinar la dirección en la que reside el servidor. 

• Un servidor que tiene un servicio que ofrecer, exporta la interfaz para este servicio. Exportar una interfaz significa el registro de la misma en el sistema para que los clientes puedan usarla. 
• Un Cliente debe importar una interfaz (exportada) antes de que pueda comenzar la comunicación.

Semántica de las llamadas asociadas a RPC 

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.

Sistema Run-Time de  RPC:

El sistema  run-time RPC es una biblioteca de rutinas y un conjunto de servicios que manejan las comunicaciones de red que subyacen al mecanismo RPC. En el curso de una llamada RPC, el código de los sistemas de tiempo de ejecución del lado del cliente y del lado del servidor maneja el enlace, establece comunicaciones a través de un protocolo apropiado, pasa datos de llamadas entre el cliente y el servidor y maneja los errores de comunicación.

Stub

La función del  stub es proporcionar transparencia al código de aplicación escrito por el programador.

• En el lado del cliente, el stub maneja la interfaz entre la llamada al procedimiento local del cliente y el sistema run-time, serializando y deserializando  de los mensajes, invocando el protocolo de tiempo de ejecución de RPC y, si se solicita, llevando a cabo algunos de los pasos de vinculación. 
• En el lado del servidor, el stub proporciona una interfaz similar entre el sistema run-time  y los procedimientos del administrador local que ejecuta el servidor.

Visitar este enlace para: RPC en python,  RPC en R  

Referencias

1. Coulouris, George F. Distributed Systems: Concepts and Design. Boston: Addison-Wesley, 2012.
2. Tanenbaum, Andrew S., and Maarten van Steen. Distributed Systems: Principles and Paradigms. Upper Saddle River, NJ: Pearson Prentice Hall, 2007. 
3. IONOS Digitalguide. “Remote Procedure Call: comunicación en sistemas cliente-servidor.” Accessed June 16, 2022. https://www.ionos.es/digitalguide/servidores/know-how/que-es-rpc/.
4. GeeksforGeeks. “Remote Procedure Call (RPC) in Operating System,” August 30, 2017. https://www.geeksforgeeks.org/remote-procedure-call-rpc-in-operating-system/.

API para los Protocolos de Internet

 Socket

Un socket es un punto final de comunicación [2] en el que una aplicación puede escribir información destinada a enviarse fuera de la red subyacente, y desde el cual puede leerse información entrante. Un socket forma una abstracción sobre el punto final real de comunicación, el cual utiliza el sistema operativo local para un protocolo de transporte específico.

Socket. Tomado de [1]

La comunicación entre procesos [1] consiste en transmitir un mensaje entre un socket en un proceso y otro socket en otro proceso.  Para que un proceso reciba mensajes , su socket debe estar vinculado a un puerto local y una de las direcciones de Internet de la computadora en la que se ejecuta (ver figura 1).

Los mensajes enviados a una dirección de Internet y número de puerto en particular solo pueden ser recibidos por 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.

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. Un servidor vinculará su socket a un puerto de servidor, uno que se da a conocer a los clientes para que puedan enviarle mensajes. Un cliente vincula su socket a cualquier puerto local libre. El método de recepción devuelve la dirección de Internet y el puerto del remitente, además del mensaje, lo que permite al destinatario enviar una respuesta

Tanto UDP como TCP usan la abstracción de socket, para la comunicación entre procesos. A continuación se indican los aspectos involucrados con la comunicación de Datagramas y la comunicación de flujos. 

Comunicación de Datagramas UDP

Un datagrama  UDP [1] se transmite desde un proceso de envío a un proceso de recepción sin acuse de recibo ni reintentos. Si ocurre una falla, es posible que el mensaje no llegue. Los siguientes son algunos problemas relacionados con la comunicación de datagramas:

• Tamaño del mensaje: El protocolo IP subyacente permite longitudes de paquete de hasta 216 bytes, lo que incluye los encabezados y el mensaje. Sin embargo, la mayoría de los entornos imponen una restricción de tamaño de 8 kilobytes. 
• Bloqueo:  los sockets proporcionan envíos sin bloqueo y recepciones con bloqueo. La operación de envío regresa cuando ha entregado el mensaje a los protocolos UDP e IP subyacentes. Al llegar, el mensaje se coloca en una cola para el socket que está vinculado al puerto de destino. 
  El método de recepción  bloquea hasta que se recibe un datagrama, a menos que se haya establecido un tiempo de espera en el socket.  
• Tiempo espera: Se puede establecer tiempo de espera en los socket para evitar que un proceso que ha invocado una operación de  recepción se mantenga esperando indefinidamente.
• Recibe desde cualquiera:  El método de recepción devuelve la dirección de Internet y el puerto local del remitente, lo que permite al destinatario verificar de dónde proviene el mensaje. Es posible conectar un socket de datagrama a un puerto remoto y una dirección de Internet en particular, en cuyo caso el socket solo puede enviar y recibir mensajes desde esa dirección.

 Modelo de Fallas 

La comunicación de Datagramas UDP sufren de las siguientes fallas:

• Fallas de Omisión: mensajes pueden perderse ocasionalmente, por causa de un error detectado en un checksum o falta de espacio en el buffer. 
• Orden: mensajes se entregan fuera del orden que se enviaron.

Uso de UDP

Ejemplos de aplicaciones que usan UDP : el Sistema de nombres de dominio (DNS), voz sobre IP (VOIP), streaming  de videos y audios,  Los datagramas UDP a veces son una opción atractiva porque no sufren los gastos generales asociados con la entrega garantizada de mensajes. Hay tres fuentes principales de sobrecarga en UDP:

• la necesidad de almacenar información del estado en el origen y el destino;
• la transmisión de mensajes adicionales;
• latencia para el remitente.

Comunicación de Stream TCP

El API del protocolo TCP [1] proporciona la abstracción de un flujo (stream) de bytes en el que se pueden escribir datos y desde el cual se pueden leer.  Las siguientes características de la red están ocultas por la abstracción Stream:

• Tamaño de mensajes: la aplicación escoge la cantidad de datos para leer/escribir del stream. 
• Mensajes Perdidos: usa un esquema de acuse de recibo del mensaje. Hay retransmisión del mensaje si no se recibe el acuse.
• Control del Flujo: protocolo TCP intenta ajustar las velocidades  de los procesos que leen/escriben en un stream. 
• Duplicación y orden de los mensajes: cada paquete IP se la asocia un identificador que hace posible detectar mensaje duplicados  y reordenar los que lleguen desordenados. 
•  Destino del Mensaje: procesos establecen una conexión antes de enviar un stream. Una vez establecido la conexión, los procesos leen/escriben sin enviar direcciones ni puertos

La comunicación de Stream TCP supone una conexión cliente-servidor con las siguientes acciones:

• Cliente crea un socket de tipo stream y la petición de conexión con el servidor en su puesto de servicio.
• Servidor crea un socket de escucha ligado al puerto de servicio y el socket de escucha mantiene una cola de peticiones de conexión.
• Cuando un servidor acepta una conexión, crea un socket  para la comunicación del cliente y se reserva el socket del puerto de servicio para escuchar las peticiones de otros clientes.
• Cuando una aplicación cierra un socket  significa que no va a seguir escribiendo.

Lo siguientes son aspectos relacionados a la comunicación por Stream: 

• Concordancia de items de datos: los procesos que se comunican necesitan estar de acuerdo con el tipo de datos transmitidos por el stream 
• Bloqueo:  Un proceso intenta leer los datos de un canal de entrada, o los extrae de la cola o se bloquea hasta que existan datos. El proceso de escritura de datos en el stream se bloqueará por el mecanismo de control de flujo de TCP, si el socket del otro lado intenta almacenar más información de la permitida.
• Hilos: cuando un servidor acepta una conexión, se crea un hilo  para comunicarse con el cliente. 

Modelo de Fallas 

Para satisfacer la propiedad de integridad de una comunicación confiable, los flujos TCP usan checksum para detectar y rechazar paquetes corruptos y números de secuencia para detectar y rechazar paquetes duplicados. También, por  la propiedad de validez, los flujos de TCP usan tiempos de espera y retransmisiones para tratar los paquetes perdidos. 

Si no se recibe acuse de recibo de los paquetes, el software declara la conexión rota. Efectos de una conexión rota:

• Los procesos que utilizan la conexión no distinguen entre un fallo de red y un fallo en el proceso que esta en el otro extremo de la conexión.
• Los procesos comunicantes no pueden saber si sus mensajes recientes se recibieron o nó.

Uso de TCP

Muchos servicios se ejecutan sobre conexiones de tipo TCP, con números de puertos reservado. Incluyen:

• HTTP:  protocolo de transferencia de hipertexto
• FTP: leer directorios de computadores remotos 
• Telnet: acceso a un terminal en un computador remoto 
• SMTP: protocolo de transferencia de correos.

Referencias

1. Coulouris, George F. Distributed Systems: Concepts and Design. Boston: Addison-Wesley, 2012.
2. Tanenbaum, Andrew S., and Maarten van Steen. Distributed Systems: Principles and Paradigms. Upper Saddle River, NJ: Pearson Prentice Hall, 2007. 

Comunicación entre Procesos

En la comunicación entre procesos, un proceso envía un mensaje (una secuencia de bytes) a un destino y otro proceso en el destino recibe el mensaje. Esta actividad implica la comunicación de datos desde el proceso de envío al proceso de recepción y puede incluir  la sincronización entre los dos procesos.

La comunicación se establece siguiendo una serie de reglas o protocolos de comunicación.  Los protocolos usados para este propósito son los desarrollados para internet:  en la capa de red (IP), capa de transporte (TCP, UDP), capa de aplicación (HTTP, FTP).

Características de la comunicación entre procesos [1]

• Comunicación síncrona y asíncrona. Se asocia una cola a cada destino de mensaje. Los procesos de envío hacen que los mensajes se agreguen a las colas remotas y los procesos de recepción eliminan los mensajes de las colas locales.
• Síncrona, los procesos de envío y recepción se sincronizan en cada mensaje. Quien envía permanece bloqueado esperando a que llegue una respuesta del receptor antes de realizar cualquier otro ejercicio.
• Asíncrona:  Operación de envío es no-bloqueante ya que  permite que el proceso de envío continúe tan pronto como el mensaje se ha copiado en un bufer local.  Operación de recepción puede ser bloqueante y no-bloqueante  ( el proceso de recepción continúa con su programa después de emitir una operación de recepción, y que proporciona un búfer para llenar en segundo plano).
• Destino de los mensajes:  Un puerto local es un destino de mensaje y es especificado como un número entero. Un puerto tiene exactamente un receptor (exceptuando los puertos de multidifusión) pero puede tener muchos remitentes.
• Confiabilidad. Un servicio de mensajes punto a punto puede describirse como confiable si se garantiza que los mensajes se entregarán a pesar de que se pierda o se pierda una cantidad razonable de paquetes.  Para la propiedad de integridad , los mensajes deben llegar sin corrupción y sin duplicación.
• Ordenamiento. Algunas aplicaciones requieren que los mensajes se entreguen en el orden del remitente, es decir, el orden en que fueron transmitidos por el remitente. Dichas aplicaciones consideran  que la entrega de mensajes fuera del orden del remitente es un error.

Referencias

1. Coulouris, George F. Distributed Systems: Concepts and Design. Boston: Addison-Wesley, 2012.
2. Tanenbaum, Andrew S., and Maarten van Steen. Distributed Systems: Principles and Paradigms. Upper Saddle River, NJ: Pearson Prentice Hall, 2007. 

Protocolos a nivel de Transporte

El término Protocolo en la DRAE se refiere  al conjunto de reglas que se establecen en el proceso de comunicación entre dos sistemas. Un protocolo esta conformado por dos partes:

• una especificación de la secuencia de mensajes que deben intercambiarse
• una especificación del formato de los datos en los mensaje 

La capa de transporte o el nivel de transporte , en el modelo OSI,  representa el cuarto nivel , y es la encargada de la transferencia de los datos entre emisor y receptor.

El Protocolo a nivel de Transporte [1] transmite mensajes de cualquier longitud  desde el proceso que hace el envío hasta el proceso receptor.  Un proceso que desea transmitir un mensaje a otro proceso emite una llamada a un módulo del protocolo de transporte, pasándole un mensaje en el formato especificado. Luego, el software de transporte se ocupa de la transmisión del mensaje a su destino, subdividiéndolo en paquetes de un tamaño y formato específicos que pueden transmitirse al destino a través del protocolo de red.  El módulo de protocolo de transporte correspondiente en la computadora receptora recibe el paquete a través del módulo de protocolo de nivel de red y realiza transformaciones inversas para regenerar el mensaje antes de pasarlo a un proceso de recepción.

Entre los protocolos de transporte se encuentran UDP y TCP, y son los que se van a detallar a continuación.

UDP

UDP  (Protocolo Universal Datagram) es casi una réplica a nivel de transporte de IP. Un datagrama UDP se encapsula dentro de un paquete IP: el datagrama contiene  un encabezado corto que incluye los números de puerto de origen y de destino (las direcciones del host correspondientes están  en el encabezado IP), un campo  longitud y una suma de comprobación (checksum), se detalla en la siguiente tabla. 

Definiciones de campos de cabecera de UDP

Item	Descripción
Número de puerto de origen	Dirección del puerto de protocolo que envía la información
Número de puerto de destino	Dirección del puerto de protocolo que recibe la información.
Longitud	Longitud en octetos del datagrama UDP.
CHECKSUM	Proporciona una comprobación en el datagrama UDP utilizando el mismo algoritmo que IP.

 Las características de UDP:

• Trabaja sin conexión: no emplea sincronización entre el origen y el destino del mensaje
• No ofrece ninguna garantía de entrega de mensajes: los paquetes IP pueden perderse debido a la congestión o a un error de la red. 
• No tiene mecanismos de confiabilidad adicionales, excepto la suma de verificación, que es opcional: los paquetes que no coinciden con el valor de verificación se descartan. 
• Proporciona un medio para transmitir mensajes de hasta 64 kbytes de tamaño entre pares de procesos (o desde uno).
• Su gran ventaja es que provoca poca carga adicional en la red ya que es sencillo y emplea cabeceras muy simples.

TCP

TCP (Protocolo para el Control de Transmisiones) presenta las siguientes característica [1] :

• Entrega confiable de secuencias de bytes arbitrariamente largas a través de la abstracción de programación basada en flujo (PBF): la garantía de confiabilidad implica la entrega al proceso de recepción de todos los datos presentados al software TCP por el proceso de envío, en el mismo orden.
•  Orientado a la conexión: antes de transferir cualquier dato, el remitente y el  receptor de procesos deben cooperar en el establecimiento de un canal de comunicación bidireccional.
• Incluye mecanismos adicionales (implementados sobre IP) para cumplir con las garantías de confiabilidad. Estos son:
• Secuenciación: un proceso de envío TCP divide el flujo en una secuencia de segmentos de datos y los transmite como paquetes IP. Se agrega un número de secuencia a cada segmento TCP.  El receptor usa los números de secuencia para ordenar los segmentos recibidos antes de colocarlos en el flujo de entrada del proceso de recepción. Todo segmento recibido con números superiores se mantienen en el bufer hasta que lleguen  los predecesores.  
• Control de flujo:  esto se logra mediante un sistema de acuses de recibo de  los segmentos. 
• Retransmisión: el remitente registra los números de secuencia de los segmentos que envía. Cuando recibe un acuse de recibo, observa que los segmentos se recibieron con éxito y luego puede eliminarlos del bufer salientes. Si algún segmento no recibe reconocimiento del acuse de recibo dentro de un tiempo de espera especificado, el remitente lo retransmite.
• Almacenamiento en búfer: el búfer entrante en el receptor se utiliza para equilibrar flujo de datos entre remitente y receptor. Si el proceso receptor emite operaciones de recepción más lentamente que el remitente emite operaciones de envío, la cantidad de datos en el búfer aumentará. El búfer puede desbordarse, y cuando  sucede, los segmentos entrantes  se eliminan sin registrar su llegada. Por lo tanto, no se envía acuse recibo de su llegada y el remitente está obligado a retransmitirlos.
• Checksum: cada segmento lleva una suma de verificación que cubre el encabezado y los datos en el segmento. Si un segmento recibido no coincide con el checksum, el segmento se descarta.

Referencias

1. Coulouris, George F. Distributed Systems: Concepts and Design. Boston: Addison-Wesley, 2012.
2. Tanenbaum, Andrew S., and Maarten van Steen. Distributed Systems: Principles and Paradigms. Upper Saddle River, NJ: Pearson Prentice Hall, 2007.