Vous êtes sur la page 1sur 16

CARACTERSTICAS DE LA COMUNICACIN ENTRE LOS PROCESOS EN

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

insertndolos y extrayndolos de la conexin. Una vez que la conexin se


ha establecido no es necesario identificar a emisor y receptor.
o En el caso de mecanismos no orientados a la conexin, los datos se
intercambian por medio de paquetes independientes, cada uno de los
cuales necesita identificar al receptor.
Las funcionalidades de tipo IPC pueden clasificarse de acuerdo a sus niveles de
abstraccin, yendo desde transferencia de datos serie/paralelo, al nivel ms bajo,
pasando por el API de sockets al siguiente nivel, hasta llamadas a procedimientos
o mtodos remotos, al nivel ms alto.
MANEJO DE SOCKETS PARA LA COMUNICACIN
LOS SOCKETS.
Los sockets no son ms que puntos o mecanismos de comunicacin entre procesos
que permiten que un proceso hable ( emita o reciba informacin ) con otro proceso incluso
estando estos procesos en distintas mquinas. Esta caracterstica de interconectividad
entre mquinas hace que el concepto de socket nos sirva de gran utilidad. Esta interfaz de
comunicaciones es una de las distribuciones de Berkeley al sistema UNIX,
implementndose las utilidades de interconectividad de este Sistema Operativo ( rlogin,
telnet, ftp, ... ) usando sockets.
Un socket es al sistema de comunicacin entre ordenadores lo que un buzn o un
telfono es al sistema de comunicacin entre personas: un punto de comunicacin entre
dos agentes ( procesos o personas respectivamente ) por el cual se puede emitir o recibir
informacin. La forma de referenciar un socket por los procesos implicados es mediante
un descriptor del mismo tipo que el utilizado para referenciar ficheros. Debido a esta
caracterstica, se podr realizar redirecciones de los archivos de E/S estndar
(descriptores 0,1 y 2) a los sockets y as combinar entre ellos aplicaciones de la red. Todo
nuevo proceso creado heredar, por tanto, los descriptores de sockets de su padre.
La comunicacin entre procesos a travs de sockets se basa en la filosofa CLIENTESERVIDOR: un proceso en esta comunicacin actuar de proceso servidor creando un
socket cuyo nombre conocer el proceso cliente, el cual podr "hablar" con el proceso
servidor a travs de la conexin con dicho socket nombrado.
El proceso crea un socket sin nombre cuyo valor de vuelta es un descriptor sobre el
que se leer o escribir, permitindose una comunicacin bidireccional, caracterstica
propia de los sockets y que los diferencia de los pipes, o canales de comunicacin
unidireccional entre procesos de una misma mquina. El mecanismo de comunicacin va
sockets tiene los siguientes pasos:
1) El proceso servidor crea un socket con nombre y espera la
conexin.
2) El proceso cliente crea un socket sin nombre.
3) El proceso cliente realiza una peticin de conexin al socket
servidor.
4) El cliente realiza la conexin a travs de su socket mientras el
proceso servidor mantiene el socket servidor original con
nombre.

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 )

permite el acceso a protocolos de ms bajo nivel como el IP

* Tipo SOCK_SEQPACKET: tiene las caractersticas del


adems el tamao de los mensajes es fijo.

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

no asegura el orden de preservacion, perdida y duplicacion de mensajes


etapas necesarias:
crear un socket
une el socket a un puerto y a una direccion local de internet

cliente: puerto libre arbitrario


servidor: puerto del servidor
metodo de recepcion: retorna la direccion de internet y el puerto del emisor, ademas del
mensaje

