Copyright2005 UNIVERSIDAD PERUANA LOS ANDES Programa de Educacin a Distancia.

Huancayo Per Prohibida la reproduccin total o parcial sin autorizacin por escrito del Rector de la Universidad. La redaccin de este texto estuvo a cargo de Ing. Carlos Alcides Almidn Ortiz.

Presentacin
La evolucin de las tecnologas de la informacin y comunicacin en el mundo nos permite implementar diferentes aplicaciones en la red, debido esto la generalizacin del termino cloud computing (servicios en el internet), la popular nube, como paradigma de todo tipo, tanto organizativo como de diseo de sistemas, conlleva a una interesante reflexin. Si la nube permite a los clientes y usuarios poder obtener funcionalidades a travs de servicios, de los cuales solo conocen su contrato de servicio pero ignoran el diseo y la localizacin. Muchas veces olvidamos que los servicios han de ser fabricados y que para ese trabajo hay que prepararse, entonces aqu ingresa el diseo de los sistemas distribuidos. Un sistema distribuido es un sistema de informacin en el cual las funciones se reparten por reas de trabajo diferentes que trabajan de forma coordinada para asumir los objetivos que la organizacin asigna a ese sistema de informacin. En este manual se trata de dar un alcance al estudiante de cmo disear sistemas distribuidos, que consiste en crear aplicaciones de software que, utilizando servicios y ayudndose de la conectividad, participen y se integren en este entorno de forma transparente a las plataformas de proceso y de almacenamiento de datos, dotndolas de los recursos necesarios para gestionarse de forma integrada con el resto del sistema distribuido. Los sistemas distribuidos que se diseen y construyan deben estar alineados con los objetivos de negocio de la empresa, aumentar la eficacia y eficiencia operacional de la compaa y permitir el mayor rendimiento con el menor costo en las estructuras informticas que dan soporte.

El autor

Programacin general
Conceptos de los Sistemas Distribuidos Autoaprendizaje 3 horas Unidad 1 Modelos de Sistemas Distribuidos Autoaprendizaje 3 horas Unidad 2 Comunicacin a Nivel de Redes. Autoaprendizaje, 3 horas Unidad 3 Comunicacin de procesos en los Sistemas Distribuidos. Autoaprendizaje, 3 horas Unidad 4 Comunicacin a bajo nivel, Sockets. Autoaprendizaje 3 horas Unidad 5 Objetos Distribuidos e Invocacion Remota Autoaprendizaje, 3 horas Unidad 6 Sistemas de Archivos Distribuidos Autoaprendizaje, 4 horas Unidad 7 Seguridad en Sistemas Distribuidos Autoaprendizaje, 3 horas Unidad 8

Tabla de contenido
Presentacin Programa general Conceptos de Sistemas Distribuidos Qu es un Sistema Distribuido?

Pgina

1 2

UNIDAD ACADMICA N 01

Sistemas Distribuidos
Un sistemas Distribuido es aquel en el que los componentes hardware o software, localizados en computadores unidos mediante red, comunican y coordinan mensajes. sus acciones slo mediante paso de

Figura 1. Representacin de un Sistema Distribuido

INDICADORES DE LOGRO Al terminar esta unidad el estudiante estar en condiciones de:

Definir y describir que es un Sistemas Distribuidos. Describir las caracteristicas de un Sistema Distribuidos. Describir los desafos de los Sistemas Distribuidos. Realizar ejemplos de Sistemas Distribuidos.

1. CARACTERISTICAS DE LOS SISTEMAS DISTRIBUIDOS Existen redes de computadoras en cualquier parte. Una de ellas es Internet, como los son las muchas redes de las que se compone. Las redes de telfonos mviles, las redes corporativas, las de las empresas, los campus, las casas, redes dentro del coche, todas, tanto separados, como combinadas, comparten las caractersticas esenciales que las hacen elementos importantes para su estudio bajo el ttulo de Sistemas Distribuidos.

Los

computadores

que

estn por

conectados mediante una red pueden estar separados especialmente cualquier distancia. Pueden estar en continentes distintos, en el mismo edificio o en la misma habitacin. Nuestra Distribuido

definicin tiene

de las

Sistema siguientes
Figura 2. Internet

consecuencias significativas:

Concurrencia.- En una red de computadores, la ejecucin de programas concurrentes es la norma. Usted puede estar realizando un trabajo en su computador, mientras otra persona tambin y a la vez ambos comparten recursos como pginas web o ficheros, cuando es necesario. La capacidad del sistema para manejar recursos compartidos se puede incrementar aadiendo ms recursos (por ejemplo computadoras) a la red. Ventajas: Trabajo Cooperativo. Inconvenientes: Programacin Compleja.

Inexistencia necesitan

de

Reloj

Global.sus

Cuando

los

programas el

cooperar

coordinan

acciones

mediante

intercambio de mensajes. La coordinacin estrecha depende a menudo de una idea compartida del instante en el que ocurren las acciones de los programas pero resulta que hay lmites a la precisin con lo que los computadores en una red pueden sincronizar sus relojes, no hay una nica nocin global del se realiza enviando mensajes a tiempo correcto. Esto es una consecuencia directa del hecho que la nica comunicacin travs de la red.

Fallos Independientes.- Todos los sistemas informticos pueden fallar y los diseadores de sistemas tienen la responsabilidad de planificar las consecuencias de posibles fallos. Los sistemas distribuidos pueden fallar de nuevas formas. Los fallos en la red producen el aislamiento de los

computadores conectados a l, pero eso no significa que detengan su ejecucin. De hecho, los programas que se ejecutan en ellos pueden no ser capaces de detectar cuando la red ha fallado o est excesivamente lenta. De forma similar, la parada de un computador o la terminacin inesperada de un programa en alguna parte del sistema no se da a conocer inmediatamente a los dems componentes con los que se comunica.

Razones de Su Origen.Compartir Recursos: Procesos Archivos Servicios

Figura 3. Red LAN, WAN

Ejemplos de Sistemas Distribuidos Planteamos ejemplos basados en redes de computadoras conocidas y utilizadas ampliamente Internet, Intranets y la tecnologa emergente basada en dispositivos mviles. Se han elegido para proporcionar ejemplos del amplio rango de servicios y aplicaciones que son soportados por redes de computadoras y para comenzar la discusin de las cuestiones tcnicas que entraa su implementacin. Ejemplo 1: Internet: Es una vasta coleccin de redes de computadoras de diferentes tipos interconectados. Programas ejecutndose en los computadores conectados a ella interactan mediante paso de mensajes, empleando un medio comn de comunicacin. Internet, tambin es un sistema distribuido muy grande. Permite a los usuarios, donde quiera que estn, hacer uso de servicios como el

World Wide Web, el correo electrnico, y la transferencia de ficheros. En internet hay disponibles servicios multimedia, que permiten a los usuarios el acceso a datos de audio y video. La implementacin de internet y los servicios que mantiene ha implicado el desarrollo de soluciones prcticas para muchas cuestiones de sistemas distribuidos. Ejemplo 2: Intranets: Una intranet es una porcin de internet que es, administrada separadamente y que tiene un lmite que puede ser configurado para hacer cumplir polticas de seguridad local. Est compuesta de varias redes de rea local (LANs) enlazadas por conexiones backbone. Una intranet est conectada a Internet por medio de un encaminador (router), lo que permite a los usuarios hacer uso de servicios de otro sitio como web o el correo electrnico, en este escenario el papel del cortafuegos es proteger la intranet impidiendo que entren o salgan mensajes no autorizados. Un cortafuegos se implementa filtrando los mensajes que entran y salen, por ejemplo de acuerdo con su origen o destino. Un cortafuegos podra permitir, slo aquellos mensajes relacionados con el correo electrnico el acceso web entrar o salir de la intranet que protege. Ejemplo 3: Computacin Mvil y Ubicua: Los avances tecnolgicos en la miniaturizacin de dispositivos y en redes inalmbricas han llevado cada vez ms a la integracin de dispositivos de computacin pequeos y porttiles en sistemas distribuidos. Estos dispositivos incluyen: Computadoras porttiles, Dispositivos de manos como asistentes digitales personales, telfonos mviles, buscapersonas y videocmaras o cmaras digitales. Tambin dispositivos que se puedan llevar puestos como relojes inteligentes con funcionalidad semejante a los asistentes

digitales personales, y Dispositivos insertados en aparatos como lavadoras, sistemas de alta fidelidad, coches y frigorficos. Se llama computacin mvil a la realizacin de tareas de cmputo mientras el usuario est en movimiento o visitando otros lugares distintos de su entorno habitual. En la computacin mvil, los usuarios que estn fuera de su hogar intranet disponen de la posibilidad de acceder a los recursos mediante los dispositivos que llevan con ellos. Pueden continuar accediendo a internet; pueden acceder a los recursos de su intranet; y se est incrementando la posibilidad de que utilicen recursos como impresoras, que estn suficientemente prximos a donde se encuentren. Computacin ubicua es la utilizacin concertada de muchos dispositivos de computacin pequeos y baratos que estn presentes en los entornos fsicos de los usuarios, incluyendo la casa, la oficina y otros. El trmino ubicuo est pensado para sugerir que los pequeos dispositivos llegarn a estar tan extendidos en los objetos de cada da que apenas nos daremos cuenta de ellos. O sea, su comportamiento computacional estar ligado con su funcin fsica de forma nfima y transparente. Por ejemplo, podra ser conveniente para los usuarios controlar su lavadora y su equipo de alta fidelidad desde un dispositivo de control remoto universal en su casa. Del mismo modo, la lavadora podra avisar al usuario a travs de una tarjeta inteligente o reloj cuando el lavado hubiera finalizado. La computacin ubicua y mvil se solapan, puesto que un usuario movindose puede beneficiarse, en principio, de los computadores que estn en cualquier parte. Pero, en general, son distintas. La computacin ubicua podr beneficiar a los usuarios mientras permanecen en un entorno sencillo como su casa o un hospital. De forma similar, la computacin mvil tiene ventajas si slo se consideran computadores convencionales y dispositivos como computadores porttiles e impresoras.

10

Figura 4. Computacion Movil y Ubicua

11

2. RECURSOS COMPARTIDOS Y WEB. Como estamos viendo hasta ahora que los sistemas distribuidos trabajan a nivel de redes, y en este escenario normalmente compartimos recursos hardware como impresoras, recursos de datos como ficheros, y recursos con una funcionalidad ms especfica como mquinas de bsqueda. Considerado desde el punto de vista de la provisin de hardware, se comparten equipos como impresoras y discos para reducir costes. En la prctica los patrones de compartir recursos varan mucho en su enlace y cun estrechamente trabajan juntos los usuarios. Los recursos en un sistema distribuido estn encapsulados fsicamente con los computadores computadores y y solo slo pueden pueden ser ser accedidos accedidos desde desde otros otros

computadores a travs de comunicacin. Para que se compartan de forma efectiva, cada recurso debe ser gestionado por un programa que ofrece una interfaz de comunicacin permitiendo que se acceda y actualice el recurso de forma fiable y consistente. El termino servidor es probablemente familiar para la mayora de los lectores. Se refiere a un programa en ejecucin (un proceso) en un computador en red que acepta peticiones de programas que se estn ejecutando en otros computadores para realizar un servicio y responder adecuadamente. Los procesos solicitantes son llamados clientes. Las peticiones se envan a travs de mensajes desde los clientes al servidor y las contestaciones se envan mediante mensajes desde el servidor a los clientes. Cuando un cliente enva una peticin para que se realice una operacin, decimos que el cliente invoca una operacin del servidor. Se llama invocacin remota a una interaccin completa entre un cliente y un servidor, desde el instante en el que el cliente enva su peticin hasta que recibe la respuesta del servidor. El mismo proceso puede ser tanto un cliente como un servidor, puesto que los servidores a veces invocan operaciones en otros

12

servidores. Los trminos cliente y servidor se aplican a los roles desempeados en una nica solicitud. Ambos son distintos, en muchos aspectos, los clientes son activos y los servidores pasivos, los servidores se estn ejecutando continuamente, mientras que los clientes slo lo hacen el tiempo que duran las aplicaciones de las que forman parte.

Figura 5. Proceso Cliente Proceso

Hay que sealar que por defecto los trminos cliente y servidor se refieren a procesos no a los computadores en las que se ejecutan, aunque en lenguaje coloquial dichos trminos se refieren tambin a los propios computadores. 2.1 El World Wide Web Es un sistema en evolucin para publicar y acceder a recursos y servicios a travs de internet. Utilizando el software de un navegador web, fcilmente disponible como Netscape o Internet Explorer, los usuarios utilizan el Web para recuperar y ver documentos de muchas clases, para escuchar secuencias de audio y ver secuencias de vdeos, y para conjunto ilimitado de servicios. El Web es un sistema abierto, puede ser ampliado e implementado en nuevas formas sin modificar su funcionalidad existente. Primero, su operacin est basada en estndares de comunicacin y en documentos estndares que estn publicados libremente e interaccionar con un

Servidor

13

implementados en muchos casos sobre diferentes plataformas; y existen muchas implementaciones de servidores web. Segundo, el web es abierto respecto a los tipos de recursos que pueden ser publicados y compartidos en l. En su forma ms simple, un recurso es una pgina web o algn otro tipo de contenido que puede ser almacenada en un fichero y presentado al usuario, como ficheros de programa, de imgenes, de sonido y documentos en formato PostScript o PDF. El Web est basado en tres componentes tecnolgicos de carcter estndar bsicos: El lenguaje de etiquetado de hipertexto (HTML, Hypertext Markup Languaje) es un lenguaje para especificar el contenido y el diseo de las pginas que son mostradas para los navegadores. Localizadores Uniformes de Recursos (URL, Uniform Resource Locator) que identifican documentos y otros recursos almacenados como parte de la Web.

El

protocolo

de

transferencia

hipertexto

(HTTP,

hyperText Transfer Protocol) mediante la cual los navegadores y otros clientes obtienen documentos y otros recursos de los servidores web.

Figura 6. Recursos Compartidos en la web

14

3. DESAFIOS DE LOS SISTEMAS DISTRIBUIDOS

En la actualidad tenemos muchos sistemas distribuidos a nuestro servicio en la vida diaria, aqu tratamos de dar algunos criterios para disear sistemas distribuidos teniendo en cuenta sus caractersticas 3.1 Heterogeneidad Se refiere a la variedad y diferencia que podemos encontrar en los elementos que componen una red de computadores sobre la que se ejecuta un sistema distribuido. (Redes, hardware, sistemas operativos, lenguajes de programacin, etc.). A pesar de que internet consta de muchos tipos de redes diferente, sus diferencias se encuentran enmarcadas dado que todos los computadores ejemplo conectados a ste utilizan los protocolos de internet para comunicarse una con otra. Por un computador conectado a Ethernet tiene una implementacin de los protocolos de Internet sobre ethernet, as un computador en un tipo de red diferente necesitar una implementacin de los protocolos de internet para esa red. Los tipos de datos, como los enteros, pueden representarse de diferente forma en diferentes clases de hardware, por ejemplo hay dos alternativas para ordenar los bytes en el caso de los enteros. Hay que tratar con estas diferencias de representacin si se va a intercambiar mensajes entre programas que se ejecutan en diferente hardware. Aunque los sistemas operativos de todos los computadores de internet necesitan incluir una implementacin de los protocolos de internet, no todas presentan necesariamente la misma interfaz de programacin para estos protocolos. Por ejemplo, las llamadas para intercambiar mensajes en UNIX son diferentes de las llamadas en Windows 2003 server. La heterogeneidad se aplica en los siguientes elementos: Redes Hardware de computadores
15

Sistemas operativos Lenguajes de programacin Implementaciones de diferentes desarrolladores.

3.1.1. Middleware El middleware es un software de conectividad que ofrece un conjunto de servicios que hacen posible el funcionamiento de aplicaciones distribuidas sobre plataformas heterogneas. Funciona como una capa de abstraccin de software distribuida, que se sita entre las capas de aplicaciones y las capas inferiores (sistema operativo y red). El middleware nos abstrae de la complejidad y heterogeneidad de las redes de comunicaciones subyacentes, as como de los sistemas operativos y lenguajes de programacin, proporcionando una API para la fcil programacin y manejo de aplicaciones distribuidas. Dependiendo del problema a resolver y de las funciones necesarias, sern tiles diferentes tipo de servicios de middleware Es el estrato de software que provee una abstraccin de programacin, as como un enmascaramiento de la heterogeneidad subyacente de las redes, hardware, sistemas operativos y lenguajes de programacin. Ejem: Corba, Java RMI.

Figura 7. Sistemas Distribuidos como MIddleware

16

3.1.2. Heterogeneidad y cdigo mvil Cdigo Mvil: cdigo que puede enviarse desde un computador a otro y ejecutarse en este ltimo. El concepto de mquina virtual ofrece un modo de crear cdigo ejecutable sobre cualquier hardware. 3.2. Extensibilidad Es la caracterstica que determina si el sistema puede extenderse de varias maneras. Un sistema puede ser abierto o cerrado con respecto a extensiones de hardware o de software. Para lograr la extensibilidad es imprescindible que las interfaces clave sean publicadas. Los Sistemas Distribuidos Abiertos pueden extenderse a nivel de hardware mediante la inclusin de computadoras a la red y a nivel de software por la introduccin de nuevos servicios y la reimplementacin de los antiguos. Otro beneficio de los sistemas abiertos es su independencia de proveedores concretos. 3.3. Seguridad La seguridad tiene tres componentes: Confidencialidad: proteccin contra individuos no autorizados. Integridad: proteccin contra la alteracin o corrupcin. Disponibilidad: proteccin contra la interferencia que impide el acceso a los recursos. Existen dos desafos que no han sido resueltos en su totalidad: Ataques de denegacin de servicio. Seguridad del cdigo mvil. 3.4. Escalabilidad Se dice que un sistema es escalable si conserva su efectividad cuando ocurre un incremento significativo en el nmero de recursos y en el nmero de usuarios. El diseo de SD escalables presenta los siguientes retos:

17

Control de costo de los recursos fsicos: para que un sistema con n usuarios sea escalable, la cantidad de recursos fsicos necesarios para soportarlo debera ser O(n). Controlar la degradacin del rendimiento: Ejm: Los algoritmos que emplean estructuras jerrquicas se comportan mejor frente al crecimiento de la escala, que los algoritmos que emplean estructuras lineales. Evitar cuellos de botella: los algoritmos deberan ser descentralizados. Prevenir el desbordamiento de los recursos de software. 3. 5. Tratamiento de Fallos.
Deteccin

de fallos: pueden utilizar sumas de comprobacin

Ejem.

Se

(checksums) para detectar datos corruptos en un mensaje.

Enmarascamiento

de fallos:

Ejem. Los mensajes pueden retransmitirse, Replicar los datos. Tolerancia de fallos: Los programas clientes de los servicios pueden disearse para tolerar ciertos fallos. Esto implica que los usuarios tendrn tambin que tolerarlos. Recuperacin de fallos: Implica el diseo de software en el que, tras una cada del servidor, el estado de los datos puede reponerse o retractarse (rollback) a unasituacin anterior. Redundancia: Emplear componentes redundantes. 3.6. Concurrencia Existe la posibilidad de acceso concurrente a un mismo recurso. La concurrencia en los servidores se puede lograr a travs de threads.

18

Cada objeto que represente un recurso compartido debe responsabilizarse de garantizar que opera correctamente en un entorno concurrente. Para que un objeto sea seguro en un entorno concurrente, sus operaciones deben sincronizarse de forma que sus datos permanezcan consistentes. 3.7. Transparencia Transparencia de acceso: permite acceder a los recursos locales y remotos empleando operaciones idnticas. Transparencia de ubicacin: permite acceder a los recursos sin conocer su localizacin. Transparencia de concurrencia: permite que varios procesos operen concurrentemente sobre recursos compartidos sin interferencia mutua. Transparencia de replicacin: permite replicar los recursos sin que los usuarios y los programadores necesiten su conocimiento. Transparencia frente a fallos: permite ocultar fallos. Transparencia de movilidad: permite la reubicacin de recursos y clientes en un sistema sin afectar la operacin de los usuarios y los programas. Transparencia de rendimiento: permite reconfigurar el sistema para mejorar el desempeo segn vare su carga. Transparencia al escalado: permite al sistema y a las aplicaciones expandirse en tamao sin cambiar la estructura del sistema o los algoritmos de aplicacin. ACTIVIDAD Tome World Wide Web como ejemplo para ilustrarel concepto de comparticin de recursos, cliente y servidor. Los recursos en el World Wide Web y otros servicios se direccionan mediante URL. o Describa el significado de las siglas URL.

19

o Proporcione ejemplos de tres tipos de recursos web a los que puede darse el nombre de URL. o Enumere los tres componentes principales de un URL, indicando como se delimitan e ilustre cada uno a partir de un ejemplo. RESUMEN Los Sistemas Distribuidos estn por todas partes, internet permite que los usuarios de todo el mundo accedan a sus servicios donde quieran que estn situados. Cada organizacin administra una intranet, que provee servcios locales y servicios de internet a los usuarios locales y habitualmente proporciona servicios a otros usuarios de internet. Es posible construir pequeos sistemas distribuidos con computadores porttiles y otros dispositivos computacionales pequeos conectados a una red inalmbrica. La comparticin de recursos y servicios de red es el principal factor que motiva la construccin de sistemas distribuidos. Recursos como impresoras, archivos, pginas web o registros de base de datos se administran mediante servidores del tipo apropiado. Las infraestructuras fsicas y lgicas de red nos permiten administrar y direccionar los paquetes en la red y los servidores nos permiten implemntar y adminsitrar los servicios en la red, como por ejemplo los servidores web administran pginas web y otros recursos web. Los recursos son accedidos por clientes, por ejemplo los clientes de los servidores web son los Browser o navegadores web. La construccin de los sistemas distribuidos presentan muchos desafos como la heterogeneidad, extensibilidad, seguridad, escalabilidad, tratamiento de fallas, concurrencia, transparencia los cuales deben ser abordados para su construccion. BIBLIOGRAFIA RECOMENDADA

20

George Colouris, Sistemas Distribuidos Conceptos y Diseo, Addison Wesley, Espaa 2001 http://www.cdk3.net/ Tanenbaum, Distributed Systems: Principles and

Paradigms, Prentice Hall, Mexico 2002. http://www.prenhall.com/divisions/esm/app/author_tanenb aum/custom/dist_sys_1/

o

Liu,

Distributed

Computing:

Principles

and

Applications, Addison Wesley, Mexico 2005 http://www.csc.calpoly.edu/~mliu/book/ AUTOEVALUACION FORMATIVA

o

Proponga cinco tipos de recursos hardware y cinco tipos de recursos de software o de datos que puedan compartirse tilmente. Proponga ejemplos de su entorno, compratido tal y como ocurre en la practica en los sistemas distribuidos. Un usuario llega a una estacin de ferrocarril que no conoce, portando un PDA capaz de conectarse a una red inalmbrica. Sugiera como podra proporcionrsele al usuario informacin sobre los servicios locales y las comodidades de la estacin, sin necesidad de insertar el nombre de la estacin o sus caracteristicas. Qu dificultades hay que superar?.

o Cuales son las ventajas y desventajas de HTML, URL, HTTP, como tecnologas de base para la consulta y visualizacin de la informacin?, Son algunas de estas tecnolgias o Cmo adecuadas como plataforma los de computo de dos cliente servidor en general? podra sincronizerse relojes Cmo computadores unidos por una red local, sin hacer uso de referencia temporal externa?, podran

21

sincronizarse

los

relojes

de

un

mayor

numero

de

computadores conectados a Internet?.

22

UNIDAD ACADMICA N 02

MODELOS DE SISTEMAS DISTRIBUIDOS

Los sistemas pensados para trabajar en entornos reales deben disearse para funcionar correctamente en el rango de circunstancias mas amplio posible y considerando todas las dificultades de amenazas (modos de utilizacin muy variable, amplio rango de entornos, problemas internos, amenazas externas). Esto conlleva a sugerir que los sistemas distribuidos de tipos diferentes comparten importantes propiedades subyacentes y dan lugar a problemas de diseo comunes, en este capitulo se presenta las propiedades y temas de diseo comunes para los sistemas distribuidos bajo la forma de de modelos descriptivos. Cada modelo est pensado para proporcionar una descripcin abstracta, simplificada pero consistente, de cada aspecto relevante del diseo de un sistema distribuido. En los modelos de Sistemas Distribuidos tenemos 2 tipos:

Los modelos Arquitectnicos Los modelos Fundamentales.

INDICADORES DE LOGRO Al terminar esta unidad el estudiante estar en condiciones de: Definir, describir los modelos de Sistemas Distribuidos.

Definir y describir los modelos arquitectnicos de Sistema Distribuidos y sus variantes. Definir y describir los Sistemas Distribuidos. modelos fundamentales de

Realizar ejemplos de Sistemas Distribuidos arquitectnicos y fundamentales.

23

2.1 MODELOS ARQUITECTNICOS La arquitectura de un sistema es su estructura en trminos de componentes especificados por separado. El objetivo global es asegurar que la estructura satisfaga las demandas presentes y previsibles sobre l. Es asi que el diseo arquitectnico de un edificio tiene aspectos similares y determina no solo su apariencia, sino tambin su estructura general y su estilo arquitectnico (gtico, neoclsico, moderno), proporcionando un marco de referencia consistente para el diseo. Un Modelo Arquitectnico de un Sistema Distribuido, trata sobre la colocacin de sus partes y las relaciones entre ellas, tambin simplifica y abstrae, inicialmente las funciones de los componentes individuales de dicho sistema y posteriormente considera 2 criterios: La ubicacin de los componentes en la red de computadores, buscando definir patrones utilizables para la distribucin de datos y carga de trabajo.

Las

interrelaciones

entre

los

componentes,

sus

papeles

funcionales y los patrones de comunicacin igual (peer to peer). 2.1.1 CAPAS DE SOFTWARE

entre ellos el

modelo cliente-servidor y el modelo de procesos de igual a

El trmino arquitectura de software se refera inicialmente a la estructuracin del software como capas en un nico computador, recientemente se refiere que las capas son uno o varios procesos, localizados en el mismo o en diferentes computadores, que ofrecen y solicitan servicios. Plataforma: Son las capas ms bajas proporcionan servicios a las en cada computador, capas que estn sobre ellas, y son implementadas independientemente

