Alumnos: Rosas Sáenz, José Manuel (Líder)

(98%) Díaz Arévalo, Hiram Abí

(98%) Orozco Flores, Henry Otoniel

(98%)

INDICE1. Introducción2. La Interfaz de Programación de aplicaciones

para los protocolos de Internet.3. Representación externa de datos y

empaquetados.4. Comunicación Cliente-Servidor.5. Comunicación en Grupo.6. Caso de Estudio: Comunicación entre

procesos en UNIX.7. Resumen.

Aplicaciones, Servicios

RMI y RCP

Protocolo petición-respuesta

Empaquetado y representación externa de datos

UDP y TCP

Este Capitulo

Capas Middleware

Figura 4.1. Capas de Middleware

4.1. Introducción La siguiente sección de este capítulo presenta las características de la comunicación entre procesos y discute UDP y TCP desde el punto de vista del programador, junto con una discusión de su modelo de fallo.La interfaz del programa de aplicación para UDP proporciona una abstracción del tipo paso de mensajes. Los paquetes independientes que contienen estos mensajes se llaman datagramas.La interfaz del programa de aplicación de TCP proporciona la abstracción de un flujo (stream) de dos direcciones entre pares de procesos.

4.1. Introducción La tercera sección de este capítulo trata sobre el modo en que los objetos y las estructuras de datos utilizadas en los programas de aplicación se traducen a una forma adecuada para ser enviada en mensajes a través de la red.Las secciones cuarta y quinta de este capítulo tratan sobre el diseño de protocolos capaces de soportar la comunicación cliente-servidor y en grupos.

4.1. Introducción Las operaciones de paso de mensajes se pueden utilizar para construir protocolos que soporten estructuras particulares de procesos y patrones de comunicación.Examinando los patrones de roles y de comunicación es posible diseñar protocolos de comunicación adecuados basados en intercambios eficientes evitando redundancias

4.2. API para los Procesos de InternetEn esta sección, estudiaremos las

características generales de la comunicación entre procesos para después considerar los protocolos de Internet como un ejemplo de la misma, explicando el modo en que los programadores pueden utilizarlos, ya sea por medio de mensajes UDP o streams TCP.

Las Características de la comunicación entre procesos

El paso de mensajes entre un par de procesos se puede basar en dos operaciones: envía y recibe, definidas en función del destino y del mensaje.

Para que un proceso se pueda comunicar con otro, el proceso envía un mensaje (una secuencia de bytes) a un destino y otro proceso en el destino recibe el mensaje.

Comunicación Sincrónica y Asincrónica

A cada destino de mensajes se asocia una cola. La comunicación entre los procesos emisor y receptor puede ser síncrona o asíncrona. En la forma síncrona, los procesos receptor y emisor se sincronizan con cada mensaje. En este caso, envía como recibe son operaciones bloqueantes.En la forma de comunicación asíncrona, la utilización de la operación envía es no bloqueante.

Destino de los MensajesUn puerto local es el destino de un mensaje dentro de un computador, especificado como un número entero.Un puerto tiene exactamente un receptor pero puede tener muchos emisores. Los procesos pueden utilizar múltiples puertos desde los que recibir mensajes.Una alternativa al uso de los puertos sería la entrega de los mensajes directamente a los procesos. Sin embargo, los puertos tienen la ventaja de que proporcionan varios puntos de entrada alternativos para un proceso receptor.

Destino de los MensajesFiabilidad: En lo que concierne a la propiedad de validez, se dice que un servicio de mensajes punto a punto es fiable si se garantiza que los mensajes se entregan a pesar de poder dejar caer o perder un número razonable de ellos. Respecto a la integridad, los mensajes deben llegar sin corromperse ni duplicarse.Ordenación: Algunas aplicaciones necesitan que los mensajes sean entregados en el orden de su emisión.

SOCKETSAmbas formas de comunicación (UDP y TCP) utilizan la abstracción de sockets, que proporciona los puntos extremos de la comunicación entre procesos. Los sockets son conectores. La comunicación entre procesos consiste en la transmisión de un mensaje entre un conector de un proceso y un conector de otro proceso.

Cualquier Puerto

Puerto Acordado

Mensaje

Otros puertos

Sockets

Cliente Servidor

Sockets

Figura 4.2. Sockets y puertos

Api de Java para las Direcciones de Internet

Java proporciona una clase, InetAddress, que representa las direcciones Internet. Los usuarios de esta clase se refieren a los computadores por sus nombres de host en el Servicio de Nombres de Dominio (Domain Name Service, DNS).

InetAddress unComputador = InetAddress.getByName(«bruno.dcs.qmw.ac.uk»);

Comunicación de Datagramas UDP

Un datagrama enviado por UDP se transmite desde un proceso emisor a un proceso receptor sin acuse de recibo ni reintentos. Cualquier proceso que necesite enviar o recibir mensajes debe crear, primero, un conector asociado a una dirección internet y a un puerto local. El método recibe devolverá, además del mensaje, la dirección Internet y el puerto del emisor, permitiendo al receptor enviar la correspondiente respuesta.

Comunicación de Datagramas UDP

Tamaño del mensaje: el proceso receptor necesita especificar una cadena de bytes de un tamaño concreto sobre la cual se almacenará el mensaje recibido.La mayoría de los entornos imponen una restricción a su talla de 8 kilobytes.Bloqueo: la comunicación de datagramas UDP utiliza operaciones de envío. envía no bloqueantes y recepciones recibe bloqueantes. Tiempo límite de espera: se pueden fijar tiempos límites de espera (timeout) en los conectores. Recibe de cualquiera: el método recibe no especifica el origen de los mensajes.

Modelo de FalloEsta definida en términos de dos propiedades: integridad y validez.El modelo de fallo puede utilizarse para proponer un modelo de fallo para los datagramas UDP, que padecen de las siguientes debilidades: Fallos de omisión y Ordenación.

