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: Primitivas de operacin: enviar, recibir, conectarse, y desconectarse. 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. 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: 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. 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 CLIENTE-SERVIDOR: 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:permite el acceso a protocolos de ms bajo nivel como el IP ( nivel de red )

* Tipo SOCK_SEQPACKET: tiene las caractersticas del SOCK_STREAM pero adems el tamao de los mensajes es fijo.

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; /* familia */ char sa__data[14]; /* 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 { shortsun__family; /* en este caso AF_UNIX */ charsun__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__longs__addr; };

struct sockaddr__in { shortsin_family; /* en este caso AF_INET */ u__shortsin_port; /* numero del puerto */ struct in__addrsin__addr; /* direcc Internet */ charsin_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 mensajesetapas necesarias:crear un socketune el socket a un puerto y a una direccion local de internet

cliente: puerto libre arbitrarioservidor: 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 receivesend(DatagramPacket dP) throws IOException receive(DatagramPacket dP) throws IOException SetSoTimeoutsetSoTimeout ( ) throws InterruptedIOException connect: para conectar un socket a una direccion de internetremota y el puertoconnect ( ) para conectarse a una sola direccin

IPC BASADO EN STREAM TCP

Crea un canal virtual de comunicacion sobre streams Oculta las siguientes caracteristicas: 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 Concordancia de tipos de datos 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 TCP usa: numeros de secuencia, checksums y timeouts. Cuando el numero de errores es excesivo o se sobrepasa el tiempo limite se declara rota la conexion. no se distingue un fallo en el proceso del fallo en la conexion. 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 constructor para crear un socket y conectarse a un host ypuerto remoto de un servidorSocket accept ( )Socket throws UnknownHostExceptionthrows IOException metodo para acceder a ujo de entrada y salidaInputStream 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 REMOTOSEl 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 RemotoAntes 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 nameHello h = new HelloImpl();

// Bind the object to the directoryctx.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.java3. Ejecutar rmic con HelloImpl como argumento para producir los stubs (esqueletos) del objeto remoto. 4. # rmic HelloImpl5. 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/ RemoteObjRemoteObj 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 ReferenciaAntes 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 objectReference ref = new Reference("Hello", new StringRefAddr("URL", rmiurl));

// Bind the object to the directoryctx.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 boundHello h = new HelloImpl();

// Bind the object to the RMI registryctx.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 del2. Compilar este ejemplo. 3. # javac RemoteRef.java4. Especificar el directorio codebase como el codebase para el intrprete Java. 5. # java -Djava.rmi.server.codebase=http://web1/example/classes/ RemoteRefRemoteRef 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 / SERVIDOROrigen 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.