Integrantes: Erick Jimnez Carrasco. Romn Jimnez Maldonado. Geovanny Lpez Guerra. Jos Adrin Lerdo Cruz.

Comunicacin en los sistemas operativos distribuidos

La diferencia ms importante entre un sistema

distribuido y un sistema de un nico procesador es la comunicacin entre procesos. En un sistema de un solo procesador la comunicacin supone implcitamente la existencia de la memoria compartida:

 Los procesos, para comunicarse, deben apegarse a

reglas conocidas como protocolos. Para los sistemas distribuidos en un rea amplia, estos protocolos toman frecuentemente la forma de varias capas y cada capa tiene sus propias metas y reglas. Los mensajes se intercambian de diversas formas, existiendo muchas opciones de diseo al respecto; una importante opcin es la llamada a un procedimiento remoto. Tambin es importante considerar las posibilidades de comunicacin entre grupos de procesos, no solo entre dos procesos

COMUNICACIN CLIENTE SERVIDOR SOCKETS

El modelo cliente - servidor tiene como idea fundamental la

estructuracin del S. O. como: Un grupo de procesos en cooperacin, llamados servidores, que ofrecen servicios a los usuarios. Un grupo de procesos usuarios llamados clientes. El modelo cliente - servidor se basa en un protocolo solicitud / respuesta: Es sencillo y sin conexin. No es complejo y orientado a la conexin como OSI o TCP / IP. El cliente enva un mensaje de solicitud al servidor pidiendo cierto servicio.

 El servidor: Ejecuta el requerimiento. Regresa los datos solicitados o un cdigo de error si no pudo ejecutarlo correctamente. No se tiene que establecer una conexin sino hasta que sta se utilice. La pila del protocolo es ms corta y por lo tanto ms eficiente. Si todas las mquinas fuesen idnticas solo se necesitaran tres niveles de protocolos

 Direccionamiento en C - S Para que un cliente pueda enviar un mensaje a un

servidor, debe conocer la direccin de ste. Un esquema de direccionamiento se basa en la direccin de la mquina destinataria del mensaje: Es limitativo si en la mquina destinataria se ejecutan varios procesos, pues no se sabra para cul de ellos es el mensaje. Otro esquema de direccionamiento se basa en identificar los procesos destinatarios en vez de a las mquinas: Elimina la ambigedad acerca de quin es el receptor. Presenta el problema de cmo identificar los procesos:

 Una solucin es una nomenclatura que incluya la

identificacin de la mquina y del proceso: No se necesitan coordenadas globales. Pueden repetirse los nombres de los procesos en distintas mquinas. Una variante utiliza machine.local-id en vez de machine.process: local-id generalmente es un entero aleatorio de 16 o 32 bits. Un proceso servidor se inicia mediante una llamada al sistema para indicarle al ncleo que desea escuchar a local-id. Cuando se enva un mensaje dirigido a machine.localid el ncleo sabe a cul proceso debe dar el mensaje.

Cdigo fuente del servidor

import java.net.*; import java.io.*; /** * * @author Jorge V */ public class Conex { final int PUERTO=5000; ServerSocket sc; Socket so; DataOutputStream salida; String mensajeRecibido; //SERVIDOR public void initServer() { BufferedReader entrada; try { sc = new ServerSocket(PUERTO ); /* crea socket servidor que escuchara en puerto 5000*/ so=new Socket(); System.out.println("Esperando una conexin:"); so = sc.accept(); //Inicia el socket, ahora esta esperando una conexin por parte del cliente System.out.println("Un cliente se ha conectado."); //Canales de entrada y salida de datos entrada = new BufferedReader(new

 InputStreamReader(so.getInputStream())); salida = new DataOutputStream(so.getOutputStream());

System.out.println("Confirmando conexion al cliente...."); salida.writeUTF("Conexin exitosa...n envia un mensaje "); //Recepcion de mensaje mensajeRecibido = entrada.readLine(); System.out.println(mensajeRecibido); salida.writeUTF("Se recibio tu mensaje.n Terminando conexion..."); salida.writeUTF("Gracias por conectarte, adios!"); System.out.println("Cerrando conexin..."); sc.close(); //Aqui se cierra la conexin con el cliente }catch(Exception e ) { System.out.println("Error: "+e.getMessage()); } } }

Cdigo fuente cliente simple