24

proporcionando una interfaz de programacin del sistema a un nivel que facilita la comunicacin y coordinacin entre procesos. Ejemplo: Windows, Linux, Solaris etc. La plataforma

Contiene los servicios propios de cada computadora concreta.

Depende del Hardware y del Sistema Operativo Aplicacin de servicios Middleware Sistema Operativo Computador y Hw. de red
Figura 1. Capas de servicio software y hardware en los sistemas distribuidos Middleware: Plataforma

Es una capa de software cuyo propsito es enmascarar la heterogeneidad aplicaciones. Aplicacin de servicios y proporcionar un modelo de programacin conveniente para los programadores de

Middleware
Sistema Operativo Computador y Hw. de red
Figura 2. Middleware

Son procesos u objetos que implementan mecanismos de comunicacin y recursos compartidos para aplicaciones distribuidas. El middleware se ocupa de proporcionar bloques tiles para la construccin de componentes de software que puedan trabajar con otros en un sistema distribuido.

25

En particular mejora el nivel de las actividades de comunicacin de los procesos de aplicacin soportando abstracciones como: llamadas a procedimientos remotos, comunicacin entre un grupo de procesos, etc. Ejem: Sun RPC (llamadas a procedimientos remotos), CORBA (middleware orientado a objeto), Java RMI (invocacin de objetos remotos en Java), DCOM (Modelo comn de objetos distribuidos de Microsoft). El middleware tambin puede proporcionar otros servicios, aparte de la comunicacin, para su uso en programas de aplicacin. Por ejemplo: gestin de nombres, seguridad, almacenamiento persistente, etc. El middleware Permite enmascarar la heterogeneidad. Puede dar un modelo y una interfaz de programacin utilizable Puede soportar abstracciones como:

Procedimientos de invocacin remota (RPC). Eventos, replicacin, servicios multimedia, etc.

Comunicacin entre grupos de procesos.

Qu forma tiene el Middleware? Bibliotecas adicionales Procedimientos de invocacin remota(RPC). Objetos Remotos (RMI, CORBA) Herramientas de Programacin. Lenguajes de definicin de Interfaces + compiladores para ellos. Servicios Bsicos de ayuda Servicio de Nombres para buscar objetos De notificacin de eventos De control de Transacciones, etc. Qu limitaciones impone?

26

Se incrementa la complejidad arquitectnica. Hay mas niveles Hay que aprender ms herramientas. Se pierde el control de bajo nivel sobre los modos de fallo.

Se depende de varias personas. 2.1.2 ARQUITECTURA DE LOS MODELOS La divisin de responsabilidades entre los componentes del sistema (aplicaciones, servidores y otros procesos) y la ubicacin de los componentes en la red es el aspecto ms importante en el diseo de un sistema distribuido. Sus implicancias fundamentales estn en las prestaciones, fiabilidad y seguridad del sistema resultante. Principales modelos arquitectnicos. Modelo cliente servidor Mltiples servidores

Procesos de igual a igual

2.1.3 MODELO CLIENTE SERVIDOR Clientes que invocan a servidores individuales. El servidor puede o no estar en la misma mquina del cliente. Tanto servidores como clientes pueden ser iterativos o concurrentes. El ms comn de modelos (DNS, Web, ftp, telnet, etc.) Un servidor puede ser cliente de otro servicio. (servidor web, Crawler )

Figura 3. Clientes que invocan a servidores individuales. 27

 Servicios proporcionados por mltiples servidores. Los servicios de pueden servidor implementarse en como distintos separados procesos computadores

interaccionando cuando es necesario, para proporcionar un servicio a los procesos clientes. Lo servidores pueden dividir el conjunto de objetos en los que est basado el servicio y distriburselo entre ellos mismos, o pueden mantener copias replicas de ellos en varias maquinas Muy usada en DNS, Web y NIS.

Cache almacena los recursos ms probablemente usados. Un cache puede responder a un esquema de Proxy. Los servidores Proxy para la Web aumentan la disponibilidad
Servidor Cliente Servidor Cliente Servidor Figura 4. Un servicio proporcionado por multiples

Servidores Proxy y Caches Cache: almacn de objetos de datos utilizados recientemente, y se encuentra ms prximo que los objetos en s. Al recibir un objeto nuevo en un computador se aade al almacn de la cache reemplazando si fuera necesario algunos objetos existentes.

servidores.

28

Los caches tipo web estar ubicados en los clientes o en un pueden servidor Proxy que se puede compartir desde varios clientes. El propsito de los servidores proxy es incrementar la disponibilidad y las prestaciones del servicio, reduciendo la carga en las redes de rea Amplia y en los servidores WEB. Servidores Proxy y Caches

Figura 5. Un servidor proxy del

Figura 6. Como funciona un

Procesos Peer-to-Peer En esta arquitectura todos los procesos desempean tareas semejantes, interactuando cooperativamente como iguales para realizar una actividad distribuida de cmputo sin distincin entre clientes y servidores. Los procesos pares mantienen la consistencia de los recursos y sincroniza las acciones a nivel de aplicacin.

proxy

Figura 7. Aplicacin distribuida basa en proceso de igual a igual

29

til al descomponer aplicaciones en tareas coordinadas. Ejemplos: Cooperacin y coordinacin, de Algoritmos trabajo descentralizados, colaborativo. 2.1.4 VARIACIONES DEL MODELO CLIENTE SERVIDOR Factores que determinan la variacin del modelo cliente servidor: El uso de cdigo mvil y agente mvil Las necesidades de los usuarios de computadores de bajo costo y con recursos de hardware limitados, que son muy sencillos de manejar El requisito de aadir o eliminar de una forma conveniente los dispositivos mviles Coordinacin agendas,

Figura 8. Interfaz de un dispositivo movil Cdigo Mvil. Es el cdigo que puede ser enviado de un

computador dado y ejecutarse en este. Ejemplo los Applets de Java Agente Mvil: es un programa que se traslada en la red, de un computador a otro, realizando una tarea para alguien. Ejem. Recolecta informacin. Computadores en red: se descarga desde un servidor remoto el sop y cualquier software de aplicacin necesario.

30

Clientes Ligeros: en el cliente slo se ejecuta una interfaz basada en ventanas, mientras que la aplicacin si se ejecuta en un servidor remoto, usualmente muy potente (multiprocesador, clusters, etc.).

Figura 9. Applet del tipo web.

Algunas Posibilidades: Segn la ubicacin del cdigo del proceso del cliente: Cdigo esttico Cdigo con movilidad (recolocacin del proceso) Segn la proporcin de tareas que recae sobre el cliente y el servidor: Clientes al estilo habitual Clientes ligeros de aplicaciones complejas Computadoras de red

Figura 10. Distribucion de carga

Red Espontanea Ventajas Facilidad de conexin a la red local

31

 Facilidad de integracin con los servicios locales Problemas Seguridad Conectividad Servicio de deteccin.

Figura 11. Intercomunicacion espontanea

Segn en diseo de la Interfaz entre procesos el un hotel

Interfaz esttico (interfaz orientado al llamado a procesamiento remoto RPC) INTERFACES Y OBJETOS

2.1.5

Una interfaz de un proceso es la especificacin del conjunto de funciones que se pueden invocar sobre l. En lenguajes orientados a objetos, los procesos distribuidos pueden ser construidos de una forma ms orientada al objeto. Las referencias a estos objetos se pasan a otros procesos para que se pueda acceder a sus mtodos de forma remota. Esta es la aproximacin adoptada por CORBA y Java RMI. 2.1.6 REQUISITOS PARA EL DISEO DE ARQUITECTURAS DISTRIBUIDAS Rendimiento Capacidad de respuesta: para obtener buenos tiempos de respuesta los sistemas deben estar compuestos por pocas capas de software y la cantidad de datos transferida debe ser pequea (ejem. Uso de proxys y caches).
32

Productividad: trabajos/unidad de tiempo. Balance de cargas: applets, varios servidores o computadores para alojar un nico servicio. Calidad de Servicio Algunas aplicaciones mantienen datos crticos en el tiempo, flujos de datos que precisan ser procesados o transferidos de un proceso a otro a una tasa prefijada. QoS es la capacidad de los sistemas para satisfacer dichos lmites. El satisfacer tales exigencias depende de la disponibilidad de los recursos en los instantes adecuados. Cada recurso crtico debe reservarse para las aplicaciones que requieren QoS. Los administradores de los recursos deben proporcionar la garanta. Las solicitudes de reserva que no se puedan cumplir se rechazan. Aspectos de Fiabilidad (que el sistema funcione correctamente) Correctitud Tolerancia de fallos Seguridad: Confidencialidad Integridad Disponibilidad.

Tolerancia a Fallos: las aplicaciones estables deben continuar funcionando correctamente en presencia de fallos de hw, sw y redes.

Se logra con redundancia Para hacer fiable un protocolo de comunicacin se

emplean otras tcnicas. Ejem. Retransmitir el mensaje. Seguridad Necesidad de ubicar datos y otros recursos sensibles slo en aquellos computadores equipados de un modo eficaz contra el ataque.
33

34

2.2 MODELOS FUNDAMENTALES Los modelos fundamentales estn implicados en una descripcin ms formal de las propiedades que son comunes en los modelos arquitectnicos. Ayudan a localizar los problemas clave para los diseadores de Sistemas Distribuidos. Su propsito es especificar los problemas, dificultades y amenazas que deben superarse para desarrollar sistemas distribuidos fiables. Principales modelos De Interaccin De Fallo De seguridad Trata sobre el rendimiento y sobre la dificultad de poner lmites temporales en un sistema distribuido. La forma en que se produce el paso de mensajes entre los procesos restringe el modo de operacin

2.2.1. Modelo de Interaccin

Figura 12. Modelo de iteraccion de un Sistema

En la comunicacin hay retrasos. El modelo estudia cmo afectan estos retrasos la coordinacin de los procesos. Entonces encontramos problemas de 2 tipos
a.

Distribuido

El Rendimiento de los canales de comunicaciones: Latencia: retardo entre el envo de un mensaje por un proceso y su recepcin por otro.

35

Ancho de banda: cantidad total de informacin que se puede transmitir en un momento dado Jitter o fluctuacin: variacin en el tiempo invertido en completar el reparto de una serie de mensajes.

b.

Problemas presentados en la nocin de Tiempo: Derivas Diferentes (diferencia de horaria) Tasas de deriva Diferentes (Ritmo de deriva) Sistemas distribuidos sncronos El tiempo de ejecucin de cada etapa de un Cada mensaje se recibe en un tiempo limitado Cada proceso tiene un reloj local cuya tasa de proceso tiene lmites superior e inferior conocidos. conocido. deriva sobre el tiempo real tiene un lmite conocido. Es posible sugerir valores para esos lmites pero es difcil obtener valores realistas y dar garantas sobre los valores elegidos. Se pueden tener timeouts. Cuando expiran Hay que garantizar ciclos suficientes de significa que ha fallado el proceso. procesador, capacidad de red y proveer relojes con tasa de deriva limitadas. Sistemas distribuidos asncronos. Son aquellos donde no existen limitaciones sobre: La velocidad de procesamiento Los retardos de transmisin de mensajes Las tasas de deriva del reloj.

2.1.1.1 Variantes del Modelo de Interaccin

Los sistemas reales son frecuentemente asncronos. Pero existen problemas que no pueden resolverse con este modelo.

36

Ordenamiento de Eventos An cuando no hay relojes precisos la ejecucin de un sistema se puede describir en trminos de los eventos y su ordenacin. Ejemplo: 1. X enva un mensaje de reunin 2. Y y Z responden 3. X enva 4. Y lee y responde 5. Z lee X, y Y enva otra respuesta. Ordenamiento de Eventos

Figura 13. Ordenamiento de eventos

Si estuvieran sincronizados seria as

Figura 14. Tabla de entrada de mensajes 37

38

2.2.2 Modelo de Fallos Intenta dar una especificacin precisa de los fallos que se pueden producir en procesos y en canales de comunicacin. Fallos por omisin De procesos De comunicaciones.

Fallos de procesos Ruptura accidentada del procesamiento. Es deseable si el resto de los procesos que interactan con el proceso interrumpido, o bien funcionan correctamente o se detienen. El mtodo de deteccin de ruptura descansa en timeouts. Fail- Stop: es cuando el resto de los procesos puede detectar con certeza que cierto proceso interrumpi su ejecucin. Se puede detectar en un sistema sncrono por los timeouts. Fallos por omisin de comunicaciones. Fallos por omisin de envos. Prdida de mensajes entre los buffers. Fallos por omisin de recepcin.
Proceso p Proceso q Recibe Canal de Comunicaci Fallos por Omisi del canal

Fallos por omisi de envio.

Envia m

Fallos por omisi de recepci.

Buffer de Buffer de Mensajes entrantes. Mensajes Salientes. Figura 15. Fallos por omision de

Enmascaramiento de fallos Ocultar el fallo. Convertirlo en un tipo razonable Fiabilidad integridad. y comunicacin uno a uno. El trmino comunicacin fiable se define en trminos de validez e

canal

39

 Validez: cualquier mensaje en el buffer de salida llega eventualmente al buffer de mensajes entrantes.

Integridad: el mensaje recibido es idntico al enviado y no se reparten mensajes por duplicado.

Amenazas de Integridad Protocolos que retransmiten pero no usan nmeros de secuencia para evitar que el mismo mensaje llegue duplicado. Usuarios mal intencionados que insertan mensajes invlidos, repiten mensajes antiguos o modifican mensajes autnticos. 2.2.3. Modelo de seguridad La seguridad de un SD puede lograrse asegurando los procesos y los canales empleados para sus interacciones y protegiendo los objetos que se encapsulan contra el acceso no autorizado.

Figura 16. Modelo de Seguridad de sistemas

Proteccin de Objetos Los objetos pueden contener datos privados y pblicos o compartidos. Se otorgan derechos de acceso que especifican a quien se permite realizar ciertas operaciones sobre un objeto. Los usuarios son los principales beneficiarios de estos derechos de acceso.

distribuidos

40

 A cada invocacin y a cada resultado se le asocia la autoridad con que se ordena. Tal autoridad se denomina principal.

El servidor es responsable de verificar la identidad del principal tras la invocacin y comprobar que dispone de los diferentes derechos para realizar operaciones sobre el objeto.

El cliente puede comprobar la identidad del principal tras el servidor para asegurar que el resultado proviene del servidor requerido.
Derechos de acceso Client e Invocaci Resultado Principal (cliente) Red
Servidor

Objeto

Figura 17. Objetos y principales

Principal (servidor)

Asegurar procesos y sus interacciones Cierto tipo de aplicaciones son ms propensas a los ataques.

Para este tipo de aplicaciones probablemente habr ataques a los procesos de los que se componen tales aplicaciones y a los mensajes que viajan entre los procesos.

Cmo

podemos

analizar

estas

amenazas

para

derrotarlas?. Modelo de amenazas de seguridad El enemigo: es capaz de enviar cualquier mensaje a cualquier proceso y tambin de leer o copiar cualquier mensaje entre un par de procesos. El ataque puede venir de un computador legtimamente
Copia autorizada. de m El enemigo

conectado

de

una

mquina

no

Proceso P