Las aplicaciones que utilizan datagramas UDP dependen de sus propias comprobaciones para conseguir la calidad que necesitan respecto a la fiabilidad de la comunicación.

Utilización de UDPPara algunas aplicaciones, resulta aceptable utilizar un servicio que sea susceptible de sufrir fallos de omisión ocasionales.Los datagramas UDP son, en algunas ocasiones, una elección atractiva porque no padecen las sobrecargas asociadas a la entrega de mensajes garantizada. Existen tres fuentes principales para esa sobrecarga:

La necesidad de almacenar información de estado en el origen y en el destino.

La transmisión de mensajes extra.La latencia para el emisor.

API Java para datagramas UDPLa API Java proporciona una comunicación de datagramas por medio de dos clases: DatagramPacket y DatagramSocket.

Cadena de bytes conteniendo el mensaje

Longitud del mensaje

Dirección Internet

Número de puerto

Paquete del datagrama

DatagramPacke: esta clase proporciona un constructor que crea una instancia compuesta por una cadena de bytes que almacena el mensaje, la longitud del mensaje y la dirección Internet y el número de puerto local del conector destino. Esta clase proporciona otro constructor para cuando se recibe un mensaje. Sus argumentos especifican la cadena de bytes en la que alojar el mensaje y la longitud de la misma.

API Java para datagramas UDPDatagramSocket: esta clase maneja conectores para enviar y recibir datagramas UDP.La clase DatagramSocket proporciona varios métodos que incluyen los siguientes:

send y receire: Origen y Destino- contenidos.

SetSoTimeout: Tiempo de Limite. connect: Conectarse a un puerto

remoto.

Import java.net.*;

import java.io. *;

public class ClienteUDP{ public static void main(String args[ ]){

// args proporciona el mensaje y el nombre del servidor

try{

DatagramSocket unSocket = new DatagramSocket( );

byte [ ] m = args[0].getBytes( );

InetAddress unHost = lnetAddress.getByName(args[1]);

int puertoServidor = 6789;

DatagramPacket petición =

new DatagramPacket(m, args[0].length( ), unHost, puertoServidor); unSocket. send(peticion);

byte [] bufar = new byte[1000];

DatagramPacket respuesta = new DatagramPacket(bufer, bufer.length); unSocket. receive(respuesta);

System. out.príntln(" Respuesta: " + new Síríng(respuesta.getData( )));

unSocket.close( );

}catch (SocketException e){System.out.príntln("Socket: " + e.getMessage( )); }

}catch (lOException e){System.out.príntln("IO: " + e.getMessage( ));}

}

}

Figura 4.3 Un Cliente UDP enviando un mensaje a un servidor

import java.net. *; import java.io. *; public class ServidorUDP{ public static void main(Stríng args[ ]){

try{DatagramSocket unSocket = new DatagramSocket(6789);byte [ ] bufer = new bytef 1000];while (true){DatagramPacket petición = new DatagramPacket(bufer, bufer.length); unSocket. receive(peticion); DatagramPacket respuesta = new

DatagramPacket(peticion.getData(),petición.getLength(), petición.getAddress(), petición.getPortf)); unSocket. send(respuesta);

}}catch (SocketException e){System.out.príntln("Socket: " + e.getMessage()); }}catch (lOException e) {System.out.println("IO: " + e.getMessage());}

}}

Figura 4.3 Un Cliente UDP enviando un mensaje a un servidor

Comunicación de Streams TCPLa API para el protocolo TCP, que es originaria de UNIX BSD 4.x, proporciona la abstracción de un flujo de bytes (stream) en el que pueden escribirse y desde el que pueden leerse datos. La abstracción de stream oculta las siguientes características de la red:Tamaño de los mensajes: la aplicación puede elegir la cantidad de datos que quiere escribir o leer del stream.Mensajes perdidos: el protocolo TCP utiliza un esquema de acuse de recibo de los mensajes.

Comunicación de Streams TCPControl del flujo: el protocolo TCP intenta ajustar las velocidades de los procesos que leen y escriben en un stream.

Duplicación y ordenación de los mensajes: a cada paquete IP se le asocia un identificador.

Destinos de los mensajes: un par de procesos en comunicación establecen una conexión antes de que puedan comunicarse mediante un stream.

Comunicación de Streams TCPEl API para la comunicación por streams supone que en el momento de establecer una conexión, uno de ellos juega el papel de cliente y el otro juega el papel de servidor, aunque después se comu niquen de igual a igual.

El par de conectores. el del cliente y el del servidor, se conectan por un par de streams. uno en cada dirección

Cuando una aplicación cierra un conector, indica que no va a escribir nada más en su stream de salida.

Comunicación de Streams TCPLos siguientes párrafos discuten aspectos importantes relacionados con la comunicación de streams:Concordancia de ítems de datos: los dos procesos que se comunican necesitan estar de acuerdo en el tipo de datos transmitidos por el stream. Bloqueo: Cuando un proceso intenta leer datos de un canal de entrada, o bien extraerá los datos de la cola o bien se bloqueará hasta que existan datos disponibles.Hilos: cuando un servidor acepta una conexión, generalmente crea un nuevo hilo con el que comunicarse con el nuevo cliente.

Modelo de FalloPara satisfacer la propiedad de integridad de una comunicación fiable, los streams TCP utilizan una suma de comprobación para detectar y rechazar los paquetes corruptos, y utilizan un número de secuencia para detectar y eliminar los paquetes duplicados. Con respecto a la propiedad de validez, los streams TCP utilizan timeouts y retransmisión de los paquetes perdidos. Cuando una conexión está rota, se notificará al proceso que la utiliza siempre que intente leer o escribir. Esto tiene los siguientes efectos:

Los procesos que utilizan la conexión no distinguen entre un fallo en la red y un fallo en el proceso que está en el otro extremo de la conexión.

Los procesos comunicantes no pueden saber si sus mensajes recientes han sido recibidos o no.

Utilización de TCPMuchos de los servicios utilizados se ejecutan sobre

conexiones TCP, con números de puerto reservados. Entre ellos se encuentran los siguientes:

HTTP: El protocolo de transferencia de hipertexto se utiliza en comunicación entre un navega dor y un servidor web; se tratará de él más tarde en este capítulo.

FTP: El protocolo de transferencia de archivos permite leer los directorios de un computador remoto y transferir archivos entre los computadores de una conexión.

Telnet: La herramienta Telnet proporciona acceso a un terminal en un computador remoto.

SMTP: El protocolo simple de transferencia de correo se utiliza para mandar correos electróni cos entre computadores.

El API Java para los streamsLa interfaz Java para los streams TCP está constituida por las clases ServerSocket y Socket.ServerSocket : esta clase está diseñada para ser utilizada por un servidor para crear un conector en el puerto de servidor que escucha las peticiones de conexión de los clientes.Socket: esta clase es utilizada por el par de procesos de una conexión. El cliente utiliza un constructor para crear un conector, especificando el nombre DNS de host y el puerto del servidor.

El API Java para los streamsLa clase Socket proporciona los métodos getlnputStream y getOutputStream para acceder a los dos streams asociados con un conector. El tipo de datos devueltos por esos métodos son InputStream y OutputStream, respectivamente (clases abstractas que definen métodos para leer y escribir bytes). Los valores de retorno se pueden utilizar corno argumentos de constructores para gestionar adecuadamente los streams de entrada y de salida del programa. Nuestro ejemplo utiliza DatalnputStream y DataOutputStream, los cuales permiten utilizar representaciones binarias de los tipos primitivos de datos para ser leídos y escritos de una forma independiente de la máquina.

import java.net.*;

import java.io. *;

public class ClienteTCP( public static void main(String args[ ]){

// los argumentos proporcionan el mensaje y el nombre del host destino try{

int puertoServicio = 7896;

Socket s = new Socket(args[1], puertoServicio);

DatalnputStream entrada = new DatalnputStream(s.getlnputStream());

DataOutputStream salida =new DataOutputStream(s.getOutputStream( ));

Salida.writeUTF(args[0]); //UTF es una codificación de Strings, ir a Sec. 4.3

String datos = entrada.readUTF();

System.out.príntln("Recibido: "+ datos);

s.close();

}catch (UnknownHostException e)

System.out.príntln("Socket: "+ e.getMessage()):

}catch (EOFException e){System.out.println("EOF: "+ e.getMessage( ));

}catch (lOException e){System.out.prínt/n("IO: "+e.getMessage());}

}

REPRESENTACIÓN EXTERNA DE DATOS Y EMPAQUETADOS

La información almacenada dentro de los programas en ejecución se representa mediante estructuras de datos, mientras que la información transportada en los mensajes consiste en secuencias de bytes.

Las estructuras de datos deben ser “aplanadas”

“aplanadas”Convertidas a una secuencia de bytes…

… antes de su transmisión y reconstruidas en el destino

“Aplanados” ¿Porqué?¿Para qué?Los tipos de datos primitivos transmitidos en los mensajes pueden tener valores de muchos tipos distintos, y no todos los computadores almacenan los valores primitivos, tales como los enteros, en el mismo orden.Por ejemplo, UNIX utiliza la codificación ASCII con un byte por carácter, mientras que el estándar Unicode permite representar textos en la mayoría de los lenguajes y utiliza dos bytes por carácter.

Entonces… para hacer posibleque dos computadoras intercambien datos

Se puede utilizar uno de los dos métodos siguientes:

1º

2º

Sin embargo, que los bytes no son alterados durante la transmisión.

Al estándar acordado para la representación de estructuras de datos y valores primitivos se denomina “REPRESENTACIÓN EXTERNA DE DATOS”

Empaquetar y DesempaquetarEmpaquetar (marshalling). Consiste en tomar

una colección de ítems de datos y ensamblar los de un modo adecuado para la transmisión en un mensaje.

Desempaquetado (unmarshalling). Es el proceso de desensamblado en el destino para producir una colección equivalente de datos.

Por tanto:Empaquetar consiste en traducir las estructuras de datos y los valores primitivos en una representación externa de datos. Similarmente, desempaquetar consiste en generar los valores primitivos desde la representación de datos externa y reconstruir las estructuras de datos.

dos alternativas para la representación externa de datos y el empaquetado:

La representación común de datos de CORBA

La señalización de objetos JAVA

CORBA

Es la representación externa de datos definida en CORBA 2.0 y puede representar todos los tipos de datos que se pueden utilizar como argumentos o como resul tados en las invocaciones remotas de CORBA.

Consta de 15 tipos primitivos, que incluyen los tipos short (16-bit), long (32-bit), unsigned short (sin signo), unsigned long, float (32-bit), double (64-bit), char, bolean (TRUE, FALSE), octet (8-bit), y any (el cual puede representar cualquier tipo básico o compuesto)

Tipos Primitivos. Los valores se transmiten en el orden del emisor, que se especifica en cada mensaje, el receptor lo traduce si es necesario a un orden diferente.

Por ejemplo, un short de 16-bit ocupa dos bytes en el mensaje

Supóngase que se indexa la secuencia de bytes desde cero. Entonces un valor primitivo cuyo tamaño son n bytes (donde n — 1, 2, 4 u 8) será añadido a la secuencia en una posición que sea un múltiplo de n en el flujo de bytes. Los valores de coma flotante siguen el estándar IEEE.

Se muestra un mensaje en CDR CORBA que contiene los tres campos de una estructura, cuyos respectivos tipos son string, string y unsigned long.

