Académique Documents
Professionnel Documents
Culture Documents
APLICACIONES DISTRIBUIDAS
La comunicacin entre procesos (IPC) conforma el eje central de la computacin
distribuida. Los principios de los mecanismos de IPC incluyen lo siguiente:
Comunicacin entre procesos (IPC): La posibilidad de que procesos
independientes, y separados se comuniquen entre ellos para colaborar en una
tarea. Cuando una comunicacin se realiza nicamente de un proceso a otro, el
mecanismo IPC se denomina unidifusin. Cuando la comunicacin se realiza entre
un proceso y un grupo de procesos, el mecanismo IPC es multidifusin.
Una API bsica de funcionalidades para IPC debe proporcionar:
o Primitivas de operacin: enviar, recibir, conectarse, y desconectarse.
o La sincronizacin de eventos permite que procesos relacionados se
ejecuten independientemente, sin conocimiento de lo que ocurre en el otro
extremo. La forma ms sencilla para que un mecanismo de comunicacin
permita sincronizacin es por medio de bloqueos. Las operaciones que son
bloqueantes se denominan a menudo operaciones sncronas, mientras que
las que no son bloqueantes se llaman tambin operaciones asncronas.
Los interbloqueos pueden aparecer debido al uso de operaciones
bloqueantes. La utilizacin de hilos de ejecucin (threads) o procesos
permiten la realizacin de otras tareas a un proceso que an espera que
una operacin bloqueante se complete.
o El empaquetamiento de datos (data marshaling) necesario para preparar
los datos para su transmisin por red, est compuesto por los siguientes
pasos: (i) serializacin de las estructuras de datos, y (ii) conversin de los
valores de datos a una representacin externa o de red.
Existen diferentes esquemas de representacin de datos de red a diferentes
niveles de abstraccin. Algunos de los ms conocidos son Sun XDR(External Data
Representation), ASN.1 (Abstract Syntax Notation Number 1) and XML (Extensible
Markup Language).
El empaquetamiento de datos es ms sencillo cuando los datos a transmitir son
una secuencia de caracteres o texto representado por medio de una codificacin
de tipo ASCII. Los protocolos que utilizan texto se denominan protocolos basados
en texto.
Los protocolo del tipo solicitud-respuesta son protocolos que envan iterativamente
mensajes de solicitud y de respuesta hasta que se completen las tareas.
Un diagrama de eventos se utiliza para documentar la secuencia detallada de
eventos y bloqueos en un protocolo. Un segmento continuo a lo largo de la lnea
de ejecucin representa el periodo de tiempo durante el cual el proceso est
activo. Una lnea discontinua representa que el proceso est bloqueado.
Un diagrama de secuencia es parte de la notacin UML y se utiliza para
documentar iteraciones entre procesos que son complejas. En un diagrama de
secuencia, el flujo de ejecucin de cada participante del protocolo se representa
por una lnea discontinua y no se diferencia entre estados de bloqueo y ejecucin.
Las funcionalidades de comunicacin entre procesos pueden ser orientadas o no
orientadas a conexin:
o Por medio de los mecanismos orientados a conexin, dos procesos
establecen una conexin lgica, para posteriormente intercambiar datos
Es muy comn en este tipo de comunicacin lanzar un proceso hijo, una vez realizada la
conexin, que se ocupe del intercambio de informacin con el proceso cliente mientras el
proceso padre servidor sigue aceptando conexiones. Para eliminar esta caracterstica se
cerrar el descriptor del socket servidor con nombre en cuanto realice una conexin con
un proceso socket cliente.
-> Todo socket viene definido por dos caractersticas fundamentales:
- El tipo del socket, que indica la naturaleza del mismo, el tipo de comunicacin que
puede generarse entre los sockets.
- El dominio del socket especifica el conjunto de sockets que pueden establecer una
comunicacin con el mismo.
Tipos de sockets.
Define las propiedades de las comunicaciones en las que se ve envuelto un socket,
esto es, el tipo de comunicacin que se puede dar entre cliente y servidor. Estas pueden
ser:
- Fiabilidad de transmisin.
- Mantenimiento del orden de los datos.
- No duplicacin de los datos.
- El "Modo Conectado" en la comunicacin.
- Envo de mensajes urgentes.
Los tipos disponibles son los siguientes:
* Tipo SOCK_DGRAM: sockets para comunicaciones en modo no conectado, con
envo de datagramas de tamao limitado ( tipo telegrama ). En dominios Internet como
la que nos ocupa el protocolo del nivel de transporte sobre el que se basa es el UDP.
* Tipo SOCK_STREAM: para comunicaciones fiables en modo conectado, de dos
vas y con tamao variable de los mensajes de datos. Por debajo, en dominios Internet,
subyace el protocolo TCP.
* Tipo SOCK_RAW:
( nivel de red )
SOCK_STREAM pero
El dominio de un socket.
Indica el formato de las direcciones que podrn tomar los sockets y los protocolos que
soportarn dichos sockets.
La estructura genrica es
struct sockaddr {
u__short sa__family;
char
sa__data[14];
};
/* familia */
/* direccin */
Pueden ser:
* Dominio AF_UNIX ( Address Family UNIX ):
El cliente y el servidor deben estar en la misma mquina. Debe incluirse el
fichero cabecera /usr/include/sys/un.h. La estructura de una direccin en este dominio
es:
struct sockaddr__un {
short
sun__family; /* en este caso AF_UNIX */
char
sun__data[108]; /* direccin */
};
* Dominio AF_INET ( Address Family INET ):
El cliente y el servidor pueden estar en cualquier mquina de la red Internet.
Deben incluirse los ficheros cabecera /usr/include/netinet/in.h, /usr/include/arpa/inet.h,
/usr/include/netdb.h. La estructura de una direccin en este dominio es:
struct in__addr {
u__long s__addr;
};
struct sockaddr__in {
short
sin_family; /* en este caso AF_INET */
u__short sin_port; /* numero del puerto */
struct in__addr
sin__addr; /* direcc Internet */
char
sin_zero[8]; /* campo de 8 ceros */
};
Estos dominios van a ser los utilizados en xshine. Pero existen otros como:
* Dominio AF_NS:
Servidor y cliente deben estar en una red XEROX.
* Dominio AF_CCITT:
Para protocolos CCITT, protocolos X25, ...
COMUNICACIN DE DATAGRAMAS UDP Y STREAMS TCP
Propiedades del datagrama UDP
Bloqueo
envia() no bloqueante,
recibe() bloqueante (posibilidad de indicar un timeout)
Identidad del emisor
El socket de recepcion suele estr abierto a cualquier emisor
es posible vincular el receptor a una sola IPAddr remota
Modelo de fallo
Fallos por omisin en el canal (que incluye los del emisor y del receptor)
provocados por desbordamiento de bfer, prdida de mensajes, o corrupcin.
Para detectar la corrupcion, se puede aadir un \checksum"
Fallos de ordenacion en la llegada
Utilizacion de UDP, cuando no es preciso almacenar informacion de estado en
origen ni en destino es preciso reducir el intercambio de mensajes el emisor no se
bloquea
send y receive
Aspectos importantes
o Concordancia de tipos de datos
o Los procesos deben conocer el tipo de datos que se envian reciben
Bloque
Modelo de fallo
o TCP usa: numeros de secuencia, checksums y timeouts.
o Cuando el numero de errores es excesivo o se sobrepasa el tiempo limite
se declara rota la conexion.
o no se distingue un fallo en el proceso del fallo en la conexion.
o no se asegura la recepcion en caso de error.
TCP es la base de: HTTP, FTP, SMTP, Telnet (el cliente de telnet se puede usar
para conectarse con cualquier servidor).
ServerSocket: crear el socket en el lado del servidor para escuchar las solicitudes
de conexion
Socket: para procesos con conexion
o constructor para crear un socket y conectarse a un host y
puerto remoto de un servidor
Socket accept ( )
Socket throws UnknownHostException
throws IOException
o metodo para acceder a ujo de entrada y salida
InputStream getInputStream ( )
OutputStream getOutputStream ( )
define ningn mtodo. Simplemente se usa para 'marcar' aquellas clases cuyas instancias
pueden ser convertidas a secuencias de bytes (y posteriormente reconstrudas). Objetos
tan comunes como String, Vector o ArrayList implementan Serializable, de modo que
pueden ser serializados y reconstrudos ms tarde. http://www.javahispano.com2Para
serializar un objeto no hay ms que declarar el objeto como serializable: public class
MiClase implements java.io.Serializable El sistema de ejecucin de Java se encarga de
hacer la serializacin de forma automtica. Ejemplos Almacenamiento de objetos Es
posible utilizar los mecanismos de serializacin disponibles para serializar un objeto
guardndolo en un fichero y para realizar el proceso inverso, recuperndolo desde el
fichero.
FileOutputStream fos = new FileOutputStream("fichero.bin");
FileInputStream fis = new FileInputStream("fichero.bin");
ObjectOutputStream out = new ObjectOutputStream(fos);
ObjectInputStream in = new ObjectInputStream(fis);
ClaseSerializable o1 = new ClaseSerializable();
ClaseSerializable o2 = new ClaseSerializable(); // Escribir el objeto en el fichero
out.writeObject(o1); out.writeObject(o2); . . . // Leer el objeto del fichero (en el mismo
orden !!) o1 = (ClaseSerializable)in.readObject(); o2 = (ClaseSerializable)in.readObject();
Envo de objetos por la red Tambin es posible enviar un objeto serializado a travs de la
red. La diferencia consiste en que ahora se utilizan streams de distinto tipo.
Socket socket = new Socket(maquina, puerto); OutputStream os =
socket.getOutputStream();
InputStream is = socket.getInputStream();
ObjectOutputStream out = new ObjectOutputStream(os);
ObjectInputStream in = new ObjectInputStream(is);
PeticionSerializable ps = new PeticionSerializable();
RespuestaSerializable rs; // Escribir una peticin en el socket out.writeObject(ps); //
Recibir del socket la respuesta rs = (RespuestaSerializable)in.readObject();
Serializacin en RMI En RMI, la serializacin se utiliza de forma casi transparente al
usuario. Concretamente, se utiliza en el paso de parmetros y retorno de valores de las
invocaciones a mtodos de objetos remotos. Por ejemplo, cuando hacemos una
invocacin remota del tipo retorno obj.metodo(param);Serializacin de objetos3ocurre el
siguiente proceso, de forma transparente al usuario: 1.(Local) El objeto param se serializa
y se enva al objeto remoto como una secuencia de bytes 2.(Remoto) Se obtiene el objeto
original a partir de la secuencia de bytes 3.(Remoto) Se ejecuta el mtodo y se obtiene un
valor de retorno 4.(Remoto) El valor de retorno se serializa y se enva como una
secuencia de bytes 5.(Local) Se obtiene el retorno a partir de la secuencia de bytes Para
que esta invocacin se lleve a cabo, es necesario que tanto los parmetros de las
invocaciones remotas como los valores devueltos pertenezcan a clases serializables.
Serializacin personalizada En ocasiones puede interesar tomar el control sobre el
proceso de serializacin de una clase en concreto. Esto se puede hacer 'sobrecargando'
los mtodos writeObject y readObject de la clase cuya serializacin se quiere controlar. En
realidad, no se puede hablar de sobrecarga, puesto que estos mtodos no estn definidos
en java.lang.Object. Este punto es un poco oscuro. Puede consultarse el API al respecto
(mtodo writeObject(Object) de ObjectOutputStream java.io.ObjectOutputStream y
mtodo readObject() de ObjectInputStream) y el JavaTutorial (Essential Java Classes ->
Reading and Writing (but no 'rithmetic) -> Object Serialization -> Providing Object
OBJETOS REMOTOS
El sistema RMI (Java Remote Method Invocation) es un mecanismo que permite a un
objeto en una mquina virtual Java llamar a mtodos de objetos en otra mquina virtual
Java. Cualquier objeto cuyos mtodos puedan ser invocados de esta forma debe
implementar el interface java.rmi.Remote. Cuando dicho objeto es invocado, sus
argumentos son formateados y envados desde la mquina virtual local a la remota,
donde los argumentos son des-formateados y usados. Cuando el mtodo termina, los
resultados son formateados desde la mquina remota y envados a la mquina virtual del
llamador.
Para hacer que un objeto remoto sea accesible para otras mquinas virtuales, un
programa lo coloca tpicamente con el registro RMI. El programa suministra al registro el
nombre del objeto remoto as como el propio objeto. Cuando un programa desea tener
acceso a un objeto remoto, suministra el nombre del objeto al registro que est en la
misma mquina que el objeto remoto. El registro devuelve al llamador una referencia
(llamada stub [esqueleto]) al objeto remoto.
Cuando el programa recibe el stub del objeto remoto, puede llamar a sus mtodos (a
travs del stub).
Un programa tambin puede obtener referencias a objetos remotos como resultado de
llamadas a otros objetos remotos o desde otros servicios de nombres. Por ejemplo, el
programa puede buscar una referencia a un objeto remoto desde un servidor LDAP que
soporta el esquema definido en la RFC 2713.
El nombre aceptado por el registro RMI tiene la sntaxis:
"rmi://hostname:port/remoteObjectName", donde hostname y port identifican la
mquina y el puerto, respectivamente, en los que se est ejecutando el registro RMI y
remoteObjectName es el nombre del objeto remoto. hostname, port, y el prefijo, "rmi:",
son opcionales. Si no se especifica hostname, el valor por defecto es el host local. Si no
se especifica el puerto, el valor por defecto es 1099. Si no es especifica
Despus de que el objeto se haya unido al directorio, una aplicacin puede buscarlo
usando el siguiente cdigo.
Hello h2 = (Hello)ctx.lookup("cn=RemoteHello");
h2.sayHello();
Para ejecutar este ejemplo, debemos hacer lo siguiente.
1. Compilar Hello.java, HelloImpl.java y este ejemplo.
2. # javac Hello.java HelloImpl RemoteObj.java
3. Ejecutar rmic con HelloImpl como argumento para producir los stubs (esqueletos)
del objeto remoto.
4. # rmic HelloImpl
5. Copiar Hello.class, HelloImpl.class y los ficheros class generados por el rmic a
un directorio del servidor Web.
6. Especificar este directorio como el codebase para el intrprete Java.
7. # java -Djava.rmi.server.codebase=http://web1/example/classes/ RemoteObj
RemoteObj no termina, porque crea el objeto remoto HelloImpl con el que otros clientes
RMI pueden contactar para usarlo. Sin embargo, este programa terminar eventualmente,
cuando el objeto remoto se convierta en recolectable para la basura. Para evitar esto,
debemos mantener (viva) una referencia al objeto remoto. Si hemos registrado el objeto
en el registro RMI, entonces mantener una referencia no ser necesario porque el registro
la mantiene automticamente.
Cuando posteriormente busquemos el objeto desde el directorio, ste devolver el objeto
HelloImpl unido. El RMI descargar automticamente las clases necesarias desde el
codebase especificado en la propiedad "java.rmi.server.codebase".
Unir un Objeto Remoto Usando un Referencia
Antes de continuar:
Este ejemplo requiere que hayamos arrancado el registro RMI en nuestra mquina.
Tambin necesitamos rmiregistry.jar, como se explic anteriormente.
El siguiente ejemplo usa la mismas clases Hello y HelloImpl del ejemplo anterior. Crea
una Reference que contiene una URL RMI ("rmi://mymachine/hello") y la une al
directorio.
String rmiurl = "rmi://mymachine/hello";
Origen de los socket tuvo lugar en una variante del sistema operativo Unix conocida como
BSD Unix. En la universidad de Berkeley, en los inicios del Internet, pronto se hizo
evidente que los programadores necesitaran un medio sencillo y eficaz para escribir
programas capaces de intercomunicarse entre s. Esta necesidad dio origen a la primera
especificacin e implementacin de sockets.
Cliente-Servidor es el modelo que actualmente domina el mbito de comunicacin, ya que
descentraliza los procesos y los recursos. Es un Sistema donde el cliente es una
aplicacin, en un equipo, que solicita un determinado servicio y existe un software, en otro
equipo, que lo proporciona.
Los servicios pueden ser;
a)Ejecucin de un programa. b)Acceso a una Base de Datos. c)Acceso a un dispositivo de
hardware.
Solo se requiere un medio fsico de comunicacin entre las maquinas y depender de ala
naturaleza de este medio la vialidad del sistema.
Definicin de Socket: designa un concepto abstracto por el cual dos programas
(posiblemente situados en computadoras distintas) pueden intercambiarse cualquier flujo
de datos, generalmente de manera fiable y ordenada.
Los sockets proporcionan una comunicacin de dos vas, punto a punto entre dos
procesos. Los sockets son muy verstiles y son un componente bsico de comunicacin
entre interprocesos e intersistemas. Un socket es un punto final de comunicacin al cual
se puede asociar un nombre.
Para lograr tener un socket es necesario que se cumplan ciertos requisitos
1.Que un programa sea capaz de localizar al otro. 2.Que ambos programas sean capaces
de intercambiarse informacin.
Por lo que son necesarios tres recursos que originan el concepto de socket
a)Un protocolo de comunicaciones, que permite el intercambio de octetos.
b)Una direccin del Protocolo de Red (Direccin IP, si se utiliza el Protocolo TCP/IP), que
identifica una computadora.
c)Un nmero de puerto, que identifica a un programa dentro de una computadora. Con un
socket se logra implementar una arquitectura cliente-servidor. la comunicacin es iniciada
por uno de los programas (cliente). Mientras el segundo programa espera a que el otro
inicie la comunicacin (servidor). Un Socket es un archivo existente en el cliente y en el
servidor.
Si un socket es un punto final de un puente de comunicaron de dos vas entre dos
programas que se comunican a travs de la red, Cmo funciona?. Normalmente, un
servidor funciona en una computadora especfica usando un socket con un nmero de
puerto especifico. El cliente conoce el nombre de la maquina (hostname) o el IP, en la cual
el servidor esta funcionando y el numero del puerto con el servidor esta conectado.
Si el cliente lanza una demanda de conexin y el servidor acepta la conexin, este abre
un socket en un puerto diferente, para que pueda continuar escuchando en el puerto
original nuevas peticiones de conexin, mientras que atiende a las peticiones del cliente
conectado. El cliente y el servidor pu8eden ahora comunicarse escribiendo o leyendo en
sus respectivos sockets.
Los tipos de socket definen las propiedades de comunicacin visibles para la aplicacin.
Los procesos se comunican solamente entre los sockets del mismo tipo. Existen cinco
tipos de sockets.
El Cliente acta de la siguiente forma.
1)Establece una conexin con el servidor (Crea un socket con el servidor).
2)Mandar mensajes al servidor o Esperar un mensaje de l.(Consultas)
3)Esperar su respuesta o contestarle(existen casos en que este paso no es necesario).
4)Repetir los pasos 2 y 3 mientras sea necesario.
5)Cerrar la conexin con el servidor.
El servidor acta as.
1)Inicializa un puerto de comunicacin, en espera de clientes que intenten conectarse a l
(Crea un serverSocket).
2)Una vez que se conecta alguien, crea un hilo de ejecucin para este usuario mientras
que el thread principal vuelve al paso 1. Esto comunmente se hace para que el servidor
puede atender a varios clientes al mismo tiempo.
3)Se comunica con el cliente mediante el socket creado entre el cliente y l.
4)Espera que el cliente se vaya o lo bota el mismo servidor (Cierrra el socket entre ellos) y
elimina el thread de comunicacin entre ellos.
Las propiedades de un socket dependen de las caractersticas del protocolo en el que se
implementan. El protocolo ms utilizado es TCP, aunque tambin es posible utilizar UDP o
IPX. Gracias al protocolo TCP, los sockets tienen las siguientes propiedades:
I.Orientado a conexin. Se garantiza la transmisin de todos los octetos sin errores ni
omisiones.
II.Se garantiza que todo octeto llegar a su destino en el mismo orden en que se ha
transmitido.
Los tipos de socket definen las propiedades de comunicacin visibles para la aplicacin.
Los procesos se comunican solamente entre los sockets del mismo tipo. Existen tres tipos
bsicos de sockets.
Socket de flujo : da un flujo de datos de dos vas, confiable, y sin duplicados sin lmites de
grabacin. El flujo opera en forma parecida a una conversacin telefnica. El tipo del
socket es SOCK_STREAM, el cual en el dominio de Internet usa TCP (Transmission
Control Protocol).
Socket de datagrama
Soporta un flujo de mensajes de dos vas. En un socket de datagrama podra recibir
mensajes en diferente orden de la secuencia de la cual los mensajes fueron envados.
Los lmites de grabacin en los datos son preservados. Los sockets de datagrama operan
parecidos a pasar cartas hacia adelante y hacia atrs en el correo. El tipo de socket es
SOCK_DGRAM, el cual en el dominio de internet usa UDP (User Datagram Protocol).