m` ^

Proceso Q 41

Canal de comunicaci

Figura 18. El enemigo

Cmo se pueden vencer las amenazas de seguridad? Criptografa y secretos compartidos Autenticacin Canales seguros ACTIVIDAD

Describa e ilustre la arquitectura cliente servidor de las siguientes aplicaciones: World Wide Web, email y Netnews.

Indique como cooperan los servidores al proveer el servicio en cada uno de sus ejemplos anteriores. RESUMEN La mayoria de los sistemas distribuidos se componen de una o mas variedades de modelos de arquitectura. El modleo cliente servidor es el mas usado, la Web y otros servicios de internet tales como FTP, news, dns y email se basan en este modelo, asi como el sistema local de archivos y otros mas. Los servicios como DNS que tienen un numero de usuarios grande y tratan con gran cantidad de informacin se basan en multiples servidores, el uso de particiones sobre los datos y la replicacin para facilitar la disponibilidad y tolerancia frente a fallos. El uso de cache en los clientes y servidores proxy se encuentran ampliamente extendidos para mejorar las prestaciones de un servicio. En el modelo de porcesos de igual a igual. Los procesos de aplicaciones distribuidas se comunican uno con otro directamente sin emplear servidores intermediarios.

42

La posibilidad de mover cdigo de un porceso a otro ha desembocado en algunas variantes del modelo cliente servidor, El ejemplo mas comn de esto es el Apple cuyo cdigo es aportado por unservidor web para ejecutarse en un cliente, proporcionando funcionalidades no disponibles en el cliente y al mejora de ciertas prestaciones debido a la proximidad con el cliente. Hemos presentado modelos de interaccion, fallo y seguridad que identifican las caracteristicas comunes de los componentes bsicos con que se construyen los sistemas distribuidos. El modelo de interaccion tiene que ver con las prestaciones de los procesos y los canales de comunicacin y con la ausencia de un reloj global. Tambin define un sistema asncrono como uno en el que no hay lmites en el tiempo de ejecucin de un proceso, el tiempo de reparto de un mensaje y la deriva de los relojes, siendo asi como se comporta el internet. El modelo de fallo clasifica los fallos de los procesos y los canales de comunicacin bsicos de un sistema distribuido. El enmascaramiento es una tcnica con la que se construye un servicio ms fiable sobre otro menos fiable, de modo que se enmascaran algunos fallos de este ltimo en particular, se puede construir un servicio de comunicacin fiable desde un canal de comunicacin bsico simplemente enmascarando sus fallos. El modelo de seguridad identifica las posibles amenazas a los procesos y los canales de comunicacin en sistema distribuido abierto, algunas de estas amenazas se relacionan con la integridad, los usuarios mal intencionados pueden modificar o repeitr los mensajes, otra amnaza es la privacidad y otra es la auteticidad. BIBLIOGRAFIA RECOMENDADA

43

George Colouris, Sistemas Distribuidos Conceptos y Diseo, Addison Wesley, Espaa 2001 http://www.cdk3.net/ Tanenbaum, Distributed Systems: Principles and

Paradigms, Prentice Hall, Mexico 2002. http://www.prenhall.com/divisions/esm/app/author_tanenb aum/custom/dist_sys_1/

o

Liu,

Distributed

Computing:

Principles

and

Applications, Addison Wesley, Mexico 2005 http://www.csc.calpoly.edu/~mliu/book/ AUTOEVALUACION FORMATIVA o Un motor de bsqueda es un servidor web que ofrece a los clientes lam oportunidad de buscar en ciertos ndices almacenados y (concurrentemente) lanzar varios esacaladores web para construir y actualizar estos ndices. Cules son los requisitos de sincronizacin entre estas actividades concurrentes? o Sugiera algunas aplicaciones para un modelo entre pares, distinguiendo entre casos en los que el estado de todos necesita ser idntico y casos que demandan menos consistencia. o Tabule los tipos de recursos locales que son vulnerables a un ataque por un programa no fiable que se descarga desde un lugar remoto y se ejcuta en un computador local. o Que factores afectan el modo de comportamiento de una aplicacin que accede a los datos compartidos administrados por un servidor? Describa los remedios disponibles y discuta su utilidad. o De algunos ejemplos de fallos en el hardware y el software de un sitema distribuido que puedan o no ser

44

tolerados mediante el uso de redundancia. en que punto podemos asegurar que el empleo de redundancia? cuando sea adecuado, hace que el sistema sea tolerante frente a fallos?

45

UNIDAD ACADMICA N 03

COMUNICACION A NIVEL DE REDES

Los sistemas distribuidos utlizan redes de area local, redes de area extendido e interredes para comunicarse. Las prestaciones, fiabilidad, escalabilidad, subyacentes movilidad influyen en y calidad el del servicio de de las redes comportamiento los sitemas

distribuidos. Los cambios en las necesidades de los usuarios han producido la irrupcin de las redes inalmbricas y las redes de altas prestaciones con calidad de servicio garantizada. Los fundamentos en los que se basan las redes de computadoras incluyen las capas de protocolos, el intercambio de paquetes, el encaminamiento y el flujo de datos. Las tcnicas de interconexin de redes hacen posible que se puedan combinar redes heterogeneas para que funcionen como una sola el Internet es el mejor ejemplo de esto, sus protocolos son casi universalmente utlizados en los sistemas distribuidos. Los modos de direccionamiento y encaminamiento usado en el internet han experimentado el impacto de su crecimiento. Tanto es asi que ahora se encuentran en porceso de revisio para que puedan soporta el crecimiento futuro y para poder cumplir con los requerimientos de movilidad, seguridad y calidad de servicios demandado. INDICADORES DE LOGRO Al terminar esta unidad el estudiante estar en condiciones de:

Definir, describir que es una red LAN, WAN y sus elementos. Definir y describir las reglas que permiten la comunicacin en una red. Definir y describir el modelo TCP/IP y el modelo OSI. Definir y describir la capa de transporte y los protocolos que trabajan en esta capa TCP y UDP
46

Realizar

el

proceso

de

encapsulamiento

de

datos

direccionamiento de puertos CONCEPTOS GENERALES DE LA COMUNICACIN POR COMPUTADORAS. 1. ELEMENTOS DELA COMUNICACIN Para que exista comunicacin deben existir los siguientes elementos: Origen del mensaje Canal de transmisin Destino del mensaje

La comunicacin comienza con un mensaje o informacin que se debe enviar desde una persona o dispositivo a otro. Las personas intercambian ideas mediante diversos mtodos de comunicacin. Todos estos mtodos tienen tres elementos en comn. El primero de estos elementos es el origen del mensaje o emisor. Los orgenes de los mensajes son las personas o los dispositivos electrnicos que deben enviar un mensaje a otras personas o dispositivos. El segundo elemento de la comunicacin es el destino o receptor del mensaje. El destino recibe el mensaje y lo interpreta. Un tercer elemento, llamado canal, est formado por los medios que proporcionan el camino por el que el mensaje viaja desde el origen hasta el destino. ELEMENTOS DE LA COMUNICACION

Figura 1. Elementos de la Comunicacin 47

En teora, una comunicacin simple, como un video musical o un e-mail puede enviarse a travs de la red desde un origen hacia un destino como un stream de bits masivo y continuo. Si en realidad los mensajes se transmitieron de esta manera, significar que ningn otro dispositivo podr enviar o recibir mensajes en la misma red mientras esta transferencia de datos est en progreso. Estos grandes streams de datos originarn retrasos importantes. Adems, si fall un enlace en la infraestructura de red interconectada durante la transmisin, se perder todo el mensaje y tendr que retransmitirse por completo. Un mejor enfoque para enviar datos a travs de la red es dividir los datos en partes ms pequeas y ms manejables. La divisin del stream de datos en partes ms pequeas se denomina segmentacin. La segmentacin de mensajes tiene dos beneficios principales. Primero: al enviar partes individuales ms pequeas del origen al destino, se pueden entrelazar diversas conversaciones en la red. El proceso que se utiliza para entrelazar las piezas de conversaciones separadas en la red se denomina multiplexacin. Segundo: la segmentacin puede aumentar la confiabilidad de las comunicaciones de red. No es necesario que las partes separadas de cada mensaje sigan el mismo recorrido a travs de la red desde el origen hasta el destino. Si una ruta en particular se satura con el trfico de datos o falla, las partes individuales del mensaje an pueden direccionarse hacia el destino mediante los recorridos alternativos. Si parte del mensaje no logra llegar al destino, slo se deben retransmitir las partes faltantes.
SEGMENTACION DE PAQUETES

48

Figura 2. Segmentacion de Paquetes

49

2. ELEMENTOS DE UNA RED Los dispositivos y los medios son los elementos fsicos o hardware de la red. 2.1 Dispositivos de una Red Varios tipos de dispositivos en toda la red participan para asegurar que las partes del mensaje lleguen a los destinos de manera confiable. Dispositivos Finales (host) Dispositivos Intermedios 2.1.1 Dispositivos Finales (host) En el contexto de una red, los dispositivos finales se denominan host. Un dispositivo host puede ser el origen o el destino de un mensaje transmitido a travs de la red. Para distinguir un host de otro, cada host en la red se identifica por una direccin. Cuando un host inicia una comunicacin, utiliza la direccin del host de destino para especificar dnde debe ser enviado el mensaje. Ejemplos: Computadoras (estaciones de trabajo, computadoras porttiles, servidores de archivos, servidores Web) Impresoras de red Telfonos VoIP Cmaras de seguridad Dispositivos mviles de mano (como escneres de barras inalmbricos, asistentes digitales personales (PDA)) En las redes modernas, un host puede funcionar como un cliente, como un servidor o como ambos. El software instalado en el host determina qu rol representa en la red. Los servidores son hosts que tienen software instalado que les permite proporcionar informacin y servicios, como e-mail o pginas Web, a otros hosts en la red, Los clientes son hosts que tienen software instalado
50

que les permite solicitar y mostrar la informacin obtenida del servidor. 2.1.2 Dispositivos Intermedios Las redes dependen de dispositivos intermediarios para proporcionar conectividad y para trabajar detrs de escena y garantizar que los datos fluyan a travs de la red. Estos dispositivos conectan los hosts individuales a la red y pueden conectar varias redes individuales para formar una internetwork. Los siguientes son ejemplos de dispositivos de red intermediarios:

Dispositivos de acceso a la red (hubs, switches y puntos de acceso inalmbricos), Dispositivos de internetworking (routers), Servidores de comunicacin y mdems. Dispositivos de seguridad (firewalls), etc. tambin es una funcin de los dispositivos

La administracin de datos mientras fluyen a travs de la red intermediarios. Estos dispositivos utilizan la direccin host de destino, conjuntamente con informacin sobre las interconexiones de la red, para determinar la ruta que deben tomar los mensajes a travs de la red. Los procesos que se ejecutan en los dispositivos de red intermediarios realizan las siguientes funciones:

Regenerar y retransmitr seales de datos Mantener informacin sobre qu rutas existen a travs de la red y de la internetwork. Notificar a otros dispositivos los errores y las fallas de comunicacin, direccionar datos por rutas alternativas cuando existen fallas en un enlace. Clasificar y direccionar mensajes segn las prioridades de QoS (calidad de servicio). Permitir o denegar el flujo de datos en base a configuraciones de seguridad.

51

2.2 Medios de una Red La comunicacin a travs de una red es transportada por un medio. El medio proporciona el canal por el cual viaja el mensaje desde el origen hasta el destino. Las redes modernas utilizan principalmente tres tipos de medios para interconectar los dispositivos y proporcionar la ruta por la cual pueden transmitirse los datos. Estos medios son:

Hilos metlicos dentro de los cables, Fibras de vidrio o plsticas (cable de fibra ptica), y Transmisin inalmbrica.

La codificacin de seal que se debe realizar para que el mensaje sea transmitido es diferente para cada tipo de medio. En los hilos metlicos, los datos se codifican dentro de impulsos elctricos que coinciden con patrones especficos. Las transmisiones por fibra ptica dependen de pulsos de luz, dentro de intervalos de luz visible o infrarroja. En las transmisiones inalmbricas, los patrones de ondas electromagnticas muestran los distintos valores de bits. Los diferentes tipos de medios de red tienen diferentes caractersticas y beneficios. No todos los medios de red tienen las mismas caractersticas ni son adecuados para el mismo fin.

52

Figura 3. Elementos de una Red 3. REGLAS QUE RIGEN LAS COMUNICACIONES

Luego tenemos que existen reglas para que se realice la comunicacin, a estas reglas en redes de computadoras la llamamos protocolos. Los protocolos de red describen las funciones que se producen durante las comunicaciones de red. Por ejemplo en una conversacin cara a carade dos personas, es posible que un protocolo para comunicar establezca que para indicar que la conversacin ha finalizado, el emisor debe permanecer en silencio durante dos segundos completos. Sin embargo, este protocolo no especifica cmo el emisor debe permanecer en silencio durante los dos segundos. Los protocolos generalmente no describen cmo cumplir una funcin en particular. Al describir solamente qu funciones se requieren de una regla de comunicacin en particular pero no cmo realizarlas, es posible que la implementacin de un protocolo en particular sea independiente de la tecnologa. Por ejemplo en un servidor Web, HTTP no especifica qu lenguaje de programacin se utiliza para crear el explorador, qu software de servidor Web se debe utilizar para servir las pginas Web, sobre qu sistema operativo se ejecuta el software o los requisitos necesarios para mostrar el explorador. Tampoco describe cmo detecta errores el servidor, aunque s describe qu hace el servidor si se produce un error. Esto significa que una computadora y otros dispositivos, como telfonos mviles o PDA, pueden acceder a una pgina Web almacenada en cualquier tipo de servidor Web que utilice cualquier tipo de sistema operativo desde cualquier lugar de Internet. Para visualizar la interaccin entre varios protocolos, es comn utilizar un modelo en capas. Un modelo en capas muestra el

53

funcionamiento de los protocolos que se produce dentro de cada capa, como as tambin la interaccin de las capas sobre y debajo de l. Existen dos tipos bsicos de modelos de networking: modelos de protocolo y modelos de referencia, el modelo OSI y modelo TCP/IP.

Figura 4. Modelos de Red

3.1 Es

Modelo TCP/IP el primer modelo de protocolo en capas para

comunicaciones de internetwork se cre a principios de la dcada de los setenta y se conoce con el nombre de modelo de Internet. Define cuatro categoras de funciones que deben tener lugar para que las comunicaciones sean exitosas. La arquitectura de la suite de protocolos TCP/IP de Internet se lo conozca como modelo TCP/IP. sigue la estructura de este modelo. Por esto, es comn que al modelo

54

El modelo TCP/IP describe la funcionalidad de los protocolos

TCP/IP

Figura 5. Modelo

que forman la suite de protocolos TCP/IP. Esos protocolos, que se implementan tanto en el host emisor como en el receptor, interactan para proporcionar la entrega de aplicaciones de extremo a extremo a travs de una red. Un proceso completo de comunicacin incluye estos pasos: o Creacin de datos a nivel de la capa de aplicacin del dispositivo final origen.
o

Segmentacin y encapsulacin de datos cuando pasan por la stack de protocolos en el dispositivo final de origen. Generacin de los datos sobre el medio en la capa de acceso a la red de la stack. Transporte de los datos a travs de la internetwork, que consiste de los medios y de cualquier dispositivo intermediario.

o o

o o o

Recepcin de los datos en la capa de acceso a la red del dispositivo final de destino. Desencapsulacin y rearmado de los datos cuando pasan por la stack en el dispositivo final. Traspaso de estos datos a la aplicacin de destino en la capa de aplicacin del dispositivo final de destino

55

Figura 6. Transporte de un paquete

Encapsulamiento de Datos Mientras los datos de la aplicacin bajan al stack del protocolo y se transmiten por los medios de la red, varios protocolos le agregan informacin en cada nivel. Esto comnmente se conoce como proceso de encapsulacin.
PROCESOS DE ENCAPSULAMIENTO DE DATOS

Figura 7. Encapsulamiento de Datos

La forma que adopta una seccin de datos en cualquier capa se denomina Unidad de datos del protocolo (PDU). Durante la encapsulacin, cada capa encapsula las PDU que recibe de la capa superior de acuerdo con el protocolo que se utiliza. En cada etapa del proceso, una PDU tiene un nombre distinto para reflejar su nuevo aspecto. Aunque no existe una convencin universal de nombres para las PDU, en este curso se denominan de acuerdo con los protocolos de la suite TCP/IP. Datos: el trmino general para las PDU que se utilizan en la capa de aplicacin. Segmento: PDU de la capa de transporte. Paquete: PDU de la capa de Internetwork. Trama: PDU de la capa de acceso a la red.

56

 Bits: una PDU que se utiliza cuando se transmiten fsicamente datos a travs de un medio.

Figura 8. Direccionamiento de PDU

Cuando se envan mensajes en una red, el stack del protocolo de un host funciona desde arriba hacia abajo. En el ejemplo del servidor Web podemos utilizar el modelo TCP/IP para ilustrar el proceso de envo de una pgina Web HTML a un cliente. El protocolo de la capa Aplicacin, HTTP, comienza el proceso entregando los datos de la pgina Web con formato HTML a la capa Transporte. All, los datos de aplicacin se dividen en segmentos TCP. A cada segmento TCP se le otorga una etiqueta, denominada encabezado, que contiene informacin sobre qu procesos que se ejecutan en la computadora de destino deben recibir el mensaje. Tambin contiene la informacin para habilitar el proceso de destino para reensamblar nuevamente los datos a su formato original. La capa Transporte encapsula los datos HTML de la pgina Web dentro del segmento y los enva a la capa Internet, donde se implementa el protocolo IP. Aqu, el segmento TCP en su totalidad es encapsulado dentro de un paquete IP, que agrega otro rtulo denominado encabezado IP. El encabezado IP

57

contiene las direcciones IP de host de origen y de destino, como tambin la informacin necesaria para entregar el paquete a su correspondiente proceso de destino. Luego el paquete IP se enva al protocolo Ethernet de la capa de acceso a la red, donde se encapsula en un encabezado de trama y en un triler. Cada encabezado de trama contiene una direccin fsica de origen y de destino. La direccin fsica identifica de forma exclusiva los dispositivos en la red local. El triler contiene informacin de verificacin de errores. Finalmente, los bits se codifican en el medio Ethernet mediante el servidor NIC.

Figura 9. Operacin de protocolo de envio y recepcion de

3.2

mensajes Modelo OSI

Inicialmente, el modelo OSI fue diseado por la Organizacin Internacional para la Estandarizacin (ISO, International Organization for Standardization) para proporcionar un marco sobre el cual crear una suite de protocolos de sistemas abiertos. La visin era que este conjunto de protocolos se utilizara para desarrollar una red internacional que no dependiera de sistemas propietarios. Lamentablemente, la velocidad a la que fue adoptada la Internet basada en TCP/IP y la proporcin en la que se expandi ocasionaron que el desarrollo y la aceptacin de la

58

suite de protocolos OSI quedaran atrs. Aunque pocos de los protocolos desarrollados mediante las especificaciones OSI son de uso masivo en la actualidad, el modelo OSI de siete capas ha realizado aportes importantes para el desarrollo de otros protocolos y productos para todos los tipos de nuevas redes.

Figura 10. Comunicacin capa a capa El modelo OSI describe los procesos de codificacin, formateo,

segmentacin y encapsulacin de datos para transmitir por la red. Un flujo de datos que se enva desde un origen hasta un destino se puede dividir en partes y entrelazar con los mensajes que viajan desde otros hosts hacia otros destinos. Miles de millones de estas partes de informacin viajan por una red en cualquier momento. Es muy importante que cada parte de los datos contenga suficiente informacin de identificacin para llegar al destino correcto. Existen varios tipos de direcciones que deben incluirse para entregar satisfactoriamente los datos desde una aplicacin de origen que se ejecuta en un host hasta la aplicacin de destino correcta que se ejecuta en otro.

59

Durante

el

proceso

de

encapsulacin,

se

agregan

identificadores de direccin a los datos mientras bajan al stack Figura 11. Direccionamiento por del protocolo encapas el host de origen. As como existen mltiples capas de protocolos que preparan los datos para transmitirlos a sus destinos, existen mltiples capas de direccionamiento para asegurar la entrega. El primer identificador, la direccin fsica del host, aparece en el encabezado de la PDU de Capa 2, llamado trama. La Capa 2 est relacionada con la entrega de los mensajes en una red local nica. La direccin de la Capa 2 es exclusiva en la red local y representa la direccin del dispositivo final en el medio fsico. En una LAN que utiliza Ethernet, esta direccin se denomina direccin de Control de Acceso al medio (MAC). Cuando dos dispositivos se comunican en la red Ethernet local, las tramas que se intercambian entre ellos contienen las direcciones MAC de origen y de destino. Una vez que una trama se recibe satisfactoriamente por el host de destino, la informacin de la direccin de la Capa 2 se elimina mientras los datos se desencapsulan y suben el stack de protocolos a la Capa 3. Los protocolos de Capa 3 estn diseados principalmente para mover datos desde una red local a otra red local dentro de una internetwork. Mientras las direcciones de Capa 2 slo se utilizan para comunicar entre dispositivos de una red local nica, las direcciones de Capa 3 deben incluir identificadores que permitan a dispositivos de red intermediarios ubicar hosts en diferentes redes. En la suite de protocolos TCP/IP, cada direccin IP host contiene informacin sobre la red en la que est ubicado el host. En los lmites de cada red local, un dispositivo de red intermediario, por lo general un router, desencapsula la trama para leer la direccin host de destino contenida en el

60

encabezado del paquete, la PDU de Capa 3. Los routers utilizan la porcin del identificador de red de esta direccin para determinar qu ruta utilizar para llegar al host de destino. Una vez que se determina la ruta, el router encapsula el paquete en una nueva trama y lo enva por su trayecto hacia el dispositivo final de destino. Cuando la trama llega a su destino final, la trama y los encabezados del paquete se eliminan y los datos se suben a la Capa 4.

Figura 12. Direccionamiento en la capa 3

En la Capa 4, la informacin contenida en el encabezado de la PDU no identifica un host de destino o una red de destino. Lo que s identifica es el proceso o servicio especfico que se ejecuta en el dispositivo host de destino que actuar en los datos que se entregan. Los hosts, sean clientes o servidores en Internet, pueden ejecutar La mltiples que un tiene aplicaciones utiliza cliente de de red simultneamente. personales gente computadoras correo

generalmente

electrnico que se ejecuta al mismo tiempo que el explorador Web, un programa de mensajera instantnea, algn streaming media y, tal vez, incluso algn juego. Todos estos programas ejecutndose en forma separada son ejemplos de procesos individuales. Ver una pgina Web invoca al menos un proceso de red. Hacer clic en un hipervnculo hace que un explorador Web se

61

comunique con un servidor Web. Al mismo tiempo, en segundo plano, es posible que cliente de correo electrnico est enviando o recibiendo un e-mail y un colega o amigo enviando un mensaje instantneo. Piense en una computadora que tiene slo una interfaz de red. Todos los streams de datos creados por las aplicaciones que se estn ejecutando en la PC ingresan y salen a travs de esa sola interfaz, sin embargo los mensajes instantneos no emergen en el medio del documento del procesador de textos o del e-mail que se ve en un juego. Esto es as porque los procesos individuales que se ejecutan en los hosts de origen y de destino se comunican entre s. Cada aplicacin o servicio es representado por un nmero de puerto en la Capa 4. Un dilogo nico entre dispositivos se identifica con un par de nmeros de puerto de origen y de destino de Capa 4 que son representativos de las dos aplicaciones de comunicacin. Cuando los datos se reciben en el host, se examina el nmero de puerto para determinar qu aplicacin o proceso es el destino correcto de los datos

Figura 13. Direccionamiento en la capa 4 Cada capa ofrece lo mejor para garantizar la comunicacin

entre procesos. Durante la clase, observamos que los Sistemas Distribuidos se desarrollan sobre la capa transporte. 4. CAPA DE TRANSPORTE

62

La capa de Transporte permite la segmentacin de datos y brinda el control necesario para reensamblar las partes dentro de los distintos 4.1
4.1.1

streams

de de

comunicacin. la

Las

responsabilidades individual entre

principales que debe cumplir son: seguimiento comunicacin aplicaciones en los hosts origen y destino, segmentacin de datos y gestin de cada porcin, reensamble de segmentos en flujos de datos de

aplicacin, e identificacin de las diferentes aplicaciones. Responsabilidades de la capa de Red Seguimiento de Conversaciones individuales: Cualquier host puede tener mltiples aplicaciones que se estn comunicando a travs de la red. Cada una de estas aplicaciones se comunicar con una o ms aplicaciones en hosts remotos. Es responsabilidad de la capa de Transporte mantener los diversos streams de comunicacin entre estas aplicaciones. 4.1.2 Segmentacin de datos: Debido a que cada aplicacin genera un stream de datos para enviar a una aplicacin remota, estos datos deben prepararse para ser enviados por los medios en partes manejables. Los protocolos de la capa de Transporte describen los servicios que segmentan estos datos de la capa datos de de Aplicacin. aplicacin Esto incluye la encapsulacin se agreguen necesaria en cada seccin de datos. Cada seccin de requiere que encabezados en la capa de Transporte para indicar la comunicacin a la cual est asociada.
4.1.3

Reensamble de segmentos: En el host de recepcin, cada seccin de datos puede ser direccionada a la aplicacin adecuada. Adems, estas

63

secciones

de

datos

individuales

tambin

deben

reconstruirse para generar un stream completo de datos que sea til para la capa de Aplicacin. Los protocolos de la capa de Transporte describen cmo se utiliza la informacin de encabezado secciones de de dicha en capa para y reensamblar las datos streams

enviarlas a la capa de Aplicacin.

4.1.4

Identificacin de las aplicaciones: Para poder transferir los streams de datos a las aplicaciones adecuadas, la capa de Transporte debe identificar la aplicacin de destino. Para lograr esto, la capa de Transporte asigna un identificador a la aplicacin. Los protocolos TCP/IP denominan a este identificador nmero de puerto. A todos los procesos de software que requieran acceder a la red se les asigna un nmero de puerto exclusivo en ese host. Este nmero de puerto se utiliza en el encabezado de la capa de Transporte para indicar con qu aplicacin est asociada esa seccin de datos.

La capa de Transporte es el enlace entre la capa de Aplicacin y las capas inferiores, que son responsables de la transmisin en la red. Esta capa acepta datos de distintas conversaciones y los transfiere a las capas inferiores como secciones manejables que puedan ser eventualmente multiplexadas a travs del medio. Las aplicaciones no necesitan conocer los detalles de operacin de la red en uso. Las aplicaciones generan datos que se envan desde una aplicacin a otra sin tener en cuenta el tipo de host destino, el tipo de medios sobre los que los datos deben viajar, el paso tomado por los datos, la congestin en un enlace o el tamao de la red. Adems, las capas inferiores no tienen conocimiento de que existen varias aplicaciones que envan datos en la red. Su responsabilidad es entregar los datos al dispositivo adecuado.

64

Luego la capa de Transporte ordena estas secciones antes de entregarlas a la aplicacin adecuada. Los requerimientos de datos varan, debido a que las distintas aplicaciones poseen distintos requerimientos, existen varios protocolos de la capa de Transporte. Para algunas aplicaciones, los segmentos deben llegar en una secuencia especfica de manera que puedan ser procesados en forma exitosa. En algunos casos, todos los datos deben recibirse para ser utilizados por cualquiera de las mismas. En otros casos, una aplicacin puede tolerar cierta prdida de datos durante la transmisin a travs de la red. En las redes convergentes actuales, las aplicaciones con distintas necesidades de transporte pueden comunicarse en la misma red. Los distintos protocolos de la capa de Transporte poseen distintas reglas que permiten que los dispositivos gestionen los diversos requerimientos de datos. Algunos protocolos proporcionan slo las funciones bsicas para la entrega eficiente de las secciones de datos entre las aplicaciones adecuadas. Estos tipos de protocolos son tiles para aquellas aplicaciones cuyos datos son sensibles a las demoras. Otros protocolos de la capa de Transporte describen procesos que brindan funciones adicionales, como asegurar la entrega confiable entre las aplicaciones. Si bien estas funciones adicionales proveen una comunicacin ms slida entre aplicaciones de la capa de Transporte, representan la necesidad de utilizar recursos adicionales y generan un mayor nmero de demandas en la red.

65

Figura 14. Habilitacion de los dispositivos para la

4.2

comunicacion Protocolos de la capa de Transporte

Los dos protocolos ms comunes de la capa de Transporte del conjunto de protocolos TCP/IP son el Protocolo de control de transmisin (TCP) y el Protocolos de datagramas de usuario (UDP). Ambos protocolos gestionan la comunicacin de mltiples aplicaciones. Las diferencias entre ellos son las funciones especficas que cada uno implementa. 4.2.1 Protocolo de datagramas de usuario (UDP)

UDP es un protocolo simple, sin conexin, descrito en la RFC 768. Cuenta con la ventaja de proveer la entrega de datos sin utilizar muchos recursos. Las porciones de comunicacin protocolo de en la UDP capa se de llaman datagramas. enva Este estos Transporte

datagramas como "maximo esfuerzo". Entre las aplicaciones que utilizan UDP se incluyen: Sistema de nombres de dominios (DNS), streaming de vdeo, y Voz sobre IP (VoIP). 4.2.2 Protocolo de control de transmisin (TCP)

TCP es un protocolo orientado a la conexin, descrito en la RFC 793. TCP incurre en el uso adicional de recursos para agregar funciones. Las funciones adicionales especificadas por TCP estn en el mismo orden de entrega, son de entrega confiable y de control de flujo. Cada segmento de TCP posee 20 bytes de carga en el encabezado, que encapsulan los datos de la capa de

66

Aplicacin, mientras que cada segmento UDP slo posee 8 bytes de carga. Ver la figura para obtener una comparacin. Las aplicaciones que utilizan TCP son: exploradores Web, e-mail, y transferencia de archivos

Figura 15. Encabezado TCP y UDP Considere el siguiente ejemplo, una computadora que recibe y

enva e-mails, mensajes instantneos, pginas Web y llamadas telefnicas VoIP de manera simultnea. Los servicios basados en TCP y UDP mantienen un seguimiento de las varias aplicaciones que se comunican. Para diferenciar los segmentos y datagramas para cada aplicacin, tanto TCP como UDP cuentan con campos de encabezado que pueden identificar de manera exclusiva estas aplicaciones. Estos identificadores nicos son los nmeros de los puertos. En el encabezado de cada segmento o datagrama hay un puerto de origen y destino. El nmero de puerto de origen es el nmero para esta comunicacin asociado con la aplicacin que origina la comunicacin en el host local. El nmero de puerto de destino es el nmero para esta comunicacin asociado con la aplicacin de destino en el host remoto. Los nmeros de puerto se asignan de varias maneras, en funcin de si el mensaje es una solicitud o una respuesta. Mientras que los procesos en el servidor poseen nmeros de

67

puertos estticos asignados a ellos, los clientes eligen un nmero de puerto de forma dinmica para cada conversacin. Cuando una aplicacin de cliente enva una solicitud a una aplicacin de servidor, el puerto de destino contenido en el encabezado es el nmero de puerto que se asigna al daemon de servicio que se ejecuta en el host remoto. El software del cliente debe conocer el nmero de puerto asociado con el proceso del servidor en el host remoto. Este nmero de puerto de destino se puede configurar, ya sea de forma predeterminada o manual. Por ejemplo, cuando una aplicacin de explorador Web realiza una solicitud a un servidor Web, el explorador utiliza TCP y el nmero de puerto 80 a menos que se especifique otro valor. Esto sucede porque el puerto TCP 80 es el puerto predeterminado asignado a aplicaciones de servidores Web. Muchas aplicaciones comunes tienen asignados puertos predeterminados. El puerto de origen del encabezado de un segmento o datagrama de un cliente se genera de manera aleatoria. Siempre y cuando no entre en conflicto con otros puertos en uso en el sistema, el cliente puede elegir cualquier nmero de puerto. El nmero de puerto acta como direccin de retorno para la aplicacin que realiza la solicitud. La capa de Transporte mantiene un seguimiento de este puerto y de la aplicacin que gener la solicitud, de manera que cuando se devuelva una respuesta, pueda ser enviada a la aplicacin correcta. El nmero de puerto de la aplicacin que realiza la solicitud se utiliza como nmero de puerto de destino en la respuesta que vuelve del servidor. La combinacin del nmero de puerto de la capa de Transporte y de la direccin IP de la capa de Red asignada al host identifica de manera exclusiva un proceso en particular que se ejecuta en un dispositivo host especfico. Esta combinacin se denomina socket. Un par de sockets, que

68

consiste en las direcciones IP y los nmeros de puerto de origen y de destino, tambin es exclusivo e identifica la conversacin entre dos hosts. Ejemplo: una solicitud de pgina Web HTTP que se enva a un servidor Web (puerto 80) y que se ejecuta en un host con una direccin IPv4 de Capa 3 192.168.1.20 ser destinada al socket 192.168.1.20:80. Si el explorador Web que solicita la pgina Web se ejecuta en el host 192.168.100.48 y el nmero de puerto dinmico asignado al explorador Web es 49152, fig.16. Se debe considerar que TCP no enva datos a la red hasta que advierte que el destino est preparado para recibirlos. Luego TCP administra el flujo de datos y reenva todos los segmentos de datos de los que recibi acuse a medida que se reciben en el destino. TCP utiliza mecanismos de enlace, temporizadores y acuses de recibo y uso dinmico de ventanas para llevar a cabo estas funciones confiables. Sin embargo, esta confiabilidad representa cierta sobrecarga en la red en trminos de encabezados de segmentos ms grandes y mayor trfico de red entre el origen y el destino que administra el transporte de datos. el socket para la pgina Web ser 192.168.100.48:49152, tal como se muestra en la

69

Figura 16. Direccionamiento de

Si los datos de aplicacin necesitan ser entregados a la red de manera rpida o si el ancho de banda de la red no admite la sobrecarga de mensajes de control que se intercambian entre los sistemas de origen y destino, UDP ser el protocolo de la capa de Transporte preferido por el desarrollador. Esto es as porque UDP no rastrea ni reconoce la recepcin de datagramas en el destino, slo enva los datagramas recibidos a la capa de Aplicacin a medida que llegan, y no reenva datagramas perdidos. Sin embargo, esto no significa necesariamente que la comunicacin no es confiable; puede haber mecanismos en los protocolos y servicios de la capa de Aplicacin que procesan datagramas perdidos o demorados si la aplicacin cuenta con esos requerimientos. El desarrollador de la aplicacin toma una decisin en cuanto al protocolo de la capa de Transporte en base a los requerimientos del usuario. Sin embargo, el desarrollador tiene en cuenta que las otras capas cumplen un rol importante en las comunicaciones de redes de datos y tendrn influencia en el rendimiento. ACTIVIDAD

puertos

Un cliente enva un mensaje de solicitud de 200 bytes a un servicio, que produce una respuesta conteniendo 5000 bytes. Estime el tiempo total necesario para completar la operacin en cada uno de los siguientes casos:
o

Utilizando

una

comunicacin

de

datagramas

no

orientado a conexin (por ejemplo UDP).

o

Utilizando una comunicacin orientada a conexin (por ejemplo TCP).

70

El proceso servidor se encuentra en la misma maquina del cliente. [Latencia por paquete (local o remoto tanto al enviar como al recibir): 5ms Tiempo de establecimiento de conexin (solo TCP): 5ms Tasa de transferencia de datos: 10Mbps. MTU: 1000 bytes Tiempo de procesado de solicitud en el servidor: 2ms Supongase que la red esta un poco cargada]

RESUMEN En esta parte hemos enfocado nuestra atencin en los conceptos y en las tcnicas de las redes que se necesitan como base para los sistemas distribuidos y no hemos aproximado a ellos desde el punto de vista de un diseador de sistemas distribuidos. Las redes de datos y los protocolos en cada capa son la base de las comunicaciones en los sistemas distribuidos. Las redes de rea local se basan en la difusin de paquetes en un medio comn, y Ethernet es la tecnolgia dominante. Las redes rea amplia se basan en la conmutacin de paquetes para encaminar los paquetes hacia sus destinos a travs de la red conectada. El encaminamiento es el mecanismo clave y son varios los algoritmos de encaminamiento utlizados, de los cuales los de vector distancia es el mas bsico pero efectivo. Es necesario un control de la congestion para prevenir el desbordamiento de los buferes en el receptor y en los nodos intermedios. Las interredes se construyen colocando una capa virtual de protocolo de intered sobre la colleccion unidas por los Routers. Los portocolos de internet TCP/IP hacen posible que los computadores en internet se comuniquen con cualquier otro de una forma uniforme, independientemente de que se encuentren que se encuentren en la misma red de rea local o en pases

71

diferentes.

Los

estndares

de

internet

incluyen

varios

protocolos del nivel de aplicacin que resultan adecuadas para su uso en aplicaciones distribuidas a gran escala.IPv6 tiene el espacio de direccionamiento necesario para la evolucin futura de internet y aporta los medios para satisfacer los requisitos de las nuevas aplicaciones tales como calidad de servicio y seguridad. Los usuarios mviles tiene soporte de IP mvil en su deambular por reas amplias, y por las LAN inalmbricas basada en la IEEE 802.11 para una conectividad local. BIBLIOGRAFIA RECOMENDADA o GARCIA, P. DIAZ, J. LOPEZ , J. Transmisin de Datos y Redes de Computadores. Pearson. Prentice Hall. (2003) o CISCO Systems, Gua del 1er ao CCNA1 y CCNA2. Academia de Networking de Cisco Systems. CiscoPress. Editorial Pearson. Madrid(2005)
o

George Colouris, Sistemas Distribuidos Conceptos y Diseo, Addison Wesley, Espaa 2001 http://www.cdk3.net/ Tanenbaum, Distributed Systems: Principles and

Paradigms, Prentice Hall, Mexico 2002. http://www.prenhall.com/divisions/esm/app/author_tanenb aum/custom/dist_sys_1/

o

Liu,

Distributed

Computing:

Principles

and

Applications, Addison Wesley, Mexico 2005 http://www.csc.calpoly.edu/~mliu/book/ AUTOEVALUACION FORMATIVA o Internet es demasiado grande para que cualquier Router pueda almacenar la informacin de encaminamiento para

72

todos

los

nodos.

Cmo

resuelve

el

esquema

de

encaminamiento de Internet este problema? o Cul es el cometido de un conmutador Ethernet? Qu tablas de direcciones contiene? o Que tipos de enrutamiento existe y cual es el fin de cada uno? o Describa el modo en que deberia configurar un cortafuegos para proteger la red local de su institucio o empresa Qu solicitudes entrantes y salientes debera interceptar?
o o

Explique el proceso de encapsulamiento? Explique el direccionamiento de puertos en las siguientes aplicaciones de la fig. 17

Figura 17. Aplicaciones de internet

UNIDAD ACADMICA N 04

COMUNICACION ENTRE PROCESOS EN SISTEMAS DISTRIBUIDOS

73

En el presente capitulo estudiaremos las caracteristicas de los protocolos que permiten la comunicacin entre procesos en un sistema distribuido, ya sea por si mismos o como soporte para la comunicacin entre objetos. La interfaz de programcion de aplicaciones (API) de java para la comunicacin de procesos en internet proporciona comunicacin tanto por datagramas como or streams. Estas proveen bloques constructivos alternativos para los protocolos de comunicacin. INDICADORES DE LOGRO Al terminar esta unidad el estudiante estar en condiciones de:

Definir, describir que es la comunicacin entre procesos en sistemas distribuidos. Definir, describir la comunicacin por paso de mensajes Definir y describir el llamado a un procediemiento remoto (RPC) Definir y describir la comunicacin Cliente Servidor. Definir y describir la comunicacin en grupo.
Aplicaciones, servicios. RMI y RPC Este cap ulo

Protocolo petici respuesta Empaquetado y representaci externa de datos UDP y TCP Figura 1. Capas Middleware

}
EN

Capas Middleware

Qu es un proceso? Es un programa en ejecucion. COMUNICACIN DISTRIBUIDOS Despus de haber revizado los de procesos en Sistemas Distribuidos. El sistema de comunicacin es la Distribuidos. espina dorsal de los Sistemas conceptos de redes para la comunicacion ahora introduscamonos en nuestro tema comunicacin ENTRE PROCESOS SISTEMAS

74

La comunicacin entre procesos en S.D. necesita compartir informacin:

Figura 2. Proceso de compartir

La comunicacin entre procesos en un ambiente distribuido no puede hacerse por memoria compartida; la nica posibilidad es por intercambio de mensajes. COMUNICACION POR PASO DE MENSAJE La comunicacin por paso de mensajes entre dos proceso se puede basar en dos operaciones enva y recibe, definidas en funcin del destino y del mensaje. Para que un proceso se comunique con otro, el proceso enva un mensaje (secuencia de bytes) a un destino y otro proceso en el destino recibe el mensaje, esta actividad implica la comunicacin de datos desde el proceso emisor hasta el proceso receptor, puede implicar adems la sincronizacin de los dos procesos. Caractersticas deseables de un buen sistema de paso de mensajes 1.1 Simplicidad Simple y fcil de usar (uso directo) Hacer sin preocuparse de aspectos de la red/sistema 1.2 Semntica uniforme en: Comunicaciones remotas Eficiencia Comunicaciones locales

informacion

1.3

75

Criterio: reduccin del nmero de mensajes intercambiados por que las IPC son costosas. Optimizacin incluye: Evitar el costo de establecer y terminar conexiones entre el mismo par de procesos y cada intercambio de mensajes entre ellos. Minimizar el costo de mantener la conexin.

Optimizar los reconocimientos cuando hay una serie de mensajes entre el send y receive. Flexibilidad incluyendo send/receive sincrnicos y

1.4

Deben permitir alguna clase de control de flujo entre procesos cooperativos, asincrnicos. 1.5 Seguridad
Autenticacin Autenticacin

del receptor de un mensaje por el enviador del enviador de un mensaje por el receptor

Encriptacin del mensaje 1.6 Confiabilidad La cada del nodo o enlace implica prdida de mensaje. Se usan timeouts (duplicacin de mensajes) 1.7 Correctitud
Atomicidad Orden

Pueden enviarse multicast de despacho

Persistencia

1.8

Portabilidad

El sistema de pasaje de mensajes debe ser portable (posible construccin de protocolos de IPC reusando el mismo sistema de mensajes)

76

Heterogeneidad de mquinas representacin. ESTRUCTURA TIPICA DE MENSAJES

compatibilizacin de

El enviador determina el contenido del mensaje. El receptor tiene en cuenta como interpretar los datos Estructura tica de mensaje

Figura 3. Estructura tipica de un mensaje

3 RENDIMIENTO DE UN SISTEMA DISTRIBUIDO El rendimiento de un sistema de computacin distribuida depende en gran medida de la comunicacin rpida entre procesos. Para que la comunicacin entre procesos sea rapida depende de dos partes:

Las primitivas de comunicacin entre procesos El protocolo de transporte sobre el cual trabajan esas PRIMITIVAS DE COMUNICACIN

primitivas. 3.1 El paso de mensajes entre un par de procesos se puede basar en dos operaciones primitivas, enva y recibe definidas en funcin del destino y del mensaje. Para que un proceso se pueda comunicar con otro, el proceso enva un mensaje (una secuencia de bytes) a un destino y otro proceso en el destino recibe el mensaje. 3.1.1. Primitivas con bloqueo o sin bloqueo

77

Una primitiva tiene una semntica sin bloqueo cuando su ejecucin no produce un retardo en el proceso que la invoca; de otra manera la primitiva es con bloqueo. Existen bsicamente cuatro tipos de comunicacin para este tipo de primitivas:

Send

con

bloqueo

(CPU

inactivo

durante

la

transmisin de los mensajes)

Send sin bloqueo, sin copia (no se puede sobrescribir hasta que el mensaje haya sido ledo) Send sin bloqueo, con copia (se desperdicia el tiempo del CPU para la copia adicional) Send sin bloqueo, con interrupcin (dificulta la programacin).

Figura 4. Mensajes Bloqueantes Vs. No bloqueantes

3.1.2

Primitivas

almacenadas

con

buffer

no

almacenadas. Cuando se efecta un intercambio de mensajes se presentan dos casos en relacin a donde se va a almacenar la informacin. En el primero de estos es el proceso servidor es el que destina una rea para recibir un mensaje al efectuar la operacin receive (no almacenado); mientras que en el segundo el proceso servidor solicita la creacin de un buzn para alojar los mensajes que van a ser recibidos mientras los puede procesar (almacenamiento con buffers).

78

En sistemas sin buffer, la ejecucin de un send se detiene hasta que en el otro extremo se ejecuta un receive (si se utiliz bloqueo). En ese momento el mensaje es enviado y ambos procesos pueden continuar su ejecucin. Ambos procesos se sincronizan o se encuentran cuando el mensaje es transferido. Los sistemas con buffer son ms difciles de controlar debido a la necesidad de crear, destruir y mantener los buffers.

Figura 5. Transferencia de

3.1.3

Primitivas confiables y no confiables

mensajes

Existen tres distintos enfoques de este problema. El Primero consiste en volver a definir la semntica de mensaje enva (send) para hacerlo no confiable. El sistema no da garanta alguna acerca de la entrega de mensajes. La implantacin de una comunicacin se deja enteramente en manos de los usuarios El de Segundo la mtodo exige que el ncleo de la mquina receptora enve un reconocimiento al ncleo mquina emisora. Slo cuando se reciba este reconocimiento, el ncleo emisor liberar al proceso usuario (cliente). El reconocimiento va de un ncleo al otro; ni el cliente, ni el servidor ven alguna vez un reconocimiento. De la misma forma que la solicitud de un cliente a un servidor es reconocida por el ncleo del servidor, la respuesta del servidor de regreso al

79

cliente es reconocida por el ncleo del cliente. As una solicitud de respuesta consta de cuatro mensajes. El Tercer mtodo aprovecha el hecho de que la comunicacin cliente-servidor se estructura como una solicitud del cliente al servidor, seguida de una respuesta del servidor al cliente. En este mtodo, el cliente se bloquea despus de enviar un mensaje. El ncleo del servidor no enva de regreso un reconocimiento sino que la misma respuesta funciona como tal. As, el emisor permanece bloqueado hasta que regresa la respuesta. Si tarda demasiado, el ncleo emisor puede volver a enviar la solicitud para protegerse contra la posibilidad de una prdida del mensaje. Una consideracin ms dentro de la comunicacin por paso de mensajes es la determinacin del receptor o receptores de un mensaje. Se tienen tres opciones: Transmisin a un slo receptor (unicast) Transmisin radial (broadcast) Transmisin radial mltiple (multicast) 3.2 PROTOCOLOS DE INTERCOMUNICACIN DE

PROCESOS En el diseo de un protocolo de intercomunicacin entre procesos el programador debe considerar lo siguiente: Quin enva ? Quin recibe ? Hay uno o varios receptores ? Est garantizado que el mensaje ha sido aceptado por el receptor ? Necesita el send esperar una respuesta ? Qu se debe hacer si falla el sitio y/o enlace ? Qu sucede si el receptor no est listo para recibir el mensaje ?
80

 Si hay varios mensajes esperando en el receptor, puede ste cambiar el orden?

81

4 NIVEL DE ABSTRACCIN EN COMUNICACIN CON PASO DE MENSAJES: Diferentes conjuntos de primitivas pueden ser usados en la comunicacin entre procesos remotos. Los tres ms comunes estn basados en:

Paso de mensajes puro.

Llamado a procedimientos remotos Transacciones. El orden en la lista anterior indica que cada forma de comunicacin puede ser construida en base a la anterior. En otras palabras, a mayor nmero, mayor nivel de abstraccin.
4.1 PASO

DE MENSAJES PURO

Un mensaje es una coleccin de datos de cierto tipo consistente en un encabezado y un cuerpo de longitudes fijas o variables, la cual puede ser manejada por un comunicacin un mensaje proceso y entregada a su destinatario. La cliente-servidor. El proceso cliente enva

orientada a mensajes est ntimamente ligada al modelo (peticin) a un proceso servidor y espera una respuesta o contina ejecutndose. Las primitivas de comunicacin por paso de mensajes son send y receive. En algunos sistemas, la primitiva receive puede ser selectiva o condicional si se agrega un guardia al llamar a la primitiva. Existen diversas formas o interpretaciones semnticas de las primitivas: 4.1.1 Direccionamiento: Existen Para que un cliente pueda enviar un mensaje a un servidor, debe conocer la direccin de ste. varios mtodos por los que un cliente puede conocer o determinar la direccin del servidor, a continuacin se mencionan tres de ellas: 4.1.1.1 Asignacin predeterminada numrica fija

82

en este caso la direccin del servidor es acordada en forma anterior o durante el desarrollo de las aplicaciones cliente-servidor, y por ello se puede incluir en el programa ejecutable (ejemplo en un archivo de encabezados header.h). Aunque esta estrategia podra funcionar en un sistema particularmente sencillo, es necesaria una forma ms sofisticada de direccionamiento. Aqu cabe sealar que no se ha determinado que es lo que significa el nmero asignado, es decir, no especifica si es la identificacin de un proceso o de un equipo.

Figura 6. Asignacion fija predeterminada

4.1.1.2 Asignacin aleatoria de nmero de proceso Este mtodo consiste en dejar que cada proceso elija su propio identificador de un espacio de direcciones grande y disperso, como el espacio de enteros de 64 bits. La probabilidad de que dos procesos elijan el mismo nmero es muy pequea. Este mtodo puede utilizarse en sistemas grandes. Sin embargo existe el problema de saber a que mquina enviar el mensaje?. Para ello el emisor podra enviar un paquete especial de localizacin con la direccin del proceso destino. Puesto que es un paquete de transmisin, ser recibido por todas

83

las mquinas de la red. Todos los ncleos verifican si la direccin es la suya y, en caso de que lo sea, regresa el mensaje de aqu estoy con su direccin en la red (nmero de mquina).

Figura 7. Asignacion Aleatoria de numero de proceso 4.1.1.3

Servidor de nombres transparente, la

Aun asi el esquema anterior es

transmisin provoca carga adicional en el sistema. Esta carga se puede evitar mediante una mquina adicional para la asociacin a alto nivel (es decir en ASCII) de los nombres de servicios con las direcciones de las mquinas. Al utilizar este sistema, se hace referencia a los procesos del tipo de los servidores mediante cadenas en ASCII, las cuales son las que introducen en los programas y no los nmeros en binario de las mquinas o procesos. Cada vez que se ejecute un cliente, en su primer intento por utilizar el servidor, el cliente enva una solicitud de cuestionamiento a un servidor especial de asociaciones, el cual se conoce como servidor de nombres para pedirle el nmero de mquina donde se localiza en ese momento el servidor.
84

Figura 7. Servidor de nombres 4.2

LLAMADOS A PROCEDIMIENTOS REMOTOS

El llamado a procedimientos remotos (RPC) implica que un proceso cliente enva una peticin y permanece bloqueado hasta que el proceso servidor devuelve una respuesta. El objetivo de los RPCs es permitir que los programas en un ambiente distribuido se escriban con el mismo estilo que los programas en un sistema de cmputo centralizado. Una de las principales ventajas de este esquema de comunicacin es que los programadores no requieren saber si un llamado a procedimiento se atender local o remotamente. La responsabilidad del mecanismo RPC es convertir llamadas escritas en un lenguaje de programacin y manejar los tipos de datos de alto nivel traducindolos en llamadas a servicios del nivel de Transporte en una red. El mecanismo RPC est asociado con servicios en los niveles de Presentacin y Sesin en el modelo OSI: Las primitivas de comunicacin en RPC son: Del lado del cliente: call service (value_args; result_args) Del lado del servidor: accept service (in value_parameters; out result_parameters) body Profundizaremos esto mas adelante 4.3 TRANSACCIONES

85

Dentro de los sistemas distribuidos, hay muchos casos en que una sola comunicacin no resuelve problemas especficos de interaccin entre dos procesos (por ejemplo, un retiro de una cuenta bancaria). La interaccin entre los procesos puede ser una secuencia de comunicaciones y clculos. En estas situaciones, es adecuado operar en base a transacciones. El concepto de transaccin se desarroll en sistemas de manejo de bases de datos para mantener la consistencia de la informacin almacenada. Los mecanismos de transacciones simplifican la construccin de sistemas confiables, y son transparentes para las aplicaciones de usuario (nivel de Sesin en el modelo OSI). En general, el trmino transaccin describe una secuencia de operaciones sobre una o ms bases de datos que transforma un estado consistente del sistema en otro estado consistente. No todos los estados de un sistema son consistentes y, por lo tanto, algunos cambios no los son permitidos. Las aseveraciones Propiedades: propiedades: Consistencia. Atomicidad.ejecutarse. Durabilidad.- una vez que se complet con buen xito, una transaccin no se puede cancelar (al menos que se aplique otra transaccin). Los sistemas de transacciones deben soportar las y siguientes recuperacin [CCR]). operaciones: terminacin, (Commitment, concurrencia debe debe mantener ejecutarse la consistencia o del no sistema en que se aplica. completamente que describen Las cambios tienen las permitidos siguientes

reciben el nombre de restricciones de consistencia. transacciones

Concurrency

and Recovery

86

5 SINCRONIZACION DE PROCESOS Como mencionamos anteriormente el paso de mensajes entre un par de procesos se puede basar en dos operaciones, enva y recibe definidas en funcin del destino y del mensaje. Para que un proceso se pueda comunicar con otro, el proceso enva un mensaje (una secuencia de bytes) a un destino y otro proceso en el destino recibe el mensaje. Esta actividad implica la comunicacin de datos desde el proceso emisor al proceso receptor y puede implicar adems la sincronizacin de los procesos. Entonces a cada destino de mensajes se asocia una cola, los procesos emisores producen mensajes que sern aadidos a las colas remotas mientras que los procesos receptores locales eliminaran mensajes de las colas locales. La comunicacin entre los proceso emisor y receptor puede ser Sncrona o asncrona.
5.1

Comunicacin Sncrona se sincronizan con cada

Lo procesos emisor y receptor

mensaje, aqu tanto enva como recibe son operaciones bloqueantes, es decir a cada enva producido el proceso emisor se bloquea hasta que se produce el correspondiente recibe y cuando se invoca un recibe el proceso se bloquea hasta que llegue un mensaje
5.2 Comunicacin

Asncrona

En la comunicacin asncrona la utilizacin de la operacin asncrona es no bloqueante de tal forma que el proceso emisor pueda continuar tan pronto como el mensaje haya sido copiado en el buffer local, la transmisin del mensaje se lleva a cabo en paralelo con el proceso emisor. La operacin recibe puede tener variantes bloqueantes y no bloqueantes. Comunicacin Sncrona Vs Comunicacin Asncrona

87

Figura 9. Comunicacin Sincrona Vs. Comunicacin

Envo no bloqueante (comunicacin asncrona): [1:8] El emisor contina al pasar el mensaje al ncleo. Envo bloqueante no fiable (comunicacin asncrona):

Asincrona

[1:2:7:8] El emisor espera a que el ncleo transmita por red el mensaje.

Envo

bloqueante

fiable

(comunicacin

asncrona):

[1:2:3:6:7:8]: El emisor espera a que el ncleo receptor recoge el mensaje.

Envo

bloqueante

explcito

(comunicacin

sncrona):

[1:2:3:4:5:6:7:8]: Idem al anterior, pero es la aplicacin receptora la que confirma la recepcin.

Peticin-Respuesta

(cliente/servidor)

[1:2:3:4:<servicio>:5:6:7:8]: Emisor espera a que el receptor procese la operacin. Respuesta puede servir de ACK. DESTINOS DE LOS MENSAJES Por los conceptos de redes sabemos que en los protocolos de internet, los mensajes son enviados a direcciones construidas por pares (direccin de internet, puerto local). Un puerto local es el destino del mensaje dentro de un computador, especificado con un nmero entero. Un puerto tiene exactamente un receptor pero puede tener muchos emisores. Los procesos pueden utilizar mltiples puertos para recibir los mensajes. Cualquier proceso que conozca el nmero de puerto apropiado puede enviarle un mensaje. Generalmente los servidores hacen pblico sus nmeros de puerto para que sean utilizados por los clientes. Destino = IP + puerto Destino de los Mensajes.

88

Ideal conceptualmente, pues solo hay 2 mensajes: envi y recepcin. Existen buffers para los mensajes. Envio => Colocar mensajes en buffer. Recepcin => Sacar mensajes en buffer. Sincronia => bloqueo Asincrona => no hay bloqueo en el envi. Uso de threads (hilos).

Entonces tenemos dos formas de comunicacin de procesos, enviando paquetes a travs de los protocolos UDP y TCP, ambas utilizan la abstraccin de sockets (conectores) para la comunicacin, estas se encargan de proporcionar los puntos extremos de la comunicacin entre procesos. COMUNICACIN EN CLIENTE SERVIDOR Esta forma de comunicacin esta orientada a soportar los roles y el intercambio de las interacciones tpicas cliente-servidor. En el caso normal, la comunicacin peticin - respuesta es sncrona, ya que el proceso cliente se bloquea hasta que llega la respuesta del servidor. Esta comunicacin tambin puede ser fiable debido a que la respuesta del servidor es en efecto un acuse de recibo para el cliente. Dos roles diferentes en la interaccin Cliente: Solicita servicio. Peticin: Operacin + Datos Servidor: Proporciona servicio. Respuesta: Resultado

Figura 10. Comunicacin peticion respuesta cliente -

Modelo con proxy o cache.

servidor

89

Tres roles diferentes en la interaccin Cliente: Solicita servicio. Servidor: Proporciona servicio. Proxy: Intermediario (si tiene memoria se denomina cach)

Figura 11. Comunicacin peticion respuesta con proxy

Modelo Multicapa Servidor puede ser cliente de otro servidor, Tpico en aplicaciones web: Presentacin + Lgica de negocio + Acceso a datos En Microsoft: ASP + COM + ADO En Java: JSP + EJB + JDBC

Figura 12. Comunicacin peticion respuesta Servidor - Servidor

Los modelos de comunicacin basados en cliente-servidor con paso de mensajes responden al esqueleto:

90

Figura 13. Esqueleto de la comunicacin cliente Servidor con paso de mensajes 8

COMUNICACIN EN GRUPO El intercambio de mensajes entre iguales no es mejor modelo para la comunicacin entre un proceso y un grupo de procesos, como por ejemplo se da en el caso de un servicio implementado por varios procesos en diferentes computadores, quizs para proporcionar tolerancia a fallos o mejorar la disponibilidad. Resulta mas apropiada una operacion multidifusin, esta es una operacin que enva un nico mensaje desde un proceso a cada uno de los miembros de un grupo de procesos, normalmente de modo que la pertenencia al grupo resulte transparente para el emisor. La comunicacin en grupo Provee confiabilidad, disponibilidad de servicios desde la perspectiva de replicacin, la operacin ms apropiada para comunicar un mensaje a un grupo es el multicasting y la comunicacin debe ser hecha de forma transparente Posibles usos en los sistemas distribuidos: Uso de datos replicados: actualizaciones mltiples. Uso de servicios replicados. Operaciones colectivas en clculo paralelo. La implementacin depende de si la red proporciona multicast, Si no, se implementa enviando N mensajes Un proceso puede pertenecer a varios grupos, en el cual existe una direccin de grupo que los distingue a cada uno. El grupo suele tener carcter dinmico Se pueden incorporar y retirar procesos del grupo

Gestin de pertenencia debe coordinarse con la comunicacin. Modelos de grupos: Grupo abierto. Proceso externo puede mandar mensaje al grupo
91

8.1

Suele usarse para datos o servicios replicados

Grupo cerrado.

Slo procesos del grupo pueden mandar mensajes. Suele usarse en procesamiento paralelo (modelo

peer-to-peer) Atomicidad O reciben todos los procesos el mensaje o ninguno Orden de recepcin de los mensajes Tres alternativas:

Orden FIFO: Los mensajes de una misma fuente No hay ninguna garanta sobre mensajes de distintos Ordenacin causal: Si entre los mensajes enviados por

llegan a cada receptor en el orden que son enviados. emisores

dos emisores existe una posible relacin causa-efecto, todos los procesos del grupo reciben primero el mensaje causa y despus el mensaje efecto. entrega Concepto de causalidad se estudia en captulo Sincronizacin

Si no hay relacin, no se garantiza ningn orden de

Ordenacin total: Todos los mensajes (de varias fuentes)

enviados a un grupo son recibidos en el mismo orden por todos los elementos. ACTIVIDAD

Un servidor crea un puerto que utiliza para recibir peticiones de sus clientes. Discuta los problemas de diseo concernientes a las relaciones entre el nombre de ese puerto y los nombres utilizados por los clientes.

Resulta til que un puerto tenga varios receptores?

92

RESUMEN Los protocolos peticin-respuesta que se puede construir un protocolo especfico para sistemas distribuidos efectivo basndose en datagramas UDP. El mensaje de respuesta se considera como un reconocimiento del mensaje de peticin, evitando de este modo las sobrecargas de los reconocimientos adicionales. El protocolo se puede hacer mas fiable si fuera necesario. Tal como es, no existe garanta de que el envio del de un mensaje de peticin desencadene la ejecucion de un mtodo, para algunas aplicaciones esto puede ser suficiente, pero se puede conseguir una fiabilidad adicional haceindo uso de delas identificaciones de los mensajes y de la retransmisin de los mensajes, de modo que nos aseguremos que los mtodos serna ejecutados. Otras aplicaciones necesitan que los mensajes de respuesta sean transmitidos sin tener que volver a ejecutar el mtodo solicitado. Esto se puede conseguir utilizando un historial. Esto demuestra que resulta una buena idea construir distintos protocolos que se ajusten alas necesidades de diferentes clase de aplicaciones en lugar de construir un nico protocolo superfiable para uso general. Los mensajes de mutidifusion se utilizan en la comunicacin entre lo miembros de un grupo de procesos.el protocolo de multidifusin IP proporciona un servicio de multidifusin tanto para redes de rea local como para internet. BIBLIOGRAFIA RECOMENDADA
o

1ST

INTERNATIONAL

WORKSHOP

ON

AGENTS

FOR

AUTONOMIC COMPUTING (AAC 2008) June 6, 2008 in Chicago, http://www.iids.org/aac2008/ o 2008 SIWN International Conference on Selforganization and Selfmanagement in Computing and Communications, Glasgow, UK, 2224 July 2008 http://siwn.org.uk/2008/

93

The

Second

International

Conference

on

Autonomic September

Computing

and

Communication

Systems,

2325, 2008, TURIN, http://www.autonomics.eu/

o

George Colouris, Sistemas Distribuidos Conceptos y Diseo, Addison Wesley, Espaa 2001 http://www.cdk3.net/ Tanenbaum, Distributed Systems: Principles and

Paradigms, Prentice Hall, Mexico 2002. http://www.prenhall.com/divisions/esm/app/author_tanenb aum/custom/dist_sys_1/

o

Liu,

Distributed

Computing:

Principles

and

Applications, Addison Wesley, Mexico 2005 http://www.csc.calpoly.edu/~mliu/book/ AUTOEVALUACION FORMATIVA o Muestre un esquema de implementacin de un servidor mostrando el modo en que se utilizan las operaciones damePeticion y envaRespuesta por un servidor que crea un nuevo hilo para ejecutar cada peticin de un cliente. Indique el modo en que el servidor copiara la IdPeticion del mensaje de peticin en el mensaje de respuesta y como obtendr la direccin y el puerto cliente. o Describa un escenario en el cual un cliente pudiera recibir una respuesta de un llamado anterior.
o

Describa los modos en que los protocolos peticinrespuesta ocultan la heterogeneidad de los sistemas operativos y de las redes de computadores.

94

UNIDAD ACADMICA N 05

COMUNICACIN A BAJO NIVEL, SOCKETS

En este capitulo como el que sigue estn realcionados con el Middleware, este capitulo se centra en el como el Midleware y los programas de aplicacin pueden utilizar los protocolos de la capa de transporte de internet TCP y UDP. En este capitulo se presenta las caracteristicas de comunicacin entre procesos y discute UDP y TCP des punto de vista del programador, presentando la interfaz Java para estos dos protocolos. INDICADORES DE LOGRO Al terminar esta unidad el estudiante estar en condiciones de:

Definir, describir que es un socket Realizar operaciones con Sockets Crear sockets utilizando los protocolos TCP y UDP en java. Conocer e implementar el Protocolo de interfaz de aplicacion (api) de java para las direcciones de internet

COMUNICACIN A BAJO NIVEL, SOCKETS 1.1. Qu es un socket? Un socket es un extremo o un punto terminal de un canal de comunicacin entre dos procesos. Obviamente, para formar un canal de comunicacin se requieren dos sockets, a los cuales se les conoce como socket local y socket remoto. La comunicacin a travs de una conexin de sockets es bidireccional. Los sockets trabajan normalmente al nivel de transporte (en el caso de TCP/IP, sobre los protocolos TCP o UDP), aunque existen tambin los raw sockets que operan en la capa de red del modelo OSI (por ejemplo, dentro de la suite

95

de protocolos TCP/IP, los raw sockets se usan en programas basados en el protocolo ICMP, como es el caso del programa Ping). Una conexin de de red la entre dos procesos queda completamente definida por una asociacin, la cual es una quinteta formada siguiente manera: {protocolo, direccin_local, puerto_remoto} Un ejemplo de asociacin usando la suite de protocolos TCP/IP es el siguiente: 21} Con base en el concepto de asociacin, se puede definir un socket como una media-asociacin, la cual tiene dos posibles definiciones: {protocolo, direccin_local, proceso_local} {protocolo, direccin_remota, proceso_remoto}. A una media-asociacin tambin se le llama direccin de transporte. {tcp, 192.43.235.2, 1500, 192.43.235.6, proceso_local, direccin_remota,

Figura 1. Sockets y Puertos

1.2

Operaciones sobre Sockets

El principal objetivo de la interfaz de sockets es facilitar al programador el desarrollo de aplicaciones distribuidas. Casi todos los programadores estn familiarizados con el manejo de archivos por medio de las operaciones bsicas open-read-write-close. La interfaz de sockets intenta que la programacin en ambientes distribuidos se realice con las

96

mismas operaciones, slo que en lugar de actuar sobre un archivo actan sobre un punto terminal de un canal de comunicaciones (socket). De esta manera tenemos las siguientes analogas:

Figura 2. Tabla de operaciones en archivos Vs

1.3.

Operaciones en Sockets Tipos de sockets

Stream (SOCK_STREAM):

Orientado a conexin. Fiable, se asegura el orden de entrega de mensajes. No mantiene separacin entre mensajes (tamao variable). AF_INET se corresponde con el protocolo TCP.

Datagrama (SOCK_DGRAM): 1.4 Sin conexin. No fiable, no se asegura el orden en la entrega. Mantiene la separacin entre mensajes. AF_INET se corresponde con el protocolo UDP.

Raw (SOCK_RAW): Permite el acceso a los protocolos de mas bajo nivel como IP. Asignamiento de direcciones Cada socket debe tener asignada una direccin nica, esta son dependientes del dominio. Las direcciones se usan para:

Asignar una direccin local a un socket (bind). Especificar una direccin remota (connect o sendto).

97

 Se utiliza la estructura genrica de direccin: struct sockaddr mi_dir; Cada dominio usa una estructura especfica.

Uso de cast en las llamadas. Direcciones en AF_INET (struct sockaddr_in). Direcciones en AF_UNIX (struct sockaddr_un Creacin de un socket

1.5

La funcin socket crea uno nuevo: int socket(int dom,int tipo,int proto) Devuelve un descriptor de fichero (igual que un open de fichero). Dominio (dom): AF_XXX Tipo de socket (tipo): SOCK_XXX Protocolo (proto): Dependiente del dominio y del tipo:

0 elige el ms adecuado. Especificados en /etc/protocols.

El socket creado no tiene direccin asignada. 1.6 Transmisin de datos con streams Envo: Puede usarse la llamada write sobre el descriptor de socket.

int send(int s,char *mem,int tam,int flags) Devuelve el n de bytes enviados.

Recepcin: Puede usarse la llamada read sobre el descriptor de socket. int recv(int s,char *mem,int tam,int flags) Devuelve el n de bytes recibidos. Los flags implican aspectos avanzado como enviar o recibir datos urgentes (out-of-band).

98

1.7 Transferencia de datos con datagramas Envo:Figura 3. Proceso de transmision de datos con int sendto(int s,char *mem,int tam, int flags,struct sockaddr *dir, int *tam) Recepcin: int recvfrom(int s,char *mem,int tam, int flags,struct sockaddr *dir, int *tam) No se establece una conexin (connect/accept) previa. Para usar un socket para transferir basta con crear el socket y reservar la direccin (bind).
Streams

Figura 3. Proceso de transmision de datos con 2

PROTOCOLO DE INTERFAZ DE APLICACION (API) DE JAVA PARA LAS DIRECCIONES DE INTERNET Como los paquetes IP que subyacen a TCP y UDP se envan en direcciones internet, java proporciona una clase InetAddres, para representar las direcciones internet. Los usuarios de esta clase se refieren a los computadores por sus nombres de host en el servicio de nombres de dominio. 2.1. Comunicacin de datagramas UDP Un datagrama enviado por UDP se transmite desde un proceso emisor a un proceso receptor sin acuse de recibo ni reintentos. Si algo falla, el mensaje puede no llegar a su destino. Se

datagramas.

99

transmite un datagrama entre proceso cuando uno lo enva y el otro lo recibe, cualquier proceso que necesite enviar o recibir mensajes debe crear primero un conector asociado a una direccin de internet y a un puerto local. Un servidor enlazara su conector a un puerto de de servidor (uno que resulte conocido a los clientes de forma que puedan enviarle mensajes). Un cliente ligara su conector a cualquier puerto local libre. El mtodo recibe devolver, adems del mensaje, la direccin de internet y el puerto del emisor, permitiendo al receptor enviar la correspondiente respuesta. API java para datagramas UDP. La API java proporciona una comunicacin de datagramas por medio de dos clases: Datagrama Packet y DatagramaSocket.

Datagrama Packet: Esta clase proporciona un constructor que crea una instancia compuesta por una cadena de bytes que almacena el mensaje, la longitud del mensaje y la direccin internet y el nmero de puerto local del conector destino.
Cadena de bytes conteniendo el mensaje Longitud del mensaje. Direccin de internet Numero de puerto

Figura 3. Paquete del

Las

datagrama DatagramaPacket instancias de

podrn

ser

transmitidas entre procesos cuando uno la enva y el otro la recibe.

DatagramaSocket: Esta clase maneja conectores para enviar y recibir datagramas UDP. Proporciona un constructor que toma un numero de puerto como argumento, apropiado para los procesos que necesitan utilizar un puerto concreto. Tambin proporciona un constructor sin argumentos que permite que el sistema elija un puerto de entre los libres. Estos constructores pueden lanzar una excepcin SocketException si el puerto ya esta siendo usado o si se especifica un puerto reservado.

100

 Cdigo java de un cliente UDP enviando un mensaje a un servidor y recogiendo su respuesta: El cdigo muestra un programa de un cliente que crea un conector, enva un mensaje a un servidor en el puerto 6789, y despus espera una respuesta. Los argumentos para el mtodo main proporcionan un mensaje y el nombre del DNS de host del servidor. El mensaje se convierte en una cadena de bytes y el nombre DNS del host a la correspondiente direccin de internet. import java.net.*; import java.io.*; public class UDPClient{ public static void main(String args[]){ // args give message contents and server hostname DatagramSocket aSocket = null; try { aSocket = new DatagramSocket(); byte [] m = args[0].getBytes(); InetAddress aHost = InetAddress.getByName(args[1]); int serverPort = 6789; DatagramPacket request = new DatagramPacket(m, args[0].length(), aHost, serverPort); aSocket.send(request); byte[] buffer = new byte[1000]; DatagramPacket reply = new DatagramPacket(buffer, buffer.length); aSocket.receive(reply); System.out.println("Reply: " + new String(reply.getData())); }catch (SocketException e) {System.out.println("Socket: " + e.getMessage());

101

}catch (IOException e){System.out.println("IO: " + e.getMessage());} }finally {if(aSocket != null) aSocket.close();} } } Cdigo java de un servidor UDP recibiendo peticiones y las devuelve al cliente en forma repetitiva. El cdigo muestra el programa para el correspondiente servidor el cual crea un conector ligado a su puerto de servidor 6789 y entonces espera repetidamente a los mensajes de peticin de los clientes, a los cuales responde mandando de vuelta el mismo mensaje. import java.net.*; import java.io.*; public class UDPServer{ public static void main(String args[]){ DatagramSocket aSocket = null; try{ aSocket = new DatagramSocket(6789); byte[] buffer = new byte[1000]; while(true){ DatagramPacket request = new DatagramPacket(buffer, buffer.length); aSocket.receive(request); DatagramPacket reply = new DatagramPacket(request.getData(), request.getLength(), request.getAddress(), request.getPort()); aSocket.send(reply); }

102

}catch (SocketException e) {System.out.println("Socket: " + e.getMessage()); }catch (IOException e) {System.out.println("IO: " + e.getMessage());} }finally {if(aSocket != null) aSocket.close();} } } 2.2. Comunicacin de Streams TCP La API para el prtocolo TCP, proporciona la abstraccin de un flujo de bytes (stream) en el que pueden escribirse y leerse datos. La API para la construccin por streams supone que en el momento de establecer una conexin uno de ellos juega el papel de cliente y el otro juega de servidor, aunque despus se comuniquen de igual a igual. El rol del cliente implica la creacin de un conector, de tipo stream, sobre cualquier puerto y la posterior peticin de conexin con el servidor en su puerto de servicio. El papel del servidor involucra la creacin de un conector de escucha ligado al puerto de servicio y la espera de clientes que soliciten conexiones. El conector para escuchar mantiene una cola de peticiones de conexin. En el modelo de Sockets, cuando un servidor acepta una conexin, crea una nuevo conector para mantener la comunicacin con el cliente, mientras que se reserva el conector del puerto de servicio para escuchar las peticiones de conexin de otros clientes. El par de conestores el del cliente y el del servidor, se conectan por un par de streams, uno en cada direccin. Asi cada conector tiene su propio stream de entrada y de salida. Uno de los procesos del par puede enviar informacin al otro escribiendo en un stream de salida, y el otro puede obtener la informacin leyendo de su stream de entrada.

103

Cuando una aplicacin cierra un conector, indica que no va escribir nada mas en su stream de salida, cualquier dato que se encuentre en su buffer de salida ser enviado al otro extremo del stream y puesto en la cola del conector destino con una indicacin de que el stream ha sido roto. El proceso en el destino puede leer los datos en la cola, pero cualquier lectura despus de que la cola este vaca resultara una indicacin del final del stream. Cuando un proceso finaliza su ejecucin o falla, todos sus conectores se cierran y cualquier proceso que intente con l descubrir que la conexin se ha roto. Utilizacin del TCP Muchos de los servicios utilizados se ejecutan sobre conexiones TCP, con nmeros de puerto reservados. Entre ellos se encuentran los siguientes. HTTP: El protocolo de transferencia de Hipertexto se utiliza en la comunicacin entre un navegador y un servidor web. FTP: El protocolo de transferencia de archivos permite leer los directorios de un computador remoto y transferir los archivos entre los computadores de una conexin. Telnet: la herramienta Telnet proporciona acceso a un terminal en un computador remoto. SMTP: el protocolo simple de transferencia de de correo se utiliza para enviar correos electrnicos entre computadores. API Java para los Streams TCP La interfaz java para los Streams TCP est constituido por clases ServerSockets y Socket. ServerSocket: esta clase est diseada para ser utilizada por un servidor para crear un conector en el puerto de servidor que escucha las peticiones de conexin de los clientes. Su mtodo Accept toma una peticin connect de la cola, o si la cola esta vaca, se bloquea hasta que llega una peticin. El resultado de ejecutar accept es una instancia de socket, un

104

conector que da acceso a streams para comunicarse con el cliente. Socket: esta clase es utilizada por el par de procesos de una conexin. El cliente utiliza un constructor para crear un conector, especificando el nombre DNS de host y el puerto del servidor. Este constructor no solo crea el conector asociado con el puerto local, sino que tambin se conecta con el computador remoto especificado con el puerto indicado. Puede lanzar una excepcin UnknowException si el nombre de host no es correcto, o una exception IOEexception si se da un error de entrada y salida. La clase socket proporciona los mtodos getinputstream y getoutputstream para accesder a los streams asociados con un conector. Un cliente TCP realiza una conexin a un servidor, enva una peticin y recibe una respuesta El cdigo muestra un programa cliente donde se le da como argumento al mtodo main un mensaje y nombre DNS del host servidor. El cliente crea un conector ligado al nombre del de host y al y puerto salida 7896. Obtiene y DataInputStream y DataOuputStream delos streams de los conectores entrada respectivamente, entonces escribe el mensaje en su stream de salida y espera a leer la respuesta en el stream de entrada.
import java.net.*; import java.io.*; public class TCPClient { public static void main (String args[]) { // arguments supply message and hostname of destination Socket s = null; try{ int serverPort = 7896; s = new Socket(args[1], serverPort); DataInputStream in = new DataInputStream( s.getInputStream()); DataOutputStream out = new DataOutputStream( s.getOutputStream()); out.writeUTF(args[0]); // UTF is a string encoding see Sn 4.3 String data = in.readUTF();

105

System.out.println("Received: "+ data) ; }catch (UnknownHostException e){ System.out.println("Sock:"+e.getMessage()); }catch (EOFException e) {System.out.println("EOF:"+e.getMessage()); }catch (IOException e) {System.out.println("IO:"+e.getMessage());} }finally {if(s!=null) try {s.close();}catch (IOExceptione) {System.out.println ("close:"+e.getMessage());}} } }

Un Servidor TCP establece una conexin para cada cliente y les reenva peticiones. El cdigo muestra un programa servidor que en realiza la siguiente accin, abre un conecctor de servidor en su puerto de servicio 7896 y escucha las peticiones de conexin, connect, cuando llega una conexin crea un nuevo hilo para comunicarse con el cliente. El nuevo hilo crea un DataInputStream y un DtaOuputStream para los flujos de esntrada y salida de su conector y entonces a leer el mensaje del cliente y lo escribe de vuelta.
import java.net.*; import java.io.*; public class TCPServer { public static void main (String args[]) { try{ int serverPort = 7896; ServerSocket listenSocket = new ServerSocket(serverPort); while(true) { Socket clientSocket = listenSocket.accept(); Connection c = new Connection(clientSocket); } } catch(IOException e) {System.out.println("Listen :"+e.getMessage());} } } class Connection extends Thread { DataInputStream in; DataOutputStream out; Socket clientSocket; public Connection (Socket aClientSocket) { try { clientSocket = aClientSocket; in = new DataInputStream( clientSocket.getInputStream()); out =new DataOutputStream( clientSocket.getOutputStream()); this.start(); } catch(IOException e) {System.out.println("Connection:"+e.getMessage());}

106

} public void run(){ try { // an echo server String data = in.readUTF(); out.writeUTF(data); } catch(EOFException e) {System.out.println("EOF:"+e.getMessage()); } catch(IOException e) {System.out.println("IO:"+e.getMessage());} } finally{ try {clientSocket.close();}catch (IOException e) {/*close failed*/}} } } 3

REPRESENTACION EXTERNA Y EMPAQUETADO. La informacin almacenada dentro d elos programas de ejecucin se representa mediante estructuras de datos (por ejemplo, por conjuntos de objetos interrelacionados) mientras que la informacin transportada en los mensajes consiste en secuencias de bytes. Independientemente utilizada, las estructuras de de la forma de comunicacin datos deben ser apalanadas

(covertidas a una secuencia de bytes) antes de su transmisin y reconstruidas en el destino. Los tipos de datos primitivos transmitidos en los mensajes pueden tener valores de diferentes tipos, y no todos los computadores almacenan valores primitivos, tales como los enteros, en el mismo orden etc. Entonces para hacer posible que dos computadores puedan intercambiar datos se puede utilizar uno de los mtodos siguientes: Los valores se convierten a un formato externo acordado antes de la transmisin y se revierte al formato local en la recepcin, si los dos computadores son del mismo tipo y lo saben, se puede omitir la transformacin al formato externo. Los valores se transmiten segn el formato del emisor junto con una indicacin del formato utilizado, y el receptor los convierte si es necesario. Hay que hacer notar sin embargo que los bytes no son alterados durante la transmisin. Para soportar RMI o RPC. Al estndar acordado para la representacin de estructuras de datos y valores primitivos se denomina represetacion externa de datos.

107

ACTIVIDAD Utilice el cdigo de datagramas UDP (cliente-servidor), para hacer un prototipo que pruebe las condiciones en las que los datagramas son, en ocasiones desechados(concejo: el programa cliente debera ser capaz de variar el numero y el tamao de los mensajesque enva; el servidor debera detectar cuando se ha perdido un mensaje de un cliente en particular) RESUMEN Este capitulo muestra que existen dos alternativas a la hora de construir los bloques con los que elaborar los protocolos de internet. Existe una interesante relacin de compromiso entre estos dos protocolos: UDP proporciona la posibilidad de un simple paso de mensajes que adolece de fallos de omisin pero lleva asociada penalizacin en las prestaciones. En el otro lado, en buenas condiciones, TCP garantiza la entrega de los mensajes pero a cambio de tener mensajes adicionales y una mayor latencia y costos de almacenamiento. La interfaz del programa de aplicacin para UDP proporciona una abstraccin del tipo de paso de mensajes, la forma mas simple de comunicacin entre procesos. Esto hace que el proceso emisor pueda transmitir un mensaje simple al proceso receptor. Los procesos independientes que contienen estos mensajes se llaman datagramas. Tanto en Java como en cada API UNIX, el emisor especifica el destino utlizando un zocalo , conector o socket(una referencia indirecta a un puerto en particular utlizada por el proceso destino en el computador destino) La interfaz del programa de aplicacin de TCP proporciona la abstraccin de un flujo (stream) de dos direcciones enrte pares de procesos. La informacin intercambiada consiste en un

108

stream de datos sin limites entre mensajes. Los streams son un bloque bsico para la construccin de la comunicacin productor consumidor. Un productor y un consumidor forman un par de procesos en los cuales el papel del primero es producir tems de datos y el papel del segundo es consumir es consumirlos. Los tems de datos enviados por el productor al consumidor se colocan en una cola a su llegada hasta que el consumidor este en disposicin de recibirlos. El consumidor debe esperar cuando no hay datos disponibles y el productor debe esperar si se llena el almacenamiento utilizado para guardar la cola de los Items. BIBLIOGRAFIA RECOMENDADA
o

George Colouris, Sistemas Distribuidos Conceptos y Diseo, Addison Wesley, Espaa 2001 http://www.cdk3.net/ Tanenbaum, Distributed Systems: Principles and

Paradigms, Prentice Hall, Mexico 2002. http://www.prenhall.com/divisions/esm/app/author_tanenb aum/custom/dist_sys_1/

o

Liu,

Distributed

Computing:

Principles

and

Applications, Addison Wesley, Mexico 2005 http://www.csc.calpoly.edu/~mliu/book/

109

AUTOEVALUACION FORMATIVA
o

Modifique el cdigo de Streams TCP de modo que el cliente obtenga de forma repetida una lnea del usuario y la escriba en el flujo que el servidor leera repetidamente, imprimiendo el resultado de la lectura. Compare los datos enviados utilizando un datgrama UDP y un stream.

o Utilice el cdigo de datagrama UDP para construir

un

programa cliente que lea repetidamente una lnea de entrada del usuario, la envie a un servidor en un datagrama UDP. Y entonces reciba un mensaje del servidor. El cliente asociara un tiempo de espera limite con su conector, de modo qe pueda informar al usuario cuando el servidor no responda.
o

Utilice el cdigo de datagrama UDP, para probar el efecto causado sobre el emisor cuandoel receptor se cae y viceversa.

110

UNIDAD ACADMICA N 06

OBJETOS DISTRIBUIDOS E INVOCACION REMOTA

Los modelos de programacin para aplicaciones distribuidas son aquellas que se componen de programas cooperantes corriendo en los procesos distintos, tales programas necesitan ser capaces de invocar operaciones entre otros procesos, que por lo general residen en otros computadores diferentes. Para lograr esto algunos modelos de programacin familiares han sido extendidos para aplicarlos a los programas distribidos. INDICADORES DE LOGRO Al terminar esta unidad el estudiante estar en condiciones de: Definir, describir objetos remotos Describir e impementar el llamado a procesos remotos (RPC). Describir e impementar Invocacion a mtodos Remotos (RMI).

El primero y quizs el mas conocido fue la extensin del modelo de llamada a procedimiento convencional al modelo de llamada a procedimiento remoto (RPC), que permite a programas cliente llamar a procedimientos de programas servidores lanzados en procesos separados y generalmente en computadores distintos al cliente.

Recientemente el modelo de programacin basado en objetos ha sido extendido para permitir que los objetos de diferentes procesos se comuniquen uno con otro por medio de ina invocacin a un mtodo remoto (RMI). RMI es una extensin de la invocacin a mtodos locales que permite que un objeto que vive en un proceso invoque los mtodos de un objeto que reside proceso. en otro

111

El modelo de programacin basado en eventos permite a los objetos recibir notificaciones de los eventos que ocurren en otros objetos en los que se ha mantenido el inters. Este modelo ha sido extendido para permitir escribir programas distribuidos basados en eventos.

Notese que usamos el termino RMI para referirnos a una invocacin de un mtodo remoto de forma genrica. No debemos confundir con ejemplos particulares de invocacin de un mtodo remoto como Java RMI. Idea Central: Cmo hacer para que objetos remotos se comuniquen entre s?
COMUNICACION DE OBJETOS REMOTOS

Figura 1. Comunicacin de Objetos remotos

1. MIDDLEWARE Al software que proporciona un modelo de programacin sobre bloques bsicos arquitectnicos, a saber procesos y paso de mensajes se le llama middleware. La capa midlleware emplea protocolos basados en mensaje entre procesos para proporcionar abstracciones de un nivel mayor, tales como invocaciones remotas y eventos.
Aplicaciones, servicios. RMI y RPC

Protocolo petici respuesta Empaquetado y representaci externa de datos UDP y TCP

Capas Middleware

112

Middleware capa que oculta los aspectos de comunicacin, paso de mensajes y notificacin de eventos, en algunas formas pretende modelar el sistema como si fuese local y no distribuida, y la vez que los componentes del programa estn escritos en diferentes lenguajes de programacin teniendo en cuenta lo siguientes criterios:

Figura 2. Capas middleware

Transparencia Frente a la ubicacin Protocolos de comunicacin Hardware de los Computadores y empaquetados de datos Sistemas Operativos Uso de diversos lenguajes de programacin mayora de los lenguajes de programacion unos con modernos otros. La

2. INTERFACES La proporciona medios para organizar un programa en conjuntos de modulos llamadas que puedan comunicarse comunicacin entre los modulos se puede realizar mediante a procedimientos entre los modulos accediendo directamente a las variables de otro modulo. Para controlar las interacciones posibles entre los modulos, se define explcitamente una interfaz para cada modulo, de tal manera que oculte toda la informacin excepto aquella que se haga disponible a travs de su interfaz. De este modo, mientras la interfaz usuarios. Un programa puede organizarse en mdulos que se comunican entre s, cada mdulo posee su propia interfaz (Nombre+argumentos+resultado), el algoritmo del mdulo puede variar pero no su interfase. permanezca inalterada, la implementacin podr cambiar sin afectar a los

113

Figura 3. 2.1. Interfaces en los sistemas Modulos e distribuidos

En los sistemas distribuidos las interfaces tienen las siguientes caractersticas.

Interfaces

Cada proceso posee su propio espacio de memoria, Los mdulos locales corren bajo un mismo proceso, Mdulos de dos procesos distintos no pueden acceder a las variables del otro.

Los tipos de datos punteros slo estn restringidos al proceso local El paso de variables de argumento y de resultados (respuesta) no puede ser por referencia Las Interfaces empleadas en el modelo cliente servidor para RPC, y modelo de objetos distribuidos para RMI. Interfaces de servicio. En el modelo cliente servidor, cada servidor provee un conjunto de mdulos disponibles que entregarn dicho servicio Ejemplo: Servidor de archivos x Leer(archivo) Escribir(archivo,x) Interfaces Remotas. Cada objeto remoto pone a disposicin algunos o todos los mtodos para que sean accesibles por otros objetos.Al conjunto de esos mtodos accesibles, se les llama interfaz remota. Lenguajes de Definicin de Interfaces IDL Corresponde al lenguaje que hace un paralelo o traduccin de los tipos de datos de los argumentos y de los resultados,

2.2.

114

traduciendo tipos de datos remotos a tipos de datos locales. En particular, permite definir interfaces entre los objetos remotos. Lenguajes de definicin de interfaces IDL. permite escribir interfaces correspondientes a objetos escritos en diferentes lenguajes (C, C++, Java, COBOL,..) Ejemplo : lenguaje de definicin de interfaz de CORBA // In file Person.idl en IDL de CORBA struct Person { string name; string place; long year; }; interface PersonList { readonly attribute string listname; void addPerson(in Person p) ; void getPerson(in string name, out Person p); long number(); }; CORBA IDL admite herencia mltiple a nivel de interfaces: Ejemplo: //interface Impresora interface Impresora { ... }; interface ServidorImpresoras { void registrar_impresora(in Impresora prn, in string nombre); Impresora buscar_impresora(in string nombre); } 3. COMUNICACIN ENTRE OBJETOS DISTRIBUIDOS
3.1.

Modelo de Objetos Locales. Un programa orientado al objeto, por ejemplo Java o C++, consta de un conjunto de objetos que interaccionan entre

115

ellos, cada uno de los cuales consiste en un conjunto de datos y un conjunto de mtodos. Un objeto se comunica con otro objeto invocando a sus mtodos, generalmente pasndole argumentos y recibiendo resultados. Los objetos pueden encapsular sus datos y el cdigo de sus mtodos. Algunos lenguajes, por ejemplo Java y C++, permiten que los programadores definan objetos en los que las variables de sus instancias estn accesibles de modo directo. Pero para su uso en un sistema distribuido de objetos, los datos de un objeto solo deberan ser accesibles mediante sus mtodos.

Referencia a Objetos: Forma de acceder a un objeto Interfaces: Mtodos (argumentos, resultados y excepciones) Acciones (mensajes locales): Informa acerca del estado del receptos, Cambia el estado del receptos, Puede afectar a otros objetos (indirectamente).

Excepciones: Tratamiento de errores separados del cdigo principal del mdulo Liberacin de Memoria: Cuando un objeto deja de ser accesible

3.2. Objetos Distribuidos En el paradigma de la programacin basada en objetos, el estado de un programa se encuentra fraccionado en partes separadas, cada uno de los cuales esta asociada con un objeto. Dado que lso programas basados en objetos estn fraccionados lgicamente, la distribucin fsica de los objetos en deiferentes procesos o computadores de un sistema distribuido es una excepcin natural. Un sistema COMUNICACI N ENTRE OBJETOS DISTRIBUIDOS podra estar compuestos de un conjunto de objetos locales, ese mismo sistema podra esparcir sus objetos en computadores o procesos diferentes, bajo este esquema, algunos objetos podran ser vistos como objetos

116

clientes y mientras que otros como objetos servidores (Arquitectura Cliente-Servidor).

3.3. Modelo de objetos distribuidos. Es posible implementar objetos locales que representen a los
Figura 4. Comunicacin entre objetos

objetos remotos, lo que facilita la programacin de este tipo distribuidos de sistema (Modelo Cliente-Servidor con Proxy).
3.3.1.

Referencia a objetos remotos. Se debe poseer referencias nicas a objetos remotos. Paso de referencia de objetos remotos como parmetros o como resultado de las invocaciones.

Figura 5. Referencia a objetos 3.3.2. remotos Interfaces Remotas.

Solo pone a disposicin mtodos remotos, Se puede utilizar un IDL, CORBA usa IDEL, JAVA utiliza la misma forma de definir interfaces en un contexto local, Ambos soportan herencias mltiples para sus interfaces.

117

Figura 6. Interfaces remotas

Figura 3. Modulos e Interfaces

118

3.3.3.

Acciones en un Sistema de Objetos Distribuidos. Como en el caso local, las acciones de un objeto remoto, puede afectar a otros objetos tambin remotos. En cada caso se emplea RMI, para tener acceso a los objetos remotos.

Figura 7. Acciones de un objeto 3.3.4. remoto Compactacin Automtica memoria en un

sistema de objetos distribuido Si el lenguaje lo permite, la compactacin ocurre localmente (caso lenguaje Java). Si no los diferentes objetos debieran colaborar para detectar referencias no accesibles para compactar la memoria disponible 3.3.5. Excepciones Cada objeto debiera manejar, adems de los errores locales, aquellos errores propios de un ambiente distribuidos. Fallas en la Red y Fallas en el objeto remoto 3.4. Cuestiones de Diseo sobre RMI
3.4.1.

Semntica de la invocacin RMI. Un objeto local es invocado slo una vez pero no es as necesariamente con un objeto distribuido. Reenvo del mensaje de peticin (reintento) Filtrado de mensajes duplicados Reenvo de mensajes de resultados

119

Figura 8. Invocaciones 3.4.1.1.

Invocacin Pudiera ser: Un mtodo se invoca solamente una vez, despus de un time out no se reintenta Es til en aplicacin donde se puede tolerar esos tipos de fallos: Fallo por omisin de la invocacin o de la respuesta

semanticas

Fallo del servidor donde reside el mtodo remoto

3.4.1.2.

Invocacin Al menos una vez: A menos que reciba una respuesta o una excepcin, reenva el mensaje de invocacin. Fallo por cada del servidor

Fallo producto invocar ms de una vez un mtodo (pude generar resultados errneos.

Aceptable si la invocacin a un mtodo es idempotente (si se activa ms de una vez produce los mismos resultados, ejemplo: saldo de una cuenta)
3.4.1.3.

Invocacin Mximo una vez: El proceso enva slo un mensaje de invocacin al mtodo remoto, Recibe una respuesta o una excepcin. Es necesario considerar todos los fallos posibles para enmascararlos.

120

3.4.2.

Transparencia. Semntica de invocacin, Ubicacin, Empaquetado, Paso deMensaje, Recuperacin ante fallos, Latencia es mayor al invocar un objeto remoto, Ante una invocacin fallida, construir mecanismos para restaurar el estado del objeto remoto

4. IMPLEMENTACIN RMI En una invocacin de mtodo remoto estn involucrados varios objetos y modulos separados. Como se muestra en la figura en la que un objeto A del nivel de aplicacin invoca a unmetodo en un objeto remoto B del nivel de aplicacin para el cual dispone de una referencia de objeto remoto. Observamos los papeles de cada uno de los componentes mostrados en la figura, tratando promero con los modulos de comunicacin y referencias remotas y despus con el software RMI que se ejecuta en ellas.

Figura 9. Invocacion a metodos remotos (RMI) 4.1.

Modulo de Comunicacin:

Implementa en el envo de mensajes de peticin y mensaje remotos (RMI) de respuesta entre objetos remotos. Hace el protocolo request-reply y utiliza el tipo de msg, reqId y el objId a invocar.

Figura 9. Invocacion a metodos

Figura 10. Modulo de comunicacion 121

4.2.

Modulo de Referencias Remotas: Traduce referencias locales y remotas, Utiliza una tabla de referencias de mtodos locales y mtodos remotos, Los objetos remotos son registrados en el servidor, y el proxy correspondiente, en la tabla local. Un mensaje de respuesta puede contener una referencia a un objeto remoto, sta referencia se registrar en la tabla local El software de RMI (capa RMI) Este consiste en una capa de software entre los objetos del nivel de aplicacin y los modulos de comunicacin y de referencia remota. Proxy : Representa al objeto remoto, redirigiendo mensajes de invocacin y entregando resultados o excepciones.Esqueleto del objeto remoto Distribuidor del mensaje de peticin/respuesta

4.3.

5. CASO DE ESTUDIO: RMI DE JAVA. El sistema de Invocacin Remota de Mtodos (RMI) de Java permite a un objeto que se est ejecutando en una Mquina Virtual Java (VM) llamar a mtodos de otro objeto que est en otra VM diferente. Nota: RMI proporciona comunicacin remota entre programas escritos en Java. Si unos de los programas est escrito en otro lenguaje, deberemos considerar la utilizacin de IDL en su lugar. 5.1. Aplicaciones RMI de Java Las aplicaciones RMI normalmente un servidor y comprenden un cliente. dos Una programas separados:

aplicacin servidor tpica crea un montn de objetos remotos, hace accesibles unas referencias a dichos objetos remotos, y espera a que los clientes llamen a estos mtodos u objetos remotos. Una aplicacin cliente tpica obtiene una referencia

122

remota de uno o ms objetos remotos en el servidor y llama a sus mtodos. RMI proporciona el mecanismo por el que se comunican y se pasan informacin del cliente al servidor y viceversa. Cuando es una aplicacin algunas veces nos referimos a ella como Aplicacin de Objetos Distribuidos. Las aplicaciones de objetos distribuidos necesitan Localizar Objetos Remotos Las aplicaciones pueden utilizar uno de los dos mecanismos para obtener referencias a objetos remotos. Puede registrar sus objetos remotos con la facilidad de nombrado de RMI rmiregistry. O puede pasar y devolver referencias de objetos remotos como parte de su operacin normal. Comunicar con Objetos Remotos Los detalles de la comunicacin entre objetos remotos son manejados por el RMI; para el programador, la comunicacin remota se parecer a una llmada estndard a un mtodo Java. Cargar Bytecodes para objetos que son enviados. Como RMI permite al llamador pasar objetos Java a objetos remotos, RMI proporciona el mecanismo necesario para cargar el cdigo del objeto, as como la transmisin de sus datos.

Figura 11. Aplicacin RMI de java

123

La figura muestra una aplicacin RMI distribuida que utiliza el registro para obtener referencias a objetos remotos. El servidor llama al registro para asociar un nombre con un objeto remoto. El cliente busca el objeto remoto por su nombre en el registro del servidor y luego llama a un mtodo. Esta ilustracin tambin muestra que el sistema RMI utiliza una servidor Web existente para cargar los bytecodes de la clase Java, desde el servidor al cliente y desde el cliente al servidor, para los objetos que necesita. 5.1.1. Ventajas de la Carga Dinmica de Cdigo Una de las principales y nicas caractersticas de RMI es la habilidad de descargar los bytecodes (o simplemente, cdigo) de una clase de un objeto si la clase no est definida en la mquina virtual del recibidor. Los tipos y comportamientos de un objeto, anteriormente slo disponibles en una sla mquina virtual, ahora pueden ser transmitidos a otra mquina virtual, posiblemente remota. RMI pasa los objetos por su tipo verdadero, por eso el comportamiento de dichos objetos no cambia cuando son enviados a otra mquina virtual. Esto permite que los nuevos tipos sean introducidos en mquinas virtuales remotas, y as extender el comportamiento de una aplicacin dinmicamente. El ejemplo del motor de clculo de este captulo utiliza la capacidad 5.1.2. de RMI para introducir un nuevo comportamiento en un programa distribuido. Interfaces, Objetos y Mtodos Remotos al igual que otras aplicaciones Java, est Una aplicacin distribuida construida utilizando RMI de Java, compuesta por interfaces y clases. Los interfaces definen mtodos, mientras que las clases implementan los mtodos definidos en los interfaces y, quizs, tambin definen algunos mtodos adicionales. En una aplicacin

124

distribuida, se asume que algunas implementaciones residen en diferentes mquinas virtuales. Los objetos que tienen mtodos que pueden llamarse por distintas mquinas virtuales son los objetos remotos. Un objeto se convierte en remoto implementando un interface remoto, que tenga estas caractersitcas. Un interface remoto desciende del interface java.rmi.Remote. Cada mtodo del interface declara que lanza una java.rmi.RemoteException adems de cualquier excepcin especfica de la aplicacin. El RMI trata a un objeto remoto de forma diferente a como lo hace con los objetos no-remotos cuando el objeto es pasado desde una mquina virtual a otra. En vez de hacer una copia de la implementacin del objeto en la mquina virtual que lo recibe, RMI pasa un stub para un objeto remoto. El stub acta como la representacin local o proxy del objeto remoto y bsicamente, para el llamador, es la referencia remota. El llamador invoca un mtodo en el stub local que es responsable de llevar a cabo la llamada al objeto remoto. Un stub para un objeto remoto implementa el mismo conjunto de interfaces remotos que el objeto remoto. Esto permite que el stub sea tipado a cualquiera de los interfaces mtodos lo recibe. 5.1.3. Crear Aplicaciones Distribuidas utilizando RMI Cuando se utiliza RMI para desarrollar una aplicacin distribuida, debemos seguir estos pasos generales. que el objeto en un remoto implementa. remoto Sin embargo, esto tambin significa que slo aquellos definidos interface estn disponibles para ser llamados en la mquina virtual que

125

Disear e implementar los componentes de nuestra aplicacin distribuida. Compilar los Fuentes y generar stubs. Hacer las clases Accesibles a la Red. Arrancar la Aplicacin.

Construir un Motor de Clculo Genrico

5.1.4.

Disear e implementar los componentes de

nuestra aplicacin distribuida. Primero, decidimos la arquitectura de nuestra aplicacin y determinamos qu componentes son objetos lcoales y cuales deberan ser accesibles remotamente. Este paso incluye.

Definir remoto

los

Interfaces los

Remotos. que

Un

interface ser la la

especifica los diseo

mtodos

pueden no es

llamados remotamente por un cliente. Los clientes programan Parte del interfaces de dichos remotos, interfaces implementacin de las clases de dichos interfaces. determinacin de cualquier objeto local que sea utilizado como parmetro y los valores de retorno de esos mtodos; si alguno de esos interfaces o clases no existen an tambin tenemos que definirlos.

Implementar los Objetos Remotos. Los objetos remotos deben implementar uno o varios interfaces remotos. La clase del objeto remoto podra incluir implementaciones remotos) y otros de otros interfaces (que (locales o mtodos slo estarn

disponibles localmente). Si alguna clase local va a ser utilizada como parmetro o cmo valor de retorno de alguno de esos mtodos, tambin debe ser implementada.

126

Implementar los Clientes. Los clientes que utilizan objetos remotos pueden ser implementados despus de haber definido los interfaces remotos, incluso despus de que los objetos remotos hayan sido desplegados.

5.1.5.

Compilar las Fuentes y Generar stubs. Este es un proceso de dos pasos. En el primer paso, se utiliza el compilador javac para compilar los ficheros fuentes de Java, los cuales contienen las implementaciones de los interfaces remotos, las clases del servidor, y del cliente. En el segundo paso es utilizar el compilador rmic para crear los stubs de los objetos remotos. RMI utiliza una clase stub del objeto remoto como un proxy en el cliente para que los clientes puedan comunicarse con un objeto remoto particular.

5.1.6.

Hacer accesibles las Clases en la Red.

En este paso, tenmos que hacer que todo - los ficheros de clases Java asociados con los interfaces remotos, los stubs, y otras clases que necesitemos descargar en los clientes - sean accesibles a travs de un servidor Web. 5.1.7. Arrancar la Aplicacin. Arrancar la aplicacin incluye ejecutar el registro de objetos remotos de RMI, el servidor y el cliente. El resto de este captulo muestra cmo seguir estos pasos para crear un motor de clculo. 5.1.8. Construir un Motor de Clculo Genrico Esta seccin se enfoca a una sencilla pero potente aplicacin distribuida llamada motor de clculo. Este motor de clculo es un objeto remoto en el servidor que toma tareas de clientes, las ejecuta, y devuelve los resultados. Las tareas se ejecutan en la mquina en la que se est ejecutando el servidor. Este tipo de aplicacin distribuida podra permitir que un nmero de

127

mquinas clientes utilizaran una mquina potente, o una que tuviera hardware especializado. El aspecto novedoso del motor de clculo es que las tareas que ejecuta no necesitan estar definidas cuando se escribe el motor de clculo. Se pueden crear nuevas clases de tareas en cualquier momento y luego entregarlas el motor de clculo para ejecutarlas. Todo lo que una tarea requiere es que su clase implemente un interface particular. Por eso una tarea puede ser enviada al motor de clculo y ejecutada, incluso si la clase que define la tarea fue escrita mucho despus de que el motor de clculo fuera escrito y arrancado. El cdigo necesita conseguir que una tarea sea descargada por el sistema RMI al motor de clculo, y que ste ejecute la tarea utilizando los recursos de la mquina en la que est ejecutando el motor de clculo. El RMI carga dinmicamente el cdigo de las tareas en la mquina virtual del motor de clculo y ejecuta la tarea si tener un conocimiento anterior de la clase que implementa la tarea. Una aplicacin como sta que tiene la habilidad de descargar cdigo dinmicamente recibe el nombre de "aplicacin basada en comportamiento". Dichas aplicaciones son parte normalmente del mecanismo requieren bsico de infraestructuras que permitan agentes. Con RMI, dichas aplicaciones programacin distribuida de Java.
5.2.

Disear e implementar los componentes de nuestra aplicacin distribuida. Escribir un Servidor RMI El servidor del motor de clculo acepta tareas de los clientes, las ejecuta, y devuelve los resultados. El servidor est compuesto por un interface y una clase. El interface propociona la definicin de los mtodos que pueden ser

128

llamados desde el cliente. Esencialmente, el interface define lo que el cliente ve del objeto remoto. La clase proporciona la implementacin.
5.2.1.

Disear una Interface Remoto Interface Compute es el pegamento que conecta el cliente y el servidor. En el corazn del motor de clculo hay un protocolo que permite que se le puedan enviar trabajos, el motor de clculo ejecuta esos trabajos, y los resultados son devueltos al cliente. Este protocolo est expresado en interfaces soportados por el motor de clculo y por los objetos que le son enviados. Cada uno de los interfaces contiene un slo mtodo. El interface del motor de clculo Compute, permite que los
Figura 12. Interfaz motor, trabajos sean enviados al compute mientras que el

interface Task define cmo el motor de clculo ejecuta una tarea enviada. El interface compute.Compute define la parte accesible remotamente - el propio motor de clculo. Codigo interface remoto con su nico mtodo. package compute; import java.rmi.Remote; import java.rmi.RemoteException; public interface Compute extends Remote { Object executeTask(Task t) throws RemoteException; } Al extender el interface java.rmi.Remote, este interface se marca a s mismo como uno de aquellos mtodos que pueden ser llamados desde cualquier mquina virtual. Cualquier objeto que implemente este interface se convierte en un objeto remoto. Como miembro de un interface remoto, el mtodo executeTask es un mtodo remoto. Por lo tanto, el mtodo debe ser definido como capaz de lanzar una

129

java.rmi.RemoteException. Esta excepcin es lanzada por el sistema RMI durante una llamada a un mtodo remoto para indicar que ha fallado la comunicacin o que ha ocurrido un error de protocolo. La segunda interface necesitada por el motor de clculo define el tipo Task. Este tipo es utilizado como un argumento del mtodo executeTask del interface Compute. El interface compute.Task define la interface entre el motor de clculo y el trabajo que necesita hacer, proporcionando la forma de iniciar el trabajo. Cdigo tipo task package compute; import java.io.Serializable; public interface Task extends Serializable { Object execute(); } El interface Task define un slo mtodo, execute. Este mtodo devuelve un Object, y no tiene parmetros ni lanza excepciones. Como este interface no extiende Remote, el mtodo no necesita listar java.rmi.RemoteException en su clausula throws.
5.2.2.

Implementar una Interface Remoto La clase que implementa el interface Compute, implementa un objeto remoto. Esta clase tambin propociona el resto del cdigo que configura el programa servidor: un mtodo main que crea un ejemplar del objeto remoto, lo registra con la facilidad de nombrado, y configura un controlador de seguridad, la implementacin de la clase para un interface remoto debera al menos.

Declarar los Interfaces remotos que estn siendo implementados. Definir el constructor del objeto remoto. Proprorcionar una implementacin para cada mtodo remoto de cada interface remoto.

130

El servidor necesita crear e instalar los objetos remotos. Este proceso de configuracin puede ser encapsulado en un mtodo main en la propia clase de implementacin del objeto remoto, o puede ser incluido completamente en otra clase. El proceso de configuracin debera.

Crear e instalar un controlador de seguridad. Crear uno o ms ejemplares del objeto remoto. Registrar al menos uno de los objetos remotos con el registro de objetos remotos de RMI (a algn otro servicio de nombrado que utilice JNDI).

Cdigo motor de clculo. La clase engine.ComputeEngine implementa el interface remoto Compute y tambin incluye el mtodo main para configurar el motor de clculo. package engine; import java.rmi.*; import java.rmi.server.*; import compute.*; public class ComputeEngine extends UnicastRemoteObject implements Compute { public ComputeEngine() throws RemoteException { super(); } public Object executeTask(Task t) { return t.execute(); } public static void main(String[] args) { if (System.getSecurityManager() == null) { System.setSecurityManager(new RMISecurityManager()); } String name = "//localhost/Compute"; try { Compute engine = new ComputeEngine(); Naming.rebind(name, engine); System.out.println("ComputeEngine bound"); } catch (Exception e) {

131

System.err.println("ComputeEngine exception: " + e.getMessage()); e.printStackTrace(); } } } Declarando las Interfaces Remotos que estn siendo Implementados La clase que implementa el motor de clculo se declara como. public class ComputeEngine extends UnicastRemoteObject implements Compute Esta declaracin indica que la clase implementa el interface remoto Compute (y, por lo tanto, define un objeto remoto) y extiende la clase java.rmi.server.UnicastRemoteObject. Definir el Constructor La clase ComputeEngine tiene un nico constructor que no toma argumentos. public ComputeEngine() throws RemoteException { super(); } Nota: En el JDK 1.2, podramos indicar el puerto especfico que un objeto remoto utiliza para aceptar peticiones. Proporcionar una Implementacin para cada Mtodo Remoto La clase para un objeto remoto proporciona implementaciones para todos los mtodos remotos especificados en los interfaces remotos. El interface Compute contiene un slo mtodo remoto, executeTask, que se implementa de esta forma. public Object executeTask(Task t) { return t.execute();

132

} Pasar Objetos en RMI Los argumentos y los tipos de retorno de los mtodos remotos pueden ser de casi cualquier tipo Java, incluyendo objetos locales, objetos remotos y tipos primitivos. Ms precisamente, una entidad de cualquier tipo Java puede ser pasada como un argumento o devuelta por un mtodo remoto siempre que la entidad sea un ejemplar de un tipo que sea.

Un tipo primitivo de Java, un objeto remoto, o un objeto serializable lo que significa que implementa el interface java.io.Serializable

Estas son las reglas que gobiernan el paso y retorno de valores.

Los objetos remotos se pasan esencialmente por referencia. Una referencia a un objeto remoto es realmente un stub, que es un proxy del lado del cliente que implementa el conjunto completo de interfaces remotos que implementa el objeto remoto.

Los

objetos el

locales

son

pasados de

por

copia de

utilizando

macanismo

serializacin

objetos de Java. Por defecto, todos los campos se copian, excepto aquellos que estn marcados como static o transient. El comportamiendo de la serializacin por defecto puede ser sobrecargado en una bsica clase-por-clase. El mtodo main() del Servidor El mtodo ms complicado de la implementacin de ComputeEngine es el mtodo main. Este mtodo es utilizado para arrancar el ComputeEngine, y, por lo

133

tanto, necesita hacer la inicializacin necesaria para preparar el servidor para aceptar llamadas de los clientes. Este mtodo no es un mtodo remoto, lo que significa que no puede ser llamado desde otra mquina virtual que no sea la suya. Cmo el mtodo main se declara static, no est asociado con ningn objeto, sino con la clase ComputeEngine. Crear e Instalar un Controlador de Seguridad Lo primero que hace el mtodo main es crear e instalar un controlador de seguridad. ste protege los accesos a los recursos del sistema por parte de cdigo no firmado que se ejecute dentro de la mquina virtual. El controlador de seguridad determina si el cdigo descargado tiene acceso al sistema de ficheros local o puede realizar cualquier otra operacin privilegiada. Aqu temos el cdigo que crea e instala el controlador de seguridad. if (System.getSecurityManager() == null) { System.setSecurityManager(new RMISecurityManager());} Poner el Objeto Remoto a Disposicin de los Clientes Luego, el mtodo main crea un ejemplar de ComputeEngine. Esto se hace con la sentencia. Compute engine = new ComputeEngine(); Antes de que un llamador pueda invocar un mtodo de un objeto remoto, debe obtener una referencia al objeto remoto. Este puede hacerse de la misma forma que en que se obtiene cualquier otra referencia en un programa Java, que es obtenindolo como parte del valor de

134

retorno de un mtodo o como parte de una estructura referencia. La clase ComputeEngine crea un nombre para el objeto con la sentencia. String name = "//localhost /Compute"; Este nombre incluye el nombre del host localhost, en el que se estn ejecutando el registro y el objeto remoto, y un nombre Compute, que identifica el objeto remoto en el registro. Luego est el cdigo necesario para aadir el nombre al registro RMI que se est ejecutando en el servidor. Esto se hace despus (dentro del bloque try con la sentencia. Naming.rebind(name, engine); Una vez que el servidor se ha registrado en el registro RMI local, imprime un mensaje indicando que est listo para empezar a manejar llamadas, y sale del mtodo main. Como el programa entrega una referencia de ComputeEngine en el registro, ste es alcanzable por un cliente remoto (el propio registro!). El sistema RMI tiene cuidado de mantener vivo el proceso ComputeEngine. El ComputeEngine

de

datos

que

contenga

dicha

est

disponible

para

aceptar

llamadas y no ser reclamado hasta que. su nombre sea eliminado del registro, y ningn cliente remoto mantenga una pieza final de cdigo del mtodo

referencia al objeto ComputeEngine. La ComputeEngine.main maneja cualquier excepcin que pudiera producirse. 5.2.3. Crear un Programa Cliente

135

El motor de clculo es un bonito y sencillo programa ejecuta las tareas que le son enviadas. Los clientes del motor de clculo son ms complejos. Un cliente necesita llamar al motor de clculo, pero tambin tiene que definir la tarea que ste va a realizar. Nuestro ejemplo est compuesto por dos clases separadas. la primera clase ComputePi, busca y llama a un objeto Compute. La segunda clase Pi, implementa el interface Task y define el trabajo que va a hacer el motor de clcilo. El trabajo de la clase Pi es calcular el valor del nmero pi, con algn nmero de posiciones decimales. Como recordaremos, el interface no-remoto Task se define de esta forma. package compute; public interface Task extends java.io.Serializable { Object execute(); } El interface Task extiende java.io.Serializable por lo que cualquier objeto que lo implemente puede ser serializado por el sistema RMI y enviado a una mquina virtual remota como parte de una llamada a un mtodo remoto. Podramos haber elegido hacer que la implementacin de nuestra clase implementara los interfaces Task y Serializable, y hubiera tenido el mismo efecto. Sin embargo, el nico proposito del interface Task es permitir que las implementaciones de este interface sean pasadas a objetos Compute, por eso, una clase que implemente el interface Task no tiene sentido que tambin implemente el interface Serializable. Dado esto, hemos asociado explcitamente los dos interfaces en el tipo system, asegurando que todos los objetos Task sean serializables. El cdigo que llama a los mtodos del objeto Compute debe obtener una referencia a ese objeto, crear un

136

objeto Task, y luego pedir que se ejecute la tarea. Ms adelante veremos la definicin de la tarea Pi. Un objeto Pi se construye con un slo argumento, la precisin deseada en el resultado. El resultado de la ejecucin de la tarea es un java.math.BigDecimal que representa el nmero pi calculado con la precisin especificada. La clase cliente ComputePi. package client; import java.rmi.*; import java.math.*; import compute.*; public class ComputePi { public static void main(String args[]) { if (System.getSecurityManager() == null) { System.setSecurityManager(new RMISecurityManager()); } try { String name = "//" + args[0] + "/Compute"; Compute comp = (Compute) Naming.lookup(name); Pi task = new Pi(Integer.parseInt(args[1])); BigDecimal pi = (BigDecimal) (comp.executeTask(task)); System.out.println(pi); } catch (Exception e) { System.err.println("ComputePi exception: " + e.getMessage()); e.printStackTrace(); } } }

137

Al igual que el servidor ComputeEngine, el cliente empieza instalando un controlador de seguridad. Esto es necesario porque RMI podra descargar cdigo en el cliente. En este ejemplo, el stub ComputeEngine es descargado al cliente. Siempre que el RMI descargue cdigo, debe presentarse un controlador de seguridad. Al igual que el servidor, el cliente utiliza el controlador de seguridad proporcionado por el sistema RMI para este propsito. Despus de llamar al controlador de seguridad, el cliente construye un nombre utilizado para buscar un objeto remoto Compute. El valor del primer argumento de la lnea de comandos args[0], es el nombre del host remoto, en el que se estn ejecutando los objetos Compute. Usando el mtodo Naming.lookup, el cliente busca el objeto remoto por su nombre en el registro del host remoto. Cuando se hace la bsqueda del nombre, el cdigo crea una URL que especfica el host donde se est ejecutando el servidor. El nombre pasado en la llamada a Naming.lookup nombre pasado tiene la misma sntaxis URL que el a la llamada Naming.rebind que

explcamos en pginas anteriores. Luego, el cliente crea un objeto Pi pasando al constructor de Pi el segundo argumento de la lnea de comandos, args[1], que indica el nmero de decimales utilizados en el clculo. Finalmente, el cliente llama al mtodo executeTask del objeto remoto Compute. El objeto pasado en la llamada a executeTask devuelve un objeto del tipo java.math.BigDecimal, por eso el programa fuerza el resultado a ese tipo y almacena en resultado en la variable result. Finalmente el programa imprime el resultado.

138

Figura 13. Flujo de mensaje Flujo de mensajes entre el cliente ComputePi, rmiregistry, y el ComputeEngine.

el

Finalmente, echemos un vistazo a la clase Pi. Esta clase implementa el interface Task y clcula el valor del nmero pi con un nmero de decimales especificado. Desde el punto de vista de este ejemplo, el algoritmo real no es importante (excepto, por supuesto, para la fiabilidad del clculo). Todo lo importante es que el clculo consume numricamene muchos recursos (y por eso es el tipo que cosa que querramos hacer en un servidor potente). Aqu tenemos el cdigo de la clase Pi, que implementa Task. package client; import compute.*; import java.math.*; public class Pi implements Task { /** constantes utilizadas en el clculo de pi*/ private static final BigDecimal ZERO = BigDecimal.valueOf(0); private static final BigDecimal ONE = BigDecimal.valueOf(1); private static final BigDecimal FOUR = BigDecimal.valueOf(4); /** modo de redondeo utilizado durante el clculo*/ private static final int roundingMode = BigDecimal.ROUND_HALF_EVEN; /** nmero de dgitos tras el punto decimal*/ private int digits; /** * Construye una tarea para calcular el nemro pi * con la precisin especficada. */ public Pi(int digits) { this.digits = digits; } /** * Calcula pi. */ public Object execute() { return computePi(digits);
139

} /** * Calcula el valor de Pi con el nmero de decimales especificados. * El valor se calcula utilizando la frmula de Machin. * * pi/4 = 4*arctan(1/5) - arctan(1/239) * * y una poderoas serie de expansiones de arctan(x) * para una precisin suficiente. */ public static BigDecimal computePi(int digits) { int scale = digits + 5; BigDecimal arctan1_5 = arctan(5, scale); BigDecimal arctan1_239 = arctan(239, scale); BigDecimal pi = arctan1_5.multiply(FOUR).subtract(arctan1_239).multi ply(FOUR); return pi.setScale(digits, BigDecimal.ROUND_HALF_UP); } /** * Calcula el valor, en radianes, de la arcotangente de la * inversa del entero suministrado para el nmero de decimales. * El valor se calcula utilizando la poderosa serie de * expansiones de arcotangente. * arctan(x) = x - (x^3)/3 + (x^5)/5 - (x^7)/7 + * (x^9)/9 ... */ public static BigDecimal arctan(int inverseX, int scale) { BigDecimal result, numer, term; BigDecimal invX = BigDecimal.valueOf(inverseX); BigDecimal invX2 = BigDecimal.valueOf(inverseX * inverseX); numer = ONE.divide(invX, scale, roundingMode); result = numer; int i = 1; do { numer = numer.divide(invX2, scale, roundingMode); int denom = 2 * i + 1; term = numer.divide(BigDecimal.valueOf(denom), scale, roundingMode); if ((i % 2) != 0) {
140

result = result.subtract(term); } else { result = result.add(term); } i++; } while (term.compareTo(ZERO) != 0); return result; } } La caracterstica ms interesante de este ejemplo es que el objeto Compute no necesita una definicin de la clase Pi hasta que se le pasa un objeto Pi como un argumento del mtodo executeTask. Hasta este punto, el cdigo de la clase se ha cargado por el RMI dentro de la mquina virtual del objeto Compute, se ha llamado al mtodo execute, y se ha ejecutado el cdigo de la tarea. El Object resultante (que en el caso de la tarea Pi es realmente un objeto java.math.BigDecimal) es enviado de vuelta al cliente, donde se utiliza para imprimir el resultado. El hecho de que el objeto Task suministrado calcule el valor de Pi es irrelevante para el objeto ComputeEngine. Por ejemplo, tambin podramos implementar una tarea que generara un nmero primo aleatorio utilizando un algoritmo probabilistico. (Esto tambin consume muchos recursos y por tanto es un candidato para ser enviado al ComputeEngine). Este cdigo tambin podra ser descargado cuando el objeto Task fuera pasado al objeto Compute. Todo lo que el objeto Compute sabe es que cada objeto que recibe implementa el mtodo execute, no sabe (y tampoco le interesa) qu hace la implementacin. 5.3. Compilar el Ejemplo Ahora aprenderemos cmo crear un fichero JAR, las clases del servidor, y las clases del cliente. Veremos como la clase Pi ser descargada al servidor durante la ejecucin. Tambin

141

veremos ejecucin.

como

el

stub

remoto

ComputeEngine

ser

descargado desde el servidor hasta el cliente durante la El ejemplo separa los interfaces, la implementacin de los objetos remotos y el cdigo del cliente en tres paquetes diferentes. compute (Los interfaces Compute y Task) engine (Implementacin de la clase, el interface y el stub de ComputeEngine) client (la implementacin del cliente ComputePi y de la tarea Pi).

5.3.1.

Construir un Fichero JAR con las Clases de

Interfaces Primero necesitamos compilar los ficheros fuente de los interfaces del paquete compute que construir un fichero JAR que contenga los ficheros class. Supongamos que el usuario waldo ha escrito estos interfaces particulares y ha situado los ficheros (en fuente UNIX en sera, c:\home\waldo\src\compute

/home/waldo/src/compute). Con estos paths podemos utilizar los siguientes comandos para compilar los intefaces y crear el fichero JAR.
Detalles especficos de la Plataforma: Construir un Fichero JAR Windows. cd c:\home\waldo\src javac compute\Compute.java javac compute\Task.java jar cvf compute.jar compute\*.class UNIX. cd /home/waldo/src javac compute/Compute.java javac compute/Task.java jar cvf compute.jar compute/*.class

142

El comando jar muestra la siguiente salida (debido a la opcin -v). added manifest adding: compute/Compute.class (in=281) (out=196) (deflated 30%) adding: compute/Task.class (in=200) (out=164) (deflated 18%)

Ahora podemos distribuir el fichero compute.jar a los desarrolladores de las aplicaciones del cliente y del servidor para que puedan hacer uso de los interfaces. La accesibilidad en la red de los ficheros de clases permite al sistema RMI descargar cdigo cuando sea necesario. En vez de definir su propio protocolo para descargar cdigo, RMI utiliza un protocolo URL soportado por Java (por ejemplo, HTTP) para descargar el cdigo. 5.3.2. Construir las Clases del Servidor del lado del del servidor, objeto ComputeEngine, del la

El paquete engine slo contiene la implementacin de la clase implementacin remoto interface

Compute. Como ComputeEngine es una implementacin de un interface remoto, necesitamos generar un stub para el objeto remoto para que los clientes puedan contactar con l. Digamos que, ana, la desarrolladora de la clase ComputeEngine, ha situado ComputeEngine.java en el directorio c:\home\ana\src\engine, y ha colocado el fichero class para que lo usen los clientes en un subdirectorio de su directorio accesible public_html, mendiante c:\home\ana\public_html\classes (en UNIX podra ser /home/ana/public_html/classes, algn servidor web como http://host/~ana/classes/). Asumamos que el fichero compute.jar esta localizado en el directorio c:\home\ana\public_html\classes. Para compilar la clase ComputeEngine, nuestro path de clases

143

debe incluir el fichero compute.jar y el propio directorio

Detalles Especficos de la Plataforma: Compilar el Motor de Clculo y sus Stubs Windows. cd c:\home\ana\src javac engine\ComputeEngine.java rmic -d . engine.ComputeEngine mkdir c:\home\ana\public_html\classes\engine cp engine\ComputeEngine_*.class c:\home\ana\public_html\classes\engine Unix. cd /home/ana/src javac engine/ComputeEngine.java rmic -d . engine.ComputeEngine mkdir /home/ana/public_html/classes/engine cp engine/ComputeEngine_*.class

fuente. Aqu podemos ver cmo seleccionar la variable de entorno CLASSPATH.

Detalles Especficos de la Plataforma: Selecionar el CLASSPATH Windows. set CLASSPATH=c:\home\ana\src;c:\home\ana\public_html\classes\compute.jar Unix: setenv CLASSPATH /home/ana/src:/home/ana/public_html/classes/compute.jar

Ahora compilamos el fichero fuente ComputeEngine.java y generamos un stub para la clase ComputeEngine y coloca el stub accesible a la red. Para crear el stub (y opcionalmente los ficheros esqueleto) ejecutamos el compilador rmic sobre los nombres totalmente cualificados de las clases de implementacin de los objetos remotos que deberan encontrarse en el path de clases. El comando rmic toma uno o ms nombres de clase como entrada y produce, como salida, ficheros de clases con la forma ClassName_Stub.class El (y opcionalmente ClassName_Skel.class). fichero

esqueleto no ser generado si llamamos a rmic con la opcin -v1.2. Esta opcin slo debera utilizarse si todos nuestros clientes van a utilizar el JDK 1.2 o posterior. La opcin -d le dice al compilador rmic que situe los ficheros de clases generados, ComputeEngine_Stub y

144

ComputeEngine_Skel, c:\home\ana\src\engine.

en Tambin

el

directorio poner

necesitamos

estos ficheros accesibles en la red, por eso debemos copiarlos en el rea public_html\classes. Como el stub de ComputeEngine implementa el interface Compute, que referencia al interface Task, tambin necesitamos poner estas clases disponibles en la red. Por eso, el paso final es en desempaquetar el para hacer el fichero que los compute.jar directorio

c:\home\ann\public_html\classes descarga.

interfaces Compute y Task estn disponibles para su

Detalles Especficos de la Plataforma: Desempaquetar el Fichero JAR Windows. cd c:\home\ana\public_html\classes jar xvf compute.jar Unix. cd /home/ana/public_html/classes jar xvf compute.jar El comando jar muestra esta salida. created: META-INF/ extracted: META-INF/MANIFEST.MF extracted: compute/Compute.class extracted: compute/Task.class

5.3.3.

Construir las clases del Cliente en el directorio c:\home\jones\src\client y

Asumamos que el usuario jones ha creado el cdigo del cliente colocar la clase Pi (para que sea descargada por el motor de clculo) en el directorio accesible a la red c:\home\jones\public_html\classes mediante algunos (tambin disponible como servidores

http://host/~jones/classes/). Las dos clases del lado del cliente estn contenidas en los ficheros Pi.java y ComputePi.java en el subdirectorio client. Para construir el cdigo del cliente, necesitamos el fichero compute.jar que contiene los interfaces Compute

145

y Task que utiliza el cliente. Digamos que el fichero compute.jar est situado en c:\home\jones\public_html\classes. Las clases del cliente se pueden construir as.
Detalles Especficos de la Plataforma: Compilar el Cliente Windows: set CLASSPATH=c:\home\jones\src;c:\home\jones\public_html\class es\compute.jar cd c:\home\jones\src javac client\ComputePi.java javac -d c:\home\jones\public_html\classes client\Pi.java UNIX. setenv CLASSPATH /home/jones/src:/home/jones/public_html/classes/compute.jar cd /home/jones/src javac client/ComputePi.java javac -d /home/jones/public_html/classes client/Pi.java

Slo necesitamos situar la clase Pi en el directorio public_html\classes\client (el directorio client lo crea el javac si no existe). Esto es as por esta clase es la nica que necesita ser desacargada por la mquina virtual del motor de clculo. 5.4. Ejecutar el Ejemplo Una Nota sobre la Seguridad El modelo de seguridad del JDK 1.2 es ms sofisticado que el modelo utilizado en el JDK 1.1. Contiene ampliaciones para seguridad de grano fino y requiere cdigo que permita los permisos especficos para realizar ciertas operaciones. En el JDK 1.1, todo el cdigo que haya en el path de clases se considera firmado y puede realizar cualquier operacin, el cdigo descargado est gobernado por las reglas del controlador de seguridad instalado. Si ejecutamos este ejemplo en el JDK 1.2 necesitaremos especificar un fichero de polica cuando ejecutemos el servidor y el cliente. Aqu tenemos un fichero de polica general que permite al cdigo descargado desde cualquier codebase, hacer dos cosas.

146

conectar o acceptar conexiones en puertos no

privilegiados (puertos por encima del 1024) de cualquier host, y

conectar con el puerto 80 (el puerto HTTP).

grant { permission java.net.SocketPermission "*:1024-65535", "connect,accept"; permission java.net.SocketPermission "*:80", "connect"; };

Si hacemos nuestro cdigo disponible mediante URLs HTTP, deberamos ejecutar el fichero de polica anterior cuando ejecutemos este ejemplo. Sin embargo, si utilizarmos un fichero de URLs en su lugar, podemos utilizar el fichero de polica siguiente. Observa que en entornos windows, la barra invertida necesita ser representada con dos barras invertidas en el fichero de polica.
grant { permission java.net.SocketPermission "*:1024-65535", "connect,accept"; permission java.io.FilePermission "c:\\home\\ana\\public_html\\classes\\-", "read"; permission java.io.FilePermission "c:\\home\\jones\\public_html\\classes\\-", "read"; };

Este ejemplo asume que el fichero de polica se llama java.policy y contiene los permisos apropiados. Si ejecutamos este ejemplo en el JDK 1.1, no necesitamos un fichero de polica ya que el RMISecurityManager proporciona toda la proteccin que necesitamos. Arrancar el Servidor Antes de arrancar el motor de clculo, necesitamos arrancar el registro de RMI con el comando rmiregistry. Como explicamos en pginas anteriores el registro RMI es una facilidad de nombrado que permite a los clientes obtener una referencia a un objeto remoto. Observa que antes de arrancar el rmiregistry, debemos asegurarnos de que el shell o ventana en la que ejecutaremos rmiregistry no tiene la variable de entorno CLASSPATH, o si la tiene sta no incluye el path a ninguna

147

clase,

incluyendo

los

stubs

de

nuestras

clases

de

implementacin de los objetos remotos, que querramos descargar a los clientes de nuestros objetos remotos. Si arrancamos el rmiregistry y ste puede encontrar nuestras clases stub en el CLASSPATH, no recordar que las clases stub cargadas pueden ser cargadas desde el codebase de nuestro servidor (que fue especificado por la propiedad java.rmi.server.codebase cuando se arranc la aplicacin servidor). Como resultado, el rmiregistry no enviar a los clientes un codebase asociado con las clases stub, y consecuentemente, nuestros clientes no podrn localizar y cargar las clases stub (u otras clases del lado del servidor). Para arrancar el registro en el servidor, se ejecuta el comando rmiregistry. Este comando no produce ninguna salida y normalmente se ejecuta en segundo plano.
Detalles Especficos de la Plataforma: Arrancar el Registro en el Puerto por Defecto Windows (utilizar javaw si no est disponible start). unset CLASSPATH start rmiregistry UNIX. unsetenv CLASSPATH rmiregistry &

Por defecto el registro se ejecuta sobre el puerto 1099. Para arrancar el registro sobre un puerto diferente, se especifica el nmero de puerto en la lnea de comandos. No olvidemos borrar el CLASSPATH.
Detalles Especficos de la Plataforma: Arrancar el Registro en el Puerto 2001

Windows.
start rmiregistry 2001 UNIX. rmiregistry 2001

Una vez arrancado el registro, podemos arrancar el servidor. Primero, necesitamos asegurarnos de que el fichero compute.jar y la implementacin del objeto remoto (que es lo que vamos a arrancar) estn en nuestro path de clases.

148

Detalles Especficos de la Plataforma - Seleccionar la variable CLASSPATH

Windows.
set CLASSPATH=c:\home\ana\src;c:\home\ana\public_html\classes\comput e.jar

Unix.
setenv CLASSPATH /home/ana/src:/home/ana/public_html/classes/compute.jar

Cuando

arrancamos

el

motor

de

clculo,

necesitamos

especificar, utilizando la propiedad java.rmi.server.codebase, donde estn disponibles las clases del servidor. En este ejemplo, las clases del lado del servidor disponibles son el stub de ComputeEngine y los interfaces Compute y Task disponibles en el directorio public_html\classes de ana.
Detalles Especficos de la Plataforma: Arrancar el Motor de Clculo Windows. java -Djava.rmi.server.codebase=file:/c:\home\ana\public_html\classes / -Djava.rmi.server.hostname=zaphod.east.sun.com -Djava.security.policy=java.policy engine.ComputeEngine UNIX. java -Djava.rmi.server.codebase=http://zaphod/~ana/classes/ -Djava.rmi.server.hostname=zaphod.east.sun.com -Djava.security.policy=java.policy engine.ComputeEngine

Arrancar el Cliente Una vez que el registro y el motor se estn ejecutando, podemos arrancar el cliente, especificando. la localizacin donde el cliente sirve sus clases (la clase Pi) utilizando la propiedad java.rmi.server.codebase. como argumentos de la lnea de comandos, el nombre del host (para que el cliente sepa donde localizar el objeto remoto) y el nmero de decimales utilizado en el clculo del nmero Pi.

149

java.security.policy, adecuados.

una

propiedad

utilizada

para

especificar el fichero de polica que contiene los permisos Primero seleccionamos el CLASSPATH para ver el cliente de jones y el fichero JAR que contiene los interfaces. Luego se arranca el cliente de esta forma.
Detalles Especficos de la Plataforma: Arrancar el Cliente Windows. set CLASSPATH c:\home\jones\src;c:\home\jones\public_html\classes\compute.jar java -Djava.rmi.server.codebase=file:/c:\home\jones\public_html\classes/ -Djava.security.policy=java.policy client.ComputePi localhost 20 UNIX. setenv CLASSAPTH /home/jones/src:/home/jones/public_html/classes/compute.jar java -Djava.rmi.server.codebase=http://ford/~jones/classes/ -Djava.security.policy=java.policy client.ComputePi zaphod.east.sun.com 20

Despus de arrancar el cliente, deberamos ver la siguiente salida en nuesta pantalla. 3.14159265358979323846

ACTIVIDAD

Discuta la semntica de invocacin que puede lograrse cuando se implementa el protocolo peticin-respuesta, sobre una conexin TCP/IP, que garantiza que los datos se entrean en el orden de su envio. Sin prdidas y sin duplicacin. Tenga en cuenta todas las condiciones que puedan causar la ruptura de una conexin.

RESUMEN Este capitulo ha mostrado dos paradigmas de la programacin distribuida: la invocacin de mtodos remotos y lo sistemas basados en eventos. Ambos paradigmas contemplan los objetos como entidades independientes que pueden recibir invocaciones desde objetos remotos. En el primer caso, un mtodo en la interfaz remota de un objeto en particular es

150

invocado

sincrnicamente

(el

que

invoca

espera

por

la

respuesta). En el segundo caso se envan notifcaciones asincrnicamente a varios multiples suscriptores cuando quiera que ocurra un evento publicado hacia el objeto interesado. El modelo de objetos distribuidos es una extensin del modelo de objetos locales que se emplea en los lenguajes de programacin badaos en objetos. Los objetos encapsulados constituyen componentes utiles en un sistema distribuido, puesto que la encapsulacin los hace enteramente responsables de gestionar su propio estado, y la invocacin de mtodos locales puede extenderse hacia la invocacin remota. Cada objeto de un sistema distribuido tiene una referencia a un objeto remoto (un identificador global nico) y una interfaz remota que especifica cuales de sus operaciones pueden ser invocadas remotamente. La invocacin a un mtodo local da una semntica del tipo exactamente una vez, mientras que una invocacin remota no puede dar las mismas garantas dado que los objetos participantes stan en computadoras diferentes, que pueden fallar independientemente y estn ligados por una red, que tambin podra fallar. Lo mejor que podemos obtener es una semntica del tipo como mximo una vez, debido a sus dieferentes caracteristicas de fallo y prestaciones y a la posibilidad de acceso concurrente a esos objetos remoto, no parece una buena idea hacer que invocacin remota parezca idntica a una invocacin local. Las implentaciones de Middleware para RMI proporcionan componentes(que comprenden proxy, esqueleto y distribuidor) que oculta detalles del empaquetado, el paso de mensajes y la localizacin de los objetos remotos desde los programas cliente y servidor. Estos componentes pueden generarse mediante un compilador de interfaces. Java RMI extiende la invocacin local en invoacion remota emplenado la misma sintaxis, pero habr

151

que especificar las interfaces remotas como una extensin de una interfaz denominada Remote y tambin cada mtodo deber lanzar la excepcin RemoteException. Esto garantiza que los programadores son conscientes de que realizan llamadas remotas o implemnetan los errores objetos o remotos, y permitindoles gestionar disear objetos

adecuados para acceso en caso de ocurrencia. BIBLIOGRAFIA RECOMENDADA

o

Java Remote Method Invocation (RMI); http://java.sun.com/products/jdk/rmi/

o jGuru: Remote Method Invocation: Introduction; http://developer.java.sun.com/developer/onlineTraining/r mi/

o

RMI y CORBA (RMI sobre IIOP); http://developer.java.sun.com/developer/earlyAccess/idlc/ George Colouris, Sistemas Distribuidos Conceptos y Diseo, Addison Wesley, Espaa 2001 http://www.cdk3.net/ Tanenbaum, Distributed Systems: Principles and

Paradigms, Prentice Hall, Mexico 2002. http://www.prenhall.com/divisions/esm/app/author_tanenb aum/custom/dist_sys_1/

o

Liu,

Distributed

Computing:

Principles

and

Applications, Addison Wesley, Mexico 2005 http://www.csc.calpoly.edu/~mliu/book/ AUTOEVALUACION FORMATIVA

o

La interfaz Eleccion proporciona dos metodos remotos: Vota: con dos parametros mediante los que el cliente indica el nombre del candidato (una cadena de texto) y el numero del votante (un entero que sirve para asegurar

152

que cada usuario solo vota una vez). Los numeros de votante se escogen de modo disperso del intervalo de los enteros para que sean dificiles de adivinar. Cules de los parametros de estos procedimientos son de entrada y cuales osn de salida?.
o

El servicio Eleccion debe asegurar que se registra cada voto cuando quiera que un usuario piense que ha emitido su voto. Explique el efecto de la semantica de llamada pudiera ser sobre el servicio eleccion. seria aceptable la semantica de llamada al menos una vez para el servicio Eleccion o recomendaria una semantica de llamada del tipo como maximo una vez?

153

UNIDAD ACADMICA N 07

SISTEMAS DE ARCHIVOS DISTRIBUIDOS

Los sistemas de archivos distribuidos soportan la compraticion de informacin en forma de archivos a travs de internet. Un servicio de archivos bien (y diseado en en un proporciona con casos acceso que a la los y de archivos fiabilidad archivos alamacenados semejantes servidor prestaciones

algunos

mejor)

almacenados en discos locales. Un sistema de archivos distribuido permite a los programas almacenar y acceder a archivos remotos del mismo modo como que si fueran loscales, permitiendo a los usuarios acceder a los archivos desde cualquier compuatdor de la intranet. Un sistema de archivos distribuidos, (DFS), es una implementacin distribuida del clsico modelo de tiempo compartido de un sistema de archivos, donde varios usuarios comparten archivos y almacenan recursos. INDICADORES DE LOGRO Al terminar esta unidad el estudiante estar en condiciones de:

Definir, describir que es sistema de archivos distribuido. Definir, describir caracteristicas de los sistemas de archivos distribuido. Definir, describir los requisitos de los sistemas de archivos diatribuido Conocer e implementar la arquitectura de los sistemas de archivos distribuidos.

1. CARACTERSTICAS DE LOS SISTEMAS DE ARCHIVOS Los sistemas de archivos son responsables de la organizacin, almacenamiento, recuperacin, nominacin, comparticin y

154

proteccin

de

los

archivos.

Proporcionan

una

interfz

de

programacin caracterstica de la abstraccin de archivo, liberando a los programadores de la preocupacin por los detalles de la asignacin y la disposicin del almacenamiento. Los archivos se almacenan en Discos y otros medios de almacenamiento no voltiles. Los sistemas de archivos estn diseados para almacenar y gestionar gran nmero de archivos, con posibilidades de crear, nombrar y borrar archivos. La nomenclatura de los archivos est respaldada por la utilizacinde directorios. Un directorio es un archivo. En la figura 1 se muestra una estructura tpica de niveles para la implementacin de un sistema de archivos no distribuidos en un sistema operativo convencional. Cada nivel depende slo de los niveles que se encuentran debajo de l. La implementacin de un servicio de archivos distribuidos requiere todos los componentes Tamao del Archivo Marca temporal de creacin Marca temporal de lectura Marca temporal de escritura Marca temporal de atributos Contador de referencias Propietario Tipo de archivos Lista de control de acceso indicados, junto a componentes adicionales ocuparse de comunicacin cliente servidor y de la nomenclatura y ubicacin de los archivos distribuidos. para la

155

Figura 1. Estructura tipica de un sitema de archivos

156

2. REQUISITOS DEL SISTEMA DE ARCHIVOS DISTRIBUIDOS Muchos de los requisitos y potenciales obstculos en el diseo de servicios distribuidos fueron ya observados en los primeros desarrollos de sistemas de archivos distribuidos. Inicialmente ofrecan transparencia de acceso y transparencia de ubicacin, los requisitos de prestaciones, escalabilidad, control de concurrencia, tolerancia a fallos y seguridad surgieron y se fueron satisfaciendo en fases posteriores del desarrollo. Discutimos estos requisitos, y otros relacionados, en las subsecciones siguientes. Transparencia. El servicio de archivos es el servicio ms fuertemente cargado en una intranet, por lo que su funcionalidad y prestaciones son crticas. El diseo de un servicio de archivos debe soportar muchos de los requisitos de transparencia para sistemas distribuidos.
2.1.

Actualizaciones concurrentes de archivos. Los cambios en un archivo por un cliente no deben interferir con la operacin de otros clientes que acceden o cambian simultneamente el mismo archivo.

2.2.

Replicacin de Archivos.

En un servicio de archivos que soporta replicaciones, un archivo puede estar representado por varias copias de su contenido en diferentes ubicaciones Esto tiene dos beneficios, permite que mltiples servidores compartan la carga de proporcionar un servicio a los clientes que acceden al mismo conjunto de archivos, mejorando la escalabilidad del servicio y mejorando la tolerancia a fallos, permitiendo a los clientes localizar otro servidor que mantiene una copia del archivo cuando ha fallado. 2.3. Heterogeneidad del hardware y del sistema operativo. Las interfaces del servicio deben estar definidas de modo que el software del cliente y el servidor pueden estar implementados por diferentes sistemas operativos y computadores. Este requisito es un aspecto importante de la extensibilidad.

157

2.4.

Tolerancia a Fallos. en los sistemas

El papel central de un servicio de archivos

distribuidos hace que sea esencial que el servicio contine funcionando aun en el caso de fallos del cliente y del servidor. Afortunadamente un diseo moderadamente tolerante a fallos es inmediato para servidores sencillos. Para manejar los fallos de comunicacin transitorios, el diseo puede estar basado en la semntica de invocacin de cmo mximo una vez. O puede utilizarse la semntica ms sencilla al menos una vez con un protocolo de servidor diseado en trminos de operaciones idempotentes, 2.5. asegurando que solicitudes duplicadas no producen actualizaciones invlidas en los archivos. Consistencia. convencionales, como los se Los sistemas de archivos

proporcionan en UNIX, ofrecen una semntica de actualizacin de una copia. Esto se refiere a un modelo para acceso concurrente a archivos en el que el contenido del archivo visto por todos los procesos que acceden o actualizan a un archivo dado es aquel que ellos veran si existiera una nica copia del contenido del archivo. 2.6. Seguridad. Virtualmente todos los sistemas de archivos proporcionan mecanismos de control de acceso basados en el uso de listas de control de acceso. En sistemas de archivos distribuidos, hay una necesidad de autenticar las solicitudes del cliente por lo que el control de acceso en el servidor est basado mensajes 2.7. de solicitud y respuesta con firmas digitales en y identificar al usuario correcto y proteger el contenido de los (opcionalmente) encriptacin de datos secretos. Eficiencia. Un servicio de archivos distribuidos debe ofrecer posibilidades con la misma potencia y generalidad que las que se encuentran

158

en

los

sistemas

de

archivos

convencionales

deben

proporcionar un nivel de prestaciones comparable. 3. ARQUITECTURA DEL SERVICIO DE ARCHIVOS El alcance de la extensibilidad y configurabilidad se mejora si el servicio de archivos se estructura en tres componentes, un servicio de archivos plano, un servicio de directorio y un mdulo cliente. El servicio de archivos plano y el servicio de directorio exportan cada uno una interfaz, para su uso por los programas del cliente y sus interfaces RPC, consideradas conjuntamente, proporcionan un conjunto global de operaciones para acceso a archivos. El mdulo cliente proporciona una interfaz sencilla con operaciones sobre archivos de programacin semejantes a las

encontradas en los sistemas de archivos convencionales. El diseo es abierto en el sentido que pueden utilizarse diferentes mdulos cliente para implementar diferentes interfaces de programacin, simulando las operaciones sobre archivos de una variedad de diferentes sistemas operativos y optimizando las prestaciones para diferentes configuraciones de hardware del cliente y el servidor.
Programa De aplicaci Programa De aplicaci

Servicio de directorio

Servicio de archivos plano Mulo de cliente

Figura 2. Arquitectura del servicio de archivos

4. SISTEMA DE ARCHIVOS EN RED DE SUN (NFS). Todas las implementaciones de NFS soportan el protocolo de NFS: un conjunto de llamadas a procedimientos remotos que proporcionan el medio para que los clientes realicen operaciones en un almacn de archivos remotos. El protocolo NFS es independiente del sistema operativo pero fue desarrollado

159

originalmente para su utilizacin en redes de sistemas UNIX. El mdulo servidor NFS reside en el ncleo de cada computador que acta como un servidor NFS. Las solicitudes que se refieren a archivos en un sistema de archivos remoto se traducen en el mdulo cliente a operaciones del protocolo NFS y despus se trasladan al mdulo servidor NFS en el computador que mantiene el sistema de archivos relevante. Los mdulos cliente y servidor NFS se comunican utilizando llamadas a procedimientos remotos.

Computador Cliente
Programa De aplicaci Programa De aplicaci

Computador servidor

LLamadas al sistema UNIX N leo UNIX

N leo UNIX
Otro sistema de archivos
Sistema de archivos virtual Sistema de archivos virtual

Local
Sistema de archivos UNIX

Remoto
Cliente NFS Servidor NFS Sistema de archivos UNIX

Protocolo NFS

Figura 3. Sistema de archivos en red de SUN

Sistemas de Archivos Virtuales.- Otros sistemas de archivos distribuidos pueden considerar que permiten las llamadas al sistema de UNIX, y si lo hacen, podran integrarse de la misma forma. La integracin se obtiene mediante para distinguir entre un mdulo de archivos virtual (VFS), que ha sido aadido al ncleo de UNIX archivos remostos y locales y para traducir los identificadores de archivos, independientes de UNIX y otros sistemas de archivos. En resumen, VFS mantiene la pista de los sistemas de archivos que estn actualmente disponibles tanto local como remotamente, pasa cada solicitud al mdulo del sistema local apropiado (el sistema de archivos UNIX, el mdulo cliente NFS o el mdulo de servicio de otro sistema de archivos).

160

Los identificadores de archivos utilizados en NFS se llama apuntadores de archivos (file handles). Un apuntador de archivo es opaco para los clientes y contiene toda la informacin que necesita el servidor para distinguir un archivo individual.

Integracin del Cliente.- El cliente NFS juega el papel descrito para el mdulo cliente en nuestro modelo arcquitectnico, proporcionado una interfaz idneo para su uso por programas de aplicacin convencionales. Pero a diferencia del mdulo cliente de nuestyro modelo, emula la semntica de las primitivas del sistema de archivos estndar de UNIX de forma precisa y est integrado con un nucleo UNIX. Est integrado con el ncleo y no proporcionado como una librera para cargar en los procesos cliente de modo que: Los programas de usuario pueden acceder a los archivos mediante llamadas del sistema de UNIX sin recopilacin o recarga. Un nico mdulo cliente sirve a todos los procesos del nivel del usuario, con una cach compartida de los bloques utilizados recientemente. La clave de encriptacin utilizada para autentificar ID del usuario pasadas al servidor puede retenerse en el ncleo, previniendo la impersonacinpor clientes a nivel de usuario. El mdulo cliente de NFS coopera con el sistema de archivos virtual en cada mquina cliente. Funciona transferiendo bloques de archivos hacia y desde el servidor y haciendo caching de los bloques en la memoria local cuando es posible. Comparte el mismo buferde cach que el utilizado por el sistema de entrada salida local. Pero puesto que varios clientes en diferentes mquinas pueden acceder simultaneamente al mismo archivo

161

remoto, se plantea un uevo y significativo problema de consistencioa de cach. ACTIVIDAD Esboce meeotodos mediante los cuales un odulo cliente podra emular la interfaz del servicio de archivos UNIX utilizando nuestro modelo de servicio de archivos. RESUMEN Los sistemas de archivos distribuidos son empleados intensamente en las organizaciones actuales y sus prestaciones han estado a muchos ajustes. Las caracterisiticas fundamentales para el diseo para sistemas de archivos distribuidos son: La utlizacion efectuva de la memoria cach en el cliente para conseguir iguales prestaciones o mejores que los de los sistemas de archivos locales. El manetnimiento de la consistencia entre multiples copias de archivos en las cachs de los clientes cuando son actualizadas. La recuperacin despus de un fallo en el servidor o en el cliente. El alto rendimiento en la lectura y escriturade archivos de todos los tamaos, La escalabilidad.

BIBLIOGRAFIA RECOMENDADA
o

George Colouris, Sistemas Distribuidos Conceptos y Diseo, Addison Wesley, Espaa 2001 http://www.cdk3.net/ Tanenbaum, Distributed Systems: Principles and

Paradigms, Prentice Hall, Mexico 2002. http://www.prenhall.com/divisions/esm/app/author_tanenb aum/custom/dist_sys_1/

162

Liu,

Distributed

Computing:

Principles

and

Applications, Addison Wesley, Mexico 2005 http://www.csc.calpoly.edu/~mliu/book/

163

AUTOEVALUACION FORMATIVA o por que no hay operacin Abre y Cierra en nuestra interfaz de servicio de archivos planos o en el servicio de directorio? Cules son las diferencias entre operacin Busca de nuestro servicio de directorio y la open de UNIX? o Por qu deben ser unicos los UFID entre todos los posibles sistemas de archivos? Cmo se asegura la unicidad para los UFID?

164

UNIDAD ACADMICA N 08

SEGURIDAD EN SISTEMAS DISTRIBUIDOS

En el mundo actual hay una necesida apremiante de medidas de seguridad para garantizar la privacidad, integridad y disponibilidad de recursos en los sistemas distribuidos. Los ataques contra la seguridad toman las formas de escucha, suplantacin, modificacin y denegacin del servicio. Los diseadores de sistemas distribuidos seguros deben tratar con interfaces de servicio desprotegidos y redes inseguras en un entorno donde se supones que los atacantes tienen conocimientos sobre los algoritmos emplesados para desplegar los recursos computacionales. INDICADORES DE LOGRO Al terminar esta unidad el estudiante estar en condiciones de:

Definir, describir que es sistema de archivos distribuido. Definir, describir caracteristicas de los sistemas de archivos distribuido. Definir, describir los requisitos de los sistemas de archivos diatribuido Conocer e implementar la arquitectura de los sistemas de archivos distribuidos.

1. AMENAZAS Y ATAQUES Algunos ataques son obvios, por ejemplo en la mayora de los tipos de redes locales es fcil construir y lanzar sobre un computador conectado para obtener copias de los mensajes en otros computadores. Otras amenazas son mas sultiles, si los clientes fallan en autenticar los servidores un programa podra situarse a si mismo en lugar del autentico servidor de archivos y

165

asi obtener copias de informacin confidencial que los clientes, inconcientemente envan para su almacenamiento. Adems del peligro de prdida o dao de informacin, o de recursos por violaciones directas tambin pueden aparecer reclamos fraudulentos contra el propietario de un sistema que no sea demostrablemente seguro. Para evitar tales reclamos, el propietario debe estar en situacin de desacreditar el reclamo mostrando que el sistema es seguro contra tales violaciones o tambin produciendo un registro histrico de todas las transacciones durante el periodo en cuestin. Un ejemplo es el problema de debito fantasma en los dispensadores automaticos de dinero en efectivo(cajeros automaticos). La mejor respuesta que un banco pueda aportar a tal reclamo es proporcionar un registro de la transacciones firmado digitalmente por el titular de la cuenta, de manera que no pueda ser falsificado por un tercero. La principal meta de la seguridad es restringir el acceso a la informacin y los recursos de modo que solo tengan acceso aquellos principales autorizados. Las amenazas de seguridad caen en tres amplias clases:

Fuga:

la

adquisicin

de

informacin

por

receptores

no

autorizados.

Alteracin: Vandalismo:

la modificacin no autorizada de informacin. interferencia con el modo de operacin adecuado de

un sistema, sin ganancia alguna para el perpetrador. Los ataques en los sistemas distribuidos dependen de la obtencin de acceso a los canales de comunicacin existentes o del establecimiento de canales nuevos que se suplantan a las conexiones(empleamos el termino canal para hacer alusin a cualquier mecanismo de comunicacin de procesos). Los mtodos pueden clasificarse ms aun en funcin del modo en que se abusa del canal:

Fisgar:

obtener copias de mensajes sin autoridad.

166

Suplantar :

enviar o recibir mensajes utilizando la identidad de

otro principal sin su autorizacin.

Alterar mensajes: Interceptar mensaje y alterar sus contenidos antes de pasarlos al receptor pretendido. Reenviar : almacenar mensajes interceptados y enviarlos mas tarde. mensajes con el fin de impedir que otros accedan a l. En teora estos son los peligros, pero como se llevan a la practica esto ataques? Los ataques victoriosos dependen de los descubrimientos de agujeros de seguridad en los sistemas. Desgraciadamente estos problemas son demasiados comunes en los sistemas de hoy en dia y no son necesariamente complicados. 2. ATAQUES DESDE CDIGO MVIL. Varios lenguajes de programcion, recientemente desarrollados han sido diseados para permitir que las descargas de programas desde servidores remotos y asi lanzar procesos que se ejecutan localmente. En este caso, las interfaces internas y lso objetos del interior de un proceso en ejecucin pueden quedar expuestos a un ataque por cdigo mvil. 3. FUGAS DE INFORMACIN Si pudiera observarse la sucesin de mensaes en la comunicacin entre dos procesos, seria posible vislumbrar informacin importante aun de su sola existencia, por ejemplo: un flujo de mensajes hacia un vendedor hacerca de una mercanca en particular podra indicar un alto nivel de comercio en esa mercanca. Hay muchas formas sutiles de fugas de informacin algunas maliciosas y otras que son consecuencias de errores inadvertidos. 4. SEGURIDAD DE LAS TRANSACCIONES ELECTRNICAS

Dengacion de servicio: desbordar un canal u otros recursos con

167

Muchas ampliaciones de internet en la industria el comercio y dems implican transacciones que dependen crucialmente de la seguridad: Email: aunque los sistemas originales de correo electrnico no incluyeran soporte de seguridad, hay muchos usos del correo en que los contenidos de los mensajes debe mantenerse confidenciales (por ejemplo al enviar un numero de trajetas de cerdito) o los contenidos y el emisor del mensaje deben estar autenticados (por ejemplo cuando se remite una puja a una subasta por email), la seguridad criptogrfica basada en las tcnicas que se describen en este capitulo se incluye actualmente en muchos clientes de correo.

Compra de bienes y servicios:

tales transacciones son hoy

en dia, algo usual. Los compradores selecciona bienes y pagan por ellos empleando la web, mas tarde sonenviados por el mecanismo de reparto mas apropiado. El software y otros productos digitales (como videos y grabaciones), se pueden enviar mediante el procedimiento de descarga desde internet los bienes tanjibles como libros, disco compactos y casi cualquier reparto. Transacciones bancarias: los bancos electrnicos de hoy en dia ofrecen virtualmente a los usuarios todos los servicos que proporcionan los bancos convencionales estos proporcionan la comprobacin de los cargos y balances de cuentas, transferencias de efectivo entre cuentas, el establecimiento de cargos regulares automaticos y dems desde la cuenta. Microtransacciones : internet se presta a proporcionar pequeas cantidades de informacin y otros servicios a sus clientes, por ejemplo el acceso a la mayora de las paginas web no exige ningn pago, pero el desarrollo del web como un medio de publicacon de alta calidad seguramente depende de otro tipo de producto puede venderse desde comercios en internet estos se envan mediante un servicio de

168

que hasta que punto los proveedores de informacin puedan obtener beneficio de los clientes de esta informacin. 5. VISIN GENERAL DE LAS TCNICAS DE LA SEGURIDAD El objetivo de esta seccin es presentar al lector algunas de las tcnicas y mecanismos mas importantes para asegurar sistemas y aplicaciones distribuidas.

169

6. CRIPTOGRAFA. La encriptacin es el proces de codificacin de un mensaje de forma que puedan ocultar sus contenidos, la criptografa moderna incluye algunos algoritmos seguros de encritacion y desencriptacion de mensajes. Todos ellos se basan en el uso de ciertos secretos llamados claves. Una clave criptogrfica es un parmetro empleado en un algoritmo de encritptacion de forma que la encriptacin no sea reversible sin el conocimiento de una clave. a) Criptoalgortmos Clsicos Revisin de la historia de la cifra. Cifra de sustitucin: Monoalfabtica. Polialfabtica. Distribucin de claves. Poligramas. Homofnica. Cifra de transposicin. Ruptura mediante el uso del anlisis de frecuencia. Teora de Shanon del secreto perfecto y sus aplicaciones prcticas. Data Encryption Standard primer intento de estandarizar la proteccin de la informacin en redes de computadoras. Revisin histrica de los criptosistemas Los roles de NBS NSA IBM. Aceptacin por parte de organismos oficiales y sectores comerciales. Principales caractersticas del algoritmo. Criterios de diseo. Criptoanlisis diferencial y lineal. Vulnerabilidad a un ataque de bsqueda exhaustiva de clave. Triple DES: Modos de operacin. Seguridad de los diferentes modos de operacin. Otras cifras de bloque de clave simtrica. IDEA, RC5, Blowfish, DESX, Skipjack. Algoritmos de cifrado para una implementacin rpida por software. Implementacin de cifras de bloque de clave secreta Arquitecturas generales de hardware y software. Implementaciones bsicas, operacin de los componentes de software y hardware. Arquitecturas de fast-hardware: loop unrolling;

170

inner-round pipelining; outer-round pipelining; mixed inner- and outer-round pipelining. Limitaciones impuestas por el ambiente de implementacin. Desarrollos de nuevo Advanced Encryption Standard AES. Contexto de desarrollo. Criterios de evaluacin. Algoritmos candidatos a AES. Comparacin de los candidatos a AES: Seguridad; Eficiencia en la implementacin por software; Eficiencia en la implementacin por hardware; Flexibilidad; Procesos de evaluacin. b) Criptoalgoritmos de clave pblica. Criptosistemas RSA (Rivest, Shamir, Adleman) el primer criptosistema de clave pblica exitoso. Cmo se gest RSA. RSA como una funcin de una sola va con trapdoor. La factorizacin como principio de seguridad en RSA: registro de factorizacin; el uso de de RSA. factorizacin redes Tamaos de de grandes de clave nmeros mediante distribuidas

computadoras.

Desafos

recomendados en los criptosistemas RSA. Generacin de claves en los criptosistemas RSA. Propsitos generales vs propsitos especiales en los algoritmos de factorizacin. RSA para paranoicos. Fortaleza de los nmeros primos. Test probabilstico para detectar primos. Test determinstico para detectar primos. Construccin de nmeros primos grandes y randmicos. Implementacin de cifrado de clave pblica. Algoritmos de exponenciacin bsicos. Uso del teorema de los restos chinos para una rpida exponenciacin. Algoritmos bsicos para multiplicacin y reduccin modular por software. Arquitecturas bsicas para multiplicacin y reduccin modular por hardware. Dependencia entre la longitud de clave y el tiempo de transformacin criptogrfica. Reconocimiento de implementaciones existentes de RSA.

171

c) Servicios de Seguridad Firma Digital. Digital Signature Standard DSS. Clasificacin de firmas digitales. Ataques contra la firma digital. Relleno de seguridad para firmas. Digital Signature Standard (DSS). Anlisis comparativo de RSA y DSS Seguridad, perfomance, funcionalidad. Temas legales respecto a la firma digital. Integridad de datos y autenticacin dos faces del mismo problema. Funciones de hash y MACs. Requerimientos para una funcin de hashing segura. Clasificacin de las funciones de hashing. Ataques contra funciones de hashing. Aplicaciones estndar y no estndar.: firma digital y cdigos de autenticacin; deteccin de virus; almacenamiento de password; cifrado rpido. Familias de algoritmos para funciones de hashing y su seguridad. Requerimientos para Message Authentication Code (MAC). Familias de MACs y su seguridad. Combinacin de autenticacin y confidencialidad. d) Administracin de claves Intercambio de claves para criptosistemas de clave simtrica. Clave de sesin y clave de encripcin. Intercabio de claves usando centros de distribucin. Protocolo de intercambio de clave de Diffie-Hellman. Intercambio de claves simtricas utilizando criptosistemas de clave pblica. Certificados de clave pblica e infraestructuras de autoridades de certificacin. Generacin y registro del par de claves pblicas. Concepto de certificado de clave pblica. Formatos de los certificados (X.509; EDIFACT; etc.). Estructura jerrquica y autoridades de certificacin en una estructura de clave pblica. Revocacin de certificados.

172

e) Estndares criptogrficos y protocolos seguros para Internet. Estndares critptogrficos de USA y resto del mundo. Organizaciones que administran estndares. Principales grupos de estndares criptogrficos: Estndares federales ( USA); Estndares ANSI; Estndares del IEEE; Estndares ISO; Estndares informales de la industria. Estndares para la criptografa clsica. Estndares para la criptografa de clave pblica. Protocolos seguros para Internet. Correo electrnico seguro: S/MIME; Open PGP. Web Site seguros: SSL; S-HTTP. Protocolos de seguridad para pagos con tarjeta: SET; dinero electrnico; micropagos. Redes privadas virtuales seguras: IPSec; PPTP. Controles de importacin y exportacin de dispositivos criptogrficos. Evolucin de las polticas de USA. Reglamentacin actual en USA. f) Captulos cuntica Criptografa cuntica Criptografa para el siglo XXI ..? Conceptos bsicos de la criptografa cuntica traslado del principio de Hisenberg para una seguridad ideal. Primeras implementaciones perfomance; prcticas de la criptografa cuntica Hacia costos; actuales limitaciones. una 7: Criptografa cuntica y computacin

computacin cuntica. Ruptura de cifras usando la computacin cuntica sueo o realidad .?. Reemplazar la fsica a la matemtica como la base para el desarrollo de la seguridad en redes de computadoras.?. Tendencia de las corrientes investigaciones en criptografa y seguridad en redes.

173

ACTIVIDAD

Describa algunas de las polticas de seguridad de su organizacin. Exprselas en trminos que pudieran ser implementados en sistema de computarizado de bloqueo de puertos..

174

RESUMEN Los ataques a la seguridad son parte de la realidad de los sistemas distribudos. Es esencial proteger los canales e interfaces de comunicacin de cualquier sistema que trate con informacin que sea suceptible de ser atacada. El correo personal, el coemrsio electrnico y otras transacciones financieras son ejemplos de tal tipo de informacin. Los protocolos de seguridad se disean cuidadosamente para evitar trampas. El diseo de los sistemas seguros parte de un listado de premisas de ataque y un conjunto de peores casos posibles. Loa mecanismos de seguridad se basan en la criptografa de clave publica y de clave secreta. Los algoritmos criptogrficos disfrazan los mensajes de forma que no pueda revertirse el proceso sin el conocimiento de la clave de desencriptacion. La criptografa de la clave secreta es simetrica: la misma clave sirve tanto para la encriptacin como para la desencriptacion. Si dos partes compraten una clave secreta, podrn intercambiar informacin encriptada sin riesgo que sea desvelada o modificada y con garantas de autenticidad. La criptografa de clave publica es asimtrica: se utlizan claves separadas para la encriptacin y desencriptacion, y el conociemiento de una de ellas no implica el de la otra. Una de ellas se hace pubica, de modo que cualquiera pueda enviar mensajes seguros al propietario de la correspondiente clave privada y permitiendo al poseedor de la clave privada firmar mensajes y certificados. Los certificados pueden servir como credenciales para el uso de recursos protegidos. Los recursos se protegen mediante mecanismos de control de acceso. Los esquemas de control de acceso asignan derechos a principales (esto es, los propietarios de las credenciales) para relaizar operaciones sobre objetos y colecciones de objetos distribuidos. Se pueden mantenerse enmanos de los principales

175

bajo la forma de habilitaciones: claves infalsificables de acceso a conjunto de recursos. Las habilitaciones son una forma conveniente de delegacin de derechos a acceso pero son difciles de revocar. Los cambios en una ACL tienen efecto inmediatamente, revocando los derechos de acceso previos, pero son mas costosas de manejar habilitaciones. BIBLIOGRAFIA RECOMENDADA
o

George Colouris, Sistemas Distribuidos Conceptos y Diseo, Addison Wesley, Espaa 2001 http://www.cdk3.net/ Tanenbaum, Distributed Systems: Principles and

Paradigms, Prentice Hall, Mexico 2002. http://www.prenhall.com/divisions/esm/app/author_tanenb aum/custom/dist_sys_1/

o

Liu,

Distributed

Computing:

Principles

and

Applications, Addison Wesley, Mexico 2005 http://www.csc.calpoly.edu/~mliu/book/ AUTOEVALUACION FORMATIVA

o

Describa algunas de las formas en la que es vulnerable el correo electronico a la indiscrecion, suplantacion, modificacion, repeticion y denegacion de servicio. Sugiera metodos por los que se pudiera proteger el correo electronico contra cada una de estas formas de ataque

o Los

intercambios

iniciales

de

claves

publicas

son

vulneranles al ataque del hombre entre medias. Describa cuantas defensas pueda contra l.
o

Cmo podria enviarse un correo electronico a un lista de receptores utilizando PGP o un esquema similar?

176