Se representará en forma aplanada la estructura Persona con el valor: {<Pérez>, <Madrid>, 19341}

La figura muestra la secuencia de bytes con cuatro bytes en cada fila. La representación de cada cadena está compuesta por un unsigned long representando la longitud, seguido por los caracteres en la cadena.

Las operaciones de empaquetado se pueden generar automática mente a partir de las especificaciones de los tipos de datos de los ítems que tienen que ser transmi tidos en un mensaje. Los tipos de las estructuras de datos y los tipos de los ítems de datos básicos están descritos en CORBA IDL (véase la Sección 17.2.3).

La interfaz del compilador CORBA 'véase el Capítulo 5) genera las operaciones de empaquetado y desempaquetado apropiadas para los argumentos y el resultado de los métodos remotos a partir las definiciones de los tipos de sus parámetros y resultados.

SERIALIZACIÓN DE OBJETOS JAVATanto los objetos como los datos primitivos pueden ser pasados como argumentos y resultados de la invocación de métodos. Un objeto es una instancia de una clase Java. Por ejemplo, la clase Java equivalente a struct Persona definida en IDL de CORBA podría ser:

public class Persona implements Serializable { prívate String nombre; prívate String lugar; prívate int año; public Persona(String unNombre, String unLugar, int unAño) {

nombre — unNombre;lugar = unLugar;año — unAño; } //seguido por los métodos para

acceder a los campos

En Java, el término señalización se refiere a la actividad de aplanar un objeto o un conjunto relacionado de objetos para obtener una forma lineal adecuada para ser almacenada en disco o para ser transmitida en un mensaje.

La deserialización consiste en restablecer el estado de un objeto o un conjunto de objetos desde su estado lineal. Se asume que el proceso que realiza la deserialización no tiene conocimiento previo de los tipos de los objetos en la forma lineal. Por lo tanto, debe incluirse en la forma lineal alguna información sobre la clase de cada objeto. Esta información posibilita al receptor la carga de la clase apropiada cuando un objeto es deserializado.

Los objetos Java pueden contener referencias a otros objetos. Cuando un objeto es serializado, todos los objetos a los que referencia son serializados con él para asegurarse de que cuando el objeto sea reconstruido, todas sus referencias pueden ser rellenadas en el destino.

Para señalizar un objeto, se escribe la información de su clase, seguida de los tipos y los nom bres de los campos. Si los campos pertenecen a una clase nueva, entonces también se escribe la información de la clase, seguida de los nombres y los tipos de sus campos. Este procedimiento recursivo continúa hasta que se haya escrito la información de todas las clases necesarias y de los nombres y tipos de sus campos. Cada clase recibe un apuntador, y ninguna clase se escribe más de una vez en el flujo de bytes (en su lugar se escribe su apuntador cuando sea necesario).

Los contenidos de los campos que sean tipos de datos primitivos, como enteros, caracteres, booleanos, bytes y enteros largos, se escriben en un formato binario transportable utilizando méto dos de la clase ObjetctOutpiítStream. Las cadenas de caracteres y los caracteres se escriben con los métodos llamados writeUTF utilizando el Formato de Transferencia Universal (Universal Transfer Format, UTF)

Corno ejemplo, considérese la serialización del siguiente objeto:

Persona p = new Persona(«Pérez», «Madrid», 1934);

Persona Número de versión de 8-bytes a0

3 Int año Java.lang.Stringnombre:

Java.lang.Stringlugar:

1934 5 Pérez Madrid A1

El primer campo (1934) es un entero que tiene una longitud fija, el segundo y el tercer campo son cadenas de caracteres que están precedidas por sus longitudes.

Para utilizar la serialización Java, por ejemplo para señalizar el objeto Persona, hay crear una instancia de la clase ObjectOutputStream e invocar a su método writeObject, pasándole el objeto Persona como argumento. Para deserializar un objeto desde un flujo de datos, hay que abrir un ObjectlnputStream sobre el flujo y utilizar su método readObject para reconstruir el objeto original

Reflexiones en JavaEs la habilidad de pregun tar sobre las propiedades de una clase, tales como los nombres y los tipos de sus campos y méto dos. Esto también hace posible que se creen las clases a partir de su nombre, y crear un constructor para una clase dada con unos argumentos dados. La reflexión hace posible hacer la señalización y la deserialización de una manera totalmente genérica.

La señalización de objetos Java utiliza la reflexión para encontrar el nombre de la clase del objeto a señalizar y los nombres, tipos y valores de sus variables de instancia. Esto es todo lo que se necesita en la forma señalizada.

Para la deserialización, se utiliza el nombre de la clase en la forma señalizada para crear un nuevo constructor con los tipos de argumentos correspondientes a aquellos especificados en la forma serializada

Referencia a Objetos RemotosCuando un cliente invoca un método en un objeto remoto, se envía un mensaje de invocación al proceso servidor que alberga el objeto remoto. Este mensaje necesita especificar el objeto particu lar cuyo método se va a invocar.

En el mensaje de invocación se incluye una referencia a objeto remoto que especifica cuál es el objeto invocado.

Las referencias a objetos remotos deber generarse de modo que se asegure su unicidad sobre el espacio y el tiempo.

Existen varios modos de asegurarse que una referencia a un objeto remoto es única. Un modo es construir una referencia a objeto remoto concatenando la dirección Internet de su computador y el número de puerto del proceso que lo creó junto con el instante de tiempo de su creación y un número de objeto local. El número de objeto local se incrementa cada vez que el proceso crea un objeto.El número de puerto junto al tiempo constituyen un identificador único en ese computador

El último campo de la referencia de objeto remoto mostrada en la Figura 4.10 contiene cierta información sobre la interfaz del objeto remoto, por ejemplo el nombre de la interfaz. Esta infor mación es relevante para cualquier proceso que reciba una referencia de objeto remoto como argu mento o resultado de una invocación remota, ya que necesitará conocer los métodos que ofrece el objeto remoto. Este punto se tratará de nuevo en la Sección 5.2.5.

Comunicación Cliente-ServidorEsta forma de comunicación está orientada a soportar los roles y el intercambio de mensajes de las interacciones típicas cliente-servidor. En el caso normal, la comunicación petición-respuesta es sín crona, ya que el proceso cliente se bloquea hasta que llega la respuesta del servidor.

En concreto:Los reconocimientos son redundantes, ya que

las peticiones son seguidas por las respuestas.El establecimiento de la conexión involucra

dos pares de mensajes extra además del par ne cesario para la petición de conexión y la consiguiente respuesta.

El control del flujo es redundante en la mayoría de las invocaciones, ya que éstas pasan sola mente una pequeña cantidad de información sobre argumentos y resultados.

El protocolo petición-respuesta Está basado en un trío de primiti vas de comunicación: hazOperacion, damePeticion, enviaRespuesta, según se muestra

Este protocolo de petición-respuesta, diseñado especialmente, hace corresponder a cada, peti ción una respuesta.

La primitiva hazOperacion envía un men saje de petición al servidor cuya dirección Internet y puerto se especifican en la referencia de obje to remoto dada como argumento. Después de enviar el mensaje de petición, hazOperacion invoca el método recibe para conseguir el mensaje respuesta, del que extrae el resultado y lo devuelve a su iñvocador. El invocador de hazOperacion se bloquea hasta que el objeto remoto en el servidor ejecuta la operación solicitada y transmite el mensaje respuesta al proceso cliente.

La primitiva damePeticion se usa en el servidor para hacerse con las peticiones de servicio.

El método enviaRespiiesta para mandar el mensaje de respuesta al cliente. Cuan do el cliente recibe el mensaje de respuesta, desbloquea la operación hazOperacion y continúa la ejecución el programa cliente.

El primer campo indica cuándo el mensaje es una petición o una respuesta. El segundo campo, idPeticion, contiene un identificador de mensajes. Una primitiva hazOperacion en el clien te genera un idPeticion para cada mensaje de petición, y el servidor lo copia en el correspondiente mensaje de respuesta. Esto hace posible que hazOperacion pueda comprobar que un mensaje de respuesta es el resultado de la petición actual, no de una invocación anterior que se ha retrasado.

Identificadores de mensaje Cualquier esquema que involucre la gestión de

mensajes para pro porcionar propiedades adicionales como la entrega fiable de mensajes o una comunicación petición-respuesta necesita que cada mensaje tenga un identificador único por el que pueda ser referenciado.

Un identificador de mensaje tiene dos partes:

Un identificador de petición, idPeticion, que proporciona el proceso emisor de una suce sión de enteros creciente.parte que hace que el identificador sea único para el emisor, y la segunda lo hace único para el sistema distribuido.

Un identificador para el proceso emisor, por ejemplo, su puerto y su dirección Internet.

Modelo de fallos del protocolo petición-respuesta

Si las tres primitivas se implementan con datagramas UDP, adolecerán de los mis mos fallos de comunicación que cualquier otro ejemplo de aplicación de UDP. Esto es:

Sufrirán fallos de omisión.No se garantiza que los mensajes lleguen en

el orden de emisión.

tiempo de espera límiteExisten varias opciones respecto a lo que la primitiva hazOperación puede hacer después de superar un timeout. La opción más simple es devolver inmediatamente el control indicando al cliente que la primitiva hazOperacion ha fracasado. Ésta no es la aproximación normal: se puede alcanzar un timeout debido a la pérdida de un mensaje de petición o de respuesta y, en el último caso, la operación se habrá realizado.

Para compensar la posibilidad de la pérdida de los mensajes. hazOperacion manda el mensaje de petición de forma repetida hasta que bien obtiene una respuesta o bien está razonablemente seguro que el retraso se debe a una falta de respuesta del servidor, más que a mensajes perdidos. En algún momento, cuando hazOperacion/i(;rO/^fwv'mp devuelva el control indicará al cliente mediante una excepción que no ha recibido resultado alguno.

eliminación de mensajes de petición duplicados

En los casos en los que el mensaje de petición es retransmitido, el servidor puede recibir más de uno. Por ejemplo, el servidor puede recibir el primer mensaje de petición pero precisará más tiempo que el timeout del cliente para ejecutar el comando y devolver la respuesta. Esto puede llevar a que el servidor ejecute una operación mas de una vez para la misma petición.

Para evitarlo, se diseñó el protocolo para reconocer sucesivos mensajes (del mismo cliente) con el mismo identificador de petición y para eliminar los duplica dos. Si el servidor no hubiera enviado aún la contestación, no necesita realizar ninguna operación especial, transmitirá la respuesta cuando termine de ejecutar la operación.

pérdida de mensajes de respuesta

Si el servidor ya ha enviado la respuesta cuando recibe una petición duplicada necesitará ejecutar otra vez la operación para obtener el resultado, a menos que haya almacenado el resultado de la ejecución original.

Una operación idempotente es una operación que puede ser llevada a cabo repetidamente con el mismo efecto que si hubiera sido ejecutada exactamente una sola vez. Un servidor cuyas operaciones sean todas idempotentes no tendrá que tomar medidas especiales para evitar que se ejecuten más de una vez.

historial En aquellos servidores que necesitan retransmitir las respuestas sin tener que volver a ejecutar las operaciones, es imprescindible la utilización de un historial.

Una entrada en el historial contiene un identificador de petición, un mensaje y un identificador del cliente al que fue enviado. Su propósito es permitir que el servidor pueda retransmitir los mensajes de respuesta cuando los clientes se lo soliciten. Un problema aso ciado con el uso del historial es el coste de almacenamiento. Un historial se volverá demasiado grande a menos que el servidor pueda decidir cuándo no será necesario seguir almacenando un mensaje para su retransmisión.

Protocolo de intercambio de RPC En la implementación de los distintos tipos de

RPC se utilizan tres protocolos, con diferentes semánticas en presencia de fallos de comunicación. Inicialmente fueron identificados por Spector [1982]:

El protocolo petición (R).El protocolo R (request) puede utilizarse cuando el procedimiento no tiene que devolver ningún valor y el cliente no necesi ta confirmación de que el procedimiento ha sido ejecutado. El cliente puede seguir inmediatamente después de haber enviado el mensaje de petición ya que no tiene que esperar un mensaje de res puesta.

El protocolo RR (request-reply) Es útil en la mayoría de los intercambios cliente-servidor, pues se basa en el protocolo petición-respuesta. No se necesitan mensajes especiales de acuse de recibo, ya que los mensajes de respuesta del servidor sirven como confirmación de las peticiones del cliente. Similarmente, una subsiguiente llamada desde un cliente podría ser considerada como un reconocimiento del mensaje de respuesta del servidor.

El protocolo RRA (reqiiest-reply-acknowledge reply) Está basado en el intercambio de tres mensajes: petición-respuesta-confirmación de la respuesta. El mensaje de reconocimiento de la res puesta contiene el idPeticion del mensaje de respuesta que reconoce. Esto hace posible que el ser vidor pueda descartar las entradas de su historial.

Utilización de streams TCP para implementar el protocolo petición-respuesta En el protocolo petición-respuesta, esto se

aplica a los búferes utilizados por el servidor para recibir los mensajes de petición de los clientes y por el cliente para recibir las respuestas. La limitada longitud de los datagramas (normalmente 8 kilobytes) no se puede considerar como adecuada para su uso en sistema RMI transparentes, ya que los argumentos o resultados de los procedimientos pueden ser cual quier tamaño.

HTTP: UN EJEMPLO DE PROTOCOLO PETICION-RESPUESTA

El Capítulo I presentó el Protocolo de Transferencia de Hipertexto utilizado por los navega dores web para realizar peticiones a los servidores web y para recibir las respuestas de ellos. Valga recordar, como recapitulación, que los servidores web gestionan recursos implementados de diferentes modos:

* Como datos, por ejemplo el texto de una página HTML, una imagen o la clase de un applct.

* Como programa, por ejemplo los programas CGI y los Servlets que puede ser ejecutado en el servidor web.

Las peticiones de los clientes especifican un URL que incluye el nombre DNS del host del servidor web y un número de puerto opcional, además del identificador de un recurso en el servidor.

HTTP es un protocolo que especifica los mensajes involucrados en un intercambio petición-respuesta, los métodos, argumentos y resultados y las reglas para representar (empaquetar) todo ello en los mensajes.

Soporta un conjunto fijo de métodos (GET, PUT, POST, etc.) que son aplica bles a todos los recursos.

Al contrario de los protocolos anteriores, cada objeto tiene sus propios métodos. Además de invocar métodos sobre recursos web, el protocolo permite la negociación de contenidos y una autenticación del tipo clave de acceso.

Negociación del Contenido :las peticiones de los clientes pueden incluir información sobre qué tipo de representación de datos pueden aceptar (por ejemplo lenguaje o tipo de medio), hacien do posible que el servidor pueda elegir la representación más apropiada para el usuario.

Autenticación :se utilizan credenciales y desafíos para conseguir una autenticación del estilo clave de acceso. En el primer intento de acceso al área protegida por palabra clave, el servidor responde con un desafío aplicable al recurso. El Capítulo 7 explica los desafíos. Cuando el cliente recibe el desafío pide al usuario un nombre y una palabra de paso, y se los envía al servidor en las siguientes solicitudes. HTTP se implementa sobre TCP.

En la versión original del protocolo, cada interacción cliente-servidor se componía de los siguientes pasos: El cliente solicita una conexión al puerto del servidor por

defecto o a otro especificado en la petición aceptada por el servidor. El cliente envía un mensaje de petición al servidor. El servidor envía un mensaje de respuesta al cliente. Se cierra la conexión.

Sin embargo, la necesidad de establecer y cerrar una conexión para cada intercambio petición-respuesta resulta cara, sobrecargando al servidor y enviando demasiados mensajes por la red. Teniendo en cuenta que los navegadores generalmente hacen múltiples peticiones al mismo servidor

la siguiente versión del protocolo (HTTP 1.1) utiliza conexiones persistentes; conexiones que permanecen abiertas durante una serie de intercambios petición-respuesta entre el cliente y el servidor.

Una conexión persistente puede ser cerrada por el cliente o por el servidor en cualquier instante enviando una indicación al otro participante.

Las peticiones y las respuestas se empaquetan en los mensajes como cadenas de caracteres AS CII, aunque los recursos que pueden representarse como secuencias de bytes quizás tengan que ser comprimidos. El uso del texto como representación de datos externa simplifica el uso del HTTP por parte de los programadores de aplicaciones que trabajan directamente con el protocolo.

Los recursos considerados como datos se proporcionan en forma de estructuras de tipo MIME tanto en los argumentos como en los resultados. Miiltipurpose Internet Malí Extensiones (Extensio nes de Correo Electrónico Multipropósito, MIME) es un estándar para enviar mensajes de correo electrónico compuestos por varias partes conteniendo a la vez, por ejemplo, texto, imágenes y sonido. Los datos van precedidos por su tipo Mime, de modo que el receptor podrá saber cómo gestionarlos. Un tipo Mime especifica un tipo y un subtipo, por ejemplo, text/plain, text/html, image/gif, image/jpeg.

METODOS HTTP:

Pide el recurso cuyo URL se da como argumento. Si el URL se refiere a datos, entonces el servidor responderá enviando de vuelta los datos indicados por el URL. Si el URL se refiere a un programa, entonces el servidor web ejecutará el programa y devolverá su salida al cliente.

GET:

HEAD:

Esta petición es idéntica a GET, sólo que no devuelve datos. Sin embargo, devuelve toda la información sobre los datos, como el tiempo de la última modificación, su tipo o tamaño.

Especifica el URL de un recurso (por ejemplo un programa) que puede tratar los datos aportados con la petición. El procesamiento llevado a cabo sobre los datos depende del progra ma especificado en el URL. Este método está diseñado para:

Proporcionar un bloque datos (por ejemplo los obtenidos en un formulario) a un proceso de gestión d£ datos como un Servlet o un programa CGI.

Enviar un mensaje a un tablón de anuncios, lista de correo o grupo de noticias.

Modificar una base de datos con una operación de añadir registro.

POST:

Indica que los datos aportados en la petición deben ser almacenados con la URL aportada como su identificador, ya sea como una modificación de datos existentes o como la creación de un recurso nuevo.

PUT:

DELETE:

El servidor borrará el recurso identificado por el L'RL. El servidor no siempre permi tirá esta función, en cuyo caso se devolverá una indicación de fallo.

DELETE:

OPTIONS:

El servidor proporciona al cliente una lista de métodos aplicables a un URL (por ejemplo, GET, HEAD, PUT) y sus requisitos especiales

El servidor envía de vuelta el mensaje de petición. Se utiliza en procesos de depura ción.

CONTENIDOS DEL MENSAJE :

Cada mensaje HTTP Request especifica el nombre de un método, el URL de un recurso, la versión del protocolo, algunas cabeceras y un cuerpo de mensaje opcional.

Método URL Versión Cabecera Cuerpo

La Figura muestra el contenido de un mensaje HTTP Request cuyo método es GET. Cuando la URL específica es un recurso de datos, el método GET no incluye cuerpo del mensaje. Un proxy necesita el URL completo, tal y como se muestra en la figura, aunque tiene sus ventajas enviar sólo la ruta en el caso de un servidor origen, dado que se envían menos datos.

Los campos de la cabecera contienen modificadores de la petición e información sobre el cliente, como las condiciones sobre la última fecha de modificación del recurso o los tipos de contenido aceptables (por ejemplo texto HTML o imágenes JPEG).

GET //WWW.DES.QMW/INDEX.HTML

HTTP/1.1

Un mensaje Reply especifica la versión del protocolo, un código de estado y su razón, algunas cabeceras y un cuerpo de mensaje opcional.

Version Codigo estado Razon Cabecera Cuerpo

El código de estado y la razón proporcionan un informe sobre el éxito o cualquier otra situación asociada al cumplimiento de la petición. El primero es un entero de tres dígitos que deben ser interpretados por el programa cliente, y el último es una frase de texto que debe ser entendida por la persona usuaria. Los campos de cabecera se utilizan para pasar información adicional sobre el servidor o sobre el acceso al re curso. Por ejemplo, si la petición requiere autenticación, el estado de la respuesta indica este extre mo y un campo de la cabecera contiene el desafío. Algunas informaciones de estado devueltas tie nen efectos más complejos.

HTTP 1.1

200 OK Datos del recurso

COMUNICACIÓN EN GRUPO

El intercambio de mensajes entre iguales no es mejor modelo para la comunicación entre un proceso y un grupo de procesos, como por ejemplo se da en el caso de un servicio implementado por varios procesos en diferentes computadores, quizás para proporcionar tolerancia a fallos o mejorar la disponibilidad. Resulta más apropiada una operación de multidifusión; ésta es una operación que envía un único mensaje desde un proceso a cada uno de los miembros de un grupo de procesos, normalmente de modo que la pertenencia al grupo resulte transparente para el emisor.

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

1. Tolerancia a fallos basada en servicios replicados: un servicio replicado consta de un grupo de servidores. Las solicitudes de los clientes se dirigen a todos los miembros del grupo y cada uno de ellos realiza La misma operación. Incluso cuando varios de los miembros fallen, los clientes todavía serán servidos.

2. Búsqueda de los servidores de descubrimiento en redes espontáneas: Los servidores y los clientes pueden utilizar la multidifusión mensajes para localizar los servicios disponibles, y registrar sus interfaces, o para buscar las interfaces de otros servicios en el sistema distribuido.

3. Mejores prestaciones basada en datos replicados: los datos se replican para incrementar las prestaciones de un servicio; en algunos casos se colocan réplicas de los datos en los compu tadores de los usuarios. Cada vez que se producen cambios en los datos, el nuevo valor se comunica a los procesos que gestionan las réplicas de los datos mediante multidifusión.

4. Propagación de las notificaciones de eventos: la multidifusión a un grupo puede utilizarse para notificar a los procesos que algo ha sucedido. Por ejemplo, un sistema de noticias podría advertir a los usuarios interesados cada vez que se dirige un nuevo mensaje a un grupo de noticias particular. El sistema Jini utiliza multidifusión para informar a los usua rios interesados que se ha descubierto un nuevo servicio.

MULTIDIFUSION IP :

La multidifusión IP se construye sobre el protocolo Internet, IP. Tenga en cuenta que los paquetes IP se dirigen a los computadores; mientras que los puertos pertenecen a los niveles TCP y UDP.

La multidifusión IP permite que el emisor transmita un único paquete IP a un conjunto de computadores que forman un grupo de multidifusión. El emisor no tiene que estar al tanto de las identidades de los receptores individuales y del tamaño del grupo. Los grupos de mul tidifusión se especifican utilizando las direcciones Internet de la clase D.

El convertirse en miembro de un grupo de multidifusión permite al computador recibir los pa quetes IP enviados al grupo. La pertenencia a los grupos de multidifusión es dinámica, permitiéndose que los computadores se apunten o se borren a un número arbitrario de grupos en cualquier instante.

En el nivel IP, un computador pertenece a un grupo de multidifusión cuando uno o más de sus procesos tienen conectores que pertenezcan a ese grupo. Cuando llega un mensaje de multidi fusión a un computador, envía copias del mismo a los conectores locales que pertenecen a la direc ción de multidifusión destino del mensaje y están limitadas por el número de puerto especificado.

Los siguientes detalles son específicos de IPv4:

Routers multidifusión: los paquetes IP pueden multidifundirse tanto en la red local como en toda Internet. La multidifusión local utiliza la capacidad de multidifusión de la red local, como por ejemplo una Ethernet. La multidifusión dirigida a Internet hace uso de las posibilidades de multidifusión de los routers (encaminadores), los cuales reenvían los datagramas únicamente a otros routers de redes con miembros de ese grupo, donde serán multidifundidos a los miembros locales.

Reserva de direcciones de multidifusión: las direcciones de multidifusión se pueden reservar de forma temporal o permanentemente. Existen grupos permanentes incluso cuando no tengan ningún miembro; y sus direcciones son asignadas arbitrariamente por la autoridad de Internet en el rango 224.0.0.1 a 224.0.0.255.

El resto de las direcciones de multidifusión están disponibles para su uso por parte de grupos temporales, los cuales deben ser creados antes de su uso y dejar de existir cuando todos los miembros los hayan dejado.

Cuando se crea un grupo temporal, se necesita una dirección de multidifusión libre para evitar los conflictos con otros grupos existentes.

MODELO DE FALLO PARA LA DIFUSION DE DATAGRAMAS :

La multidifusión de datagramas sobre la multidifusión IP tiene las mismas características de fallo que los datagramas UDP; esto es, sufren de fallos de omisión. El efecto en una multidifusión es que no se garantiza que los mensajes sean entregados a cualquier miembro particular del grupo en presencia de incluso un único fallo de omisión. Esto es, alguno, pero no todos los miembros del grupo pueden recibir el mensaje. Esto puede denominarse multidifusión no fiable, ya que no existe garantía de que un mensaje sea entre gado a cualquier miembro del grupo.

API JAVA PARA LA DIFUSION :

El API Java para la multidifusión IP proporciona una interfaz de datagramas para la multidifusión IP a través de la clase MulticastSocket, que es una subclase de DatagramSocket con la capacidad adicional de ser capaz de pertenecer a grupos de multidifusión. La clase MulticastSocket proporciona dos constructores alternativos, permitiendo crear los conectores utilizando un número de puerto local concreto, o cualquier puerto local libre.

El API Java permite fijar el TTL para un conector multidifusión mediante el método setTimeTolive. El valor por defecto es I, permitiendo que la multidifusión se propague sólo en la red local.

FIABILIDAD Y ORDEN EN MULTIDIFUSION :

La sección previa ha fijado el modelo de fallos de la multidifusión IP. Esto es, que sufre de fallos de omisión. En la multidifusión en redes de área local que utilizan las capacidades de multidifusión de la red para permitir que un único datagrama llegue a múltiples receptores, cualquiera de esos receptores puede perder un mensaje debido a que su búfer se encuentre lleno. También se puede perder un datagrama enviado de un router multidifusión a otro, impidiendo de este modo que todos los receptores más allá de ese router reciban el mensaje.

Otro factor es que cualquier proceso puede malograrse. Si falla un router de multidifusión, los miembros del grupo al otro lado del router no recibirán el mensaje multidifusión, aunque los miembros locales lo hagan.

Otra cuestión es el orden. Los paquetes enviados sobre IP en una interred no llegan necesaria mente en el orden en que fueron enviados, con el efecto posible de que algunos miembros del gru po reciban los datagramas del mismo emisor en un orden diferente a otros miembros del grupo. Además, los mensajes enviados por dos procesos diferentes no llegarán necesariamente en el mis mo orden a todos los miembros del grupo.

COMUNICACIÓN DE DATAGRAMAS Para poder enviar datagramas, se identifica el par de conectores

cada vez que se realiza una comu nicación. Esto se logra en el proceso emisor utilizando su descriptor de conector local y la direc ción del conector receptor cada vez que envía un mensaje.

Enviando un mensaje Recibiendo un mensaje

DireccionServidor y Direccion Cliente son direcciones de conectores.

s = socket(AFJNET,SOCK_DGRAM, 0)••bind(s, DireccionCliente)••sendto(s, "mensaje",DireccionServidor)

s = socket(AFJNET,SOCK_DGRAM, 0)••bind(s, DireccionServidor)••- cantidad=recvfrom(s, búfer, desde)

COMUNICACIÓN DE STREAMS

Antes de utilizar el protocolo de streams, dos procesos deben establecer una conexión entre sus pares de conectores. El acuerdo es asimétrico porque uno de los conectores estará escuchando peticiones de conexión y el otro estará preguntando por una conexión. Una vez que un par de conectores han sido conectados, pueden utilizarse para transmitir datos en ambas o en cualquier dirección. Esto es, se comportan como streams en los que cualquier dato disponible se lee inmediatamente en el mismo orden en que fue escrito y no existen indicaciones de fronteras entre los mensajes. Sin embargo, existe una cola limitada en el conector receptor y el receptor se bloqueará si la cola está vacía; y el emisor se bloqueará si la cola está llena.

s = socket(AFJNET,SOCK_STREAM, 0)• »connect(s, DireccionServidor)•*sendto(s, "mensaje"tDireccionServidor)

s = socket(AFJNET,SOCK_STREAM••bind(s, DireccionServidor);listen(s,5);•sNuevo=accept(s, DireccionCliente); n=read(sNuevo, búfer, cantidad)

Solicitando una Conexión

Escuchando y Aceptando una Conexión

DireccionServidor y Dirección Cliente son direcciones de conectores.