import java.net.*; import java.io.*; /** * * @author Jorge V */ public class Conex { final String HOST = "localhost"; final int PUERTO=5000; Socket sc; DataOutputStream mensaje; DataInputStream entrada; //Cliente public void initClient() /*ejecuta este metodo para correr el cliente */ {

 try { sc = new Socket( HOST , PUERTO ); /*conectar a un servidor en localhost con puerto

5000*/ //creamos el flujo de datos por el que se enviara un mensaje mensaje = new DataOutputStream(sc.getOutputStream()); //enviamos el mensaje mensaje.writeUTF("hola que tal!!"); //cerramos la conexin sc.close(); } catch(Exception e ) { System.out.println("Error: "+e.getMessage()); } } }

COMUNICACION CON RPC

RCP (REMOTE PROCEDURE CALL) El mecanismo general para las aplicaciones cliente-

servidor se proporciona por el paquete Remote Procedure Call (RPC). RPC fue desarrollado por Sun Microsystems y es una coleccin de herramientas y funciones de biblioteca. Aplicaciones importantes construidas sobre RPC son NIS, Sistema de Informacin de Red y NFS, Sistema de Ficheros de Red. Es un protocolo que permite a un programa de ordenador ejecutar cdigo en otra mquina remota sin tener que preocuparse por las comunicaciones entre ambos.

 1. -El sub cliente rene luego los parmetros y los

empaqueta en un mensaje. Esta operacin se conoce como reunin de argumentos 2.- En un sistema LAN con un servicio sin conexiones, la entidad de transporte probablemente slo le agrega al mensaje un encabezamiento y lo coloca en la subred sin mayor trabajo 3.-En una WAN, la transmisin real puede ser ms complicada. Cuando el mensaje llega al servidor, la entidad de transporte lo pasa al stub del servidor

 4.- que desempaqueta los parmetros. El sub servidor

llama luego al procedimiento servidor 5.- pasndole los parmetros de manera estndar. El procedimiento servidor no tiene forma de saber que est siendo activado remotamente, debido a que se lo llama desde un procedimiento local que cumple con todas las reglas estndares. nicamente el sub sabe que est ocurriendo algo particular. Despus que ha completado su trabajo, el procedimiento servidor retorna 6.- de la misma forma en que retornan otros procedimientos cuando terminan y, desde luego, puede retornar un resultado a un llamador. El sub servidor empaqueta luego el resultado en un mensaje y lo entrega a la interfaz con transporte

 7.- posiblemente mediante una llamada al sistema, al igual que

en el paso 2. Despus que la respuesta retorna a la mquina cliente 8.- la misma se entrega al sub cliente 9.- que desempaqueta las respuestas. Finalmente, el sub cliente retorna a su llamador, el procedimiento cliente y cualquier valor devuelto por el servidor en el paso 6, se entrega al cliente en el paso 10. El propsito de todo el mecanismo es darle al cliente (procedimiento cliente) la ilusin de que est haciendo una llamada a un procedimiento local. Dado el xito de la ilusin, ya que el cliente no puede saber que el servidor es remoto, se dice que el mecanismo es transparente. Sin embargo, una inspeccin ms de cerca revela algunas dificultades en alcanzar la total transparencia.

COMUNICACIN EN GRUPO
BROADCAST O DIFUSION FORZADA: Transmisin de

un paquete que ser recibido por todos los dispositivos en una red. MULTICAST: Consiste en la entrega de paquetes a travs de una red a varios destinos de forma simultnea evitando al mximo el duplicar los paquetes, esto es, se duplican paquetes exclusivamente cuando se bifurca el camino a los diferentes destinos finales. UNICAST o POINTCAST: Un nodo emite y otro recibe, solo escucha aquel a quien se dirigi el msj Una clasificacin adicional es la realizada en base a grupos

Tolerancia a Fallos
La tolerancia a fallas es considerada la principal

caracterstica que debe de tener un sistema distribuido para alcanzar el principio de transparencia. Para lograr la tolerancia a fallos se necesita de una buena comunicacin entre procesos distribuidos y sobretodo de una correcta coordinacin entre procesos Un Sistema Distribuido en base a la coordinacin de sus procesos puede ser: Asncrono: no hay coordinacin en el tiempo. Sncrono: se suponen lmites mximos para el retraso de mensajes. El primer factor a tomar en cuenta es que el canal de comunicacin este libre de errores (canal confiable).

 Algunos fallos en el funcionamiento de un sistema

pueden originarse por: Especificaciones impropias o con errores. Diseo deficiente de la creacin del software o el hardware. Deterioros o averas en al hardware.

Prevencin y Tolerancia a Fallos Existen dos formas de aumentar la fiabilidad de un sistema. 1. Prevencin de fallos: Se trata de evitar que se

implementen sistemas que pueden introducir fallos. 2. Tolerancia a fallos: Se trata de conseguir que el sistema continu funcionando correctamente aunque se presenten algunos fallos.