Tamao de mensajes: Todas las IP pueden enviar mensajes de 2, 16 bytes (algunos se


restringen a 8KB
Comunicacin con 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

JAVA API PARA DATAGRAMA UDP

DatagramPacket : Constructor de generacion de mensajes para ser enviado en un


arreglo de bytes
contenido del mensaje(byte array) getData()
longitud del mensaje getPort()
direccion de internet y numero de puerto (destino) getAdress()

DatagramSocket: clase para el envio y recepcion de datagramas UDP


un constructor con el numero de puerto como argumento
constructor sin argumentos para utilizar el puerto local libre mtodos

send y receive

send(DatagramPacket dP) throws IOException


receive(DatagramPacket dP)
throws IOException
SetSoTimeout
setSoTimeout ( ) throws InterruptedIOException
connect: para conectar un socket a una direccion de internet
remota y el puerto
connect ( ) para conectarse a una sola direccin

IPC BASADO EN STREAM TCP

Crea un canal virtual de comunicacion sobre streams


Oculta las siguientes caracteristicas:
o Tamao de los mensajes: se parte el mensaje y se reconstruye en destino
Mensajes perdidos
Control de flujo: ajusta velocidades bloqueando el emisor si el receptor no
recupera los mensajes
Duplicacion y ordenacion
Destinos de los mensajes, una vez realizada la conexion.

Aspectos importantes
o Concordancia de tipos de datos
o Los procesos deben conocer el tipo de datos que se envian reciben
Bloque

El receptor se bloquea siempre, y el emisor solo cuando el canal no


puede admitir mas mensajes

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 ( )

SERIALIZACION DE UN OBJETO EN JAVA Y REFERENCIA A OBJETOS REMOTOS


La serializacin de un objeto consiste en obtener una secuencia de bytes que represente
el estado de dicho objeto. Esta secuencia puede utilizarse de varias maneras (puede
enviarse a travs de la red, guardarse en un fichero para su uso posterior, utilizarse para
recomponer el objeto original, etc.). Estado de un objeto El estado de un objeto viene
dado, bsicamente, por el estado de sus campos. As, serializar un objeto consiste,
bsicamente, en guardar el estado de sus campos. Si el objeto a serializar tiene campos
que a su vez son objetos, habr que serializarlos primero. ste es un proceso recursivo
que implica la serializacin de todo un grafo (en realidad, un rbol) de objetos. Adems,
tambin se almacena informacin relativa a dicho rbol, para poder llevar a cabo la
reconstruccin del objeto serializado. En ocasiones puede interesar que un atributo
concreto de un objeto no sea serializado. Esto se puede conseguir utilizando el
modificador transient, que informa a la JVM de que no nos interesa mantener el valor de
ese atributo para serializarlo o hacerlo persistente.
Ejemplo:
public class MiFecha {
protected int n;
protected Date fecha;
protected transient long s; . . .
}
En este ejemplo, los atributos n y fecha sern includos en la secuencia de bytes
resultante de serializar un objeto de clase MiFecha. El atributo s no ser includo, por
tener el modificador transient. Objetos serializables. Interfaz Serializable Un objeto
serializable es un objeto que se puede convertir en una secuencia de bytes. Para que un
objeto sea serializable, debe implementar la interfaz java.io.Serializable. Esta interfaz no

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

Serialization for Your Classes). Para 'personalizar' la serializacin de un objeto, basta


aadir un mtodo tal que:
private void writeObject (ObjectOutputStream stream)
throws IOException { stream.defaultWriteObject(); . . .
}
Es necesario respetar exactamente tanto la signatura del mtodo como la primera accin
a realizar. A continuacin pueden aadirse otras acciones que escriban en el stream dado.
Tambin ser necesario aadir un mtodo para hacer el paso inverso:
private void readObject (ObjectInputStream stream)
throws IOException
{
stream.defaultReadObject(); . . .
}

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

remoteObjectName, entonces el objeto que est siendo nombrado es el propio registro


RMI. Puedes ver la Especificacin RMI para ms detalles.
RMI puede soportarse usando el "Java Remote Method Protocol" (JRMP) y el "Internet
Inter-ORB Protocol" (IIOP). El JRMP es un protocolo especializado diseado para RMI; el
IIOP es el protocolo estndar de comunicacin entre objetos CORBA. RMI sobre IIOP
permite a los objetos remotos Java comunicarse con objetos CORBA que podran estar
escritos en lenguajes de programacin distintos de Java.
Algunos proveedores de servicios, como el LDAP de Sun, soportan uniones de objetos
java.rmi.Remote en el directorio. Cuando los objetos java.rmi.Remote y/o las entradas
de registro RMI se unen en un espacio de nombres enterprise como el LDAP, los clientes
RMI pueden buscar objetos java.rmi.Remote sin conocer en qu mquina se est
ejecutando el objeto.
Unir un Objeto Remoto
Antes de Continuar:
Para ejecutar este ejemplo, necesitamos la Java 2 Platform, v1.2 o una versin superior.
Tambin necesitaremos ldapbp.jar.

El siguiente ejemplo define un interface java.rmi.Remote: Hello que tiene un mtodo,


sayHello().
public interface Hello extends Remote {
public String sayHello() throws RemoteException;
}
Tambin define una implementacin para este interface, HelloImpl.
public class HelloImpl extends UnicastRemoteObject implements Hello {
public HelloImpl() throws RemoteException {
}
public String sayHello() throws RemoteException {
return ("Hello, the time is " + new java.util.Date());
}
}
Este ejemplo tambin crea un ejemplar de HelloImpl y lo une al directorio, asignndole el
nombre "cn=RemoteHello".
// Create the remote object to be bound, and give it a name
Hello h = new HelloImpl();
// Bind the object to the directory
ctx.bind("cn=RemoteHello", h);

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";

// Create the reference containing the (future) location of the object


Reference ref = new Reference("Hello", new StringRefAddr("URL", rmiurl));
// Bind the object to the directory
ctx.bind("cn=RefHello", ref);
Luego crea un ejemplar de HelloImpl y lo une al registro RMI local usando la misma URL
RMI ("rmi://mymachine/hello").
// Create the remote object to be bound
Hello h = new HelloImpl();
// Bind the object to the RMI registry
ctx.rebind(rmiurl, h);
Despus de que el objeto se haya unido en el directorio y en el registro RMI, una
aplicacin puede buscar el objeto usando el siguiente cdigo.
Hello h2 = (Hello)ctx.lookup("cn=RefHello");
System.out.println(h2.sayHello());
En efecto, este mtodo tiene ms de un nivel de indireccin que los que ofrecan los
ejemplos anteriores. La informacin almacenada en el directorio (la Reference) es
realmente un puntero a informacin almacenada en otro servicio de nombres (el registro
RMI), que a su vez, contiene la referencia al objeto java.rmi.Remote.
Para ejecutar este ejemplo, debemos hacer lo siguiente.
1. Realizar los pasos 1-3 del
2. Compilar este ejemplo.
3. # javac RemoteRef.java
4. Especificar el directorio codebase como el codebase para el intrprete Java.
5. # java -Djava.rmi.server.codebase=http://web1/example/classes/ RemoteRef
RemoteRef no termina, porque crea el objeto remoto HelloImpl con el que pueden
contactar otros clientes RMI.
Cuando posteriormente busquemos este objeto en el directorio, ste devolver el objeto
remoto HelloImpl unido. El RMI descargar automticamente los ficheros class
necesarios desde el codebase especificado en la propiedad "java.rmi.server.codebase".

COMUNICACIN CLIENTE / SERVIDOR

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).

Socket de paquete secuencial


Da una conexin de dos vas, secuencial y confiable para datagramas de una longitud fija
mxima. El tipo de socket es SOCK_SEQPACKET. No hay protocolo en Internet
implementado para este tipo de socket.
Implementando un socket en java
En un programa Cliente-Servidor un socket nos ayuda a representar las conexiones entre
un programa cliente y uno servidor. En el lado del cliente se utiliza la clase Socket y en el
del servidor el Server Socket para representar dichas conexiones.

Vous aimerez peut-être aussi