Libro Final Sistemas Distribuidos PDF

Copyright©2005 UNIVERSIDAD PERUANA LOS ANDES Programa de Educación a Distancia. Huancayo – Perú Prohibida la reproducción total o parcial sin autorización por escrito del Rector de la Universidad. La redacción de este texto estuvo a cargo de Ing. Carlos Alcides Almidón Ortiz.

1

Presentación La evolución de las tecnologías de la información y comunicación en el mundo nos permite implementar diferentes aplicaciones en la red, debido esto la generalización del termino cloud computing (servicios en el internet), la popular nube, como paradigma de todo tipo, tanto organizativo como de diseño de sistemas, conlleva a una interesante reflexión. Si la nube permite a los clientes

y usuarios poder obtener

funcionalidades a través de servicios, de los cuales solo conocen su contrato de servicio pero ignoran el diseño y la localización. Muchas veces olvidamos que los servicios han de ser fabricados y que para ese trabajo hay que prepararse, entonces aquí ingresa el diseño de los sistemas distribuidos. Un sistema distribuido es un sistema de información en el cual las funciones se reparten por áreas de trabajo diferentes que trabajan de forma coordinada para asumir los objetivos que la organización asigna a ese sistema de información. En este manual se trata de dar un alcance al estudiante de cómo diseñar sistemas distribuidos, que consiste en crear aplicaciones de software que, utilizando servicios y ayudándose de la conectividad, participen y se integren en este entorno de forma transparente a las plataformas de proceso y de almacenamiento de datos, dotándolas de los recursos necesarios para gestionarse de forma integrada con el resto del sistema distribuido. Los sistemas distribuidos que se diseñen y construyan deben estar alineados con los objetivos de negocio de la empresa, aumentar la eficacia y eficiencia operacional de la compañía y permitir el mayor rendimiento con el menor costo en las estructuras informáticas que dan soporte.

2

El autor

3

Programación general Conceptos de los Sistemas Distribuidos Autoaprendizaje 3 horas Unidad 1 Modelos de Sistemas Distribuidos Autoaprendizaje 3 horas Unidad 2 Comunicación a Nivel de Redes. Autoaprendizaje, 3 horas Unidad 3 Comunicación de procesos en los Sistemas Distribuidos. Autoaprendizaje, 3 horas Unidad 4 Comunicación 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

4

Tabla de contenido

Página

Presentación Programa general Conceptos de Sistemas Distribuidos

1

¿Qué es un Sistema Distribuido?

2

5

UNIDAD ACADÉMICA 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

sus acciones sólo mediante paso de

mensajes.

Figura 1. Representación 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 desafíos 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 teléfonos móviles, las redes corporativas, las de las empresas, los campus, las casas, redes dentro del coche, todas, tanto separados, como combinadas, comparten las características esenciales que las hacen elementos importantes para su estudio bajo el título de Sistemas Distribuidos.

6

Los

computadores

que

están

conectados mediante una red pueden estar separados especialmente

por

cualquier distancia. Pueden estar en continentes distintos, en el mismo edificio o en la misma habitación. Nuestra

definición

Distribuido

tiene

de las

Sistema siguientes

Figura 2.

consecuencias significativas: •

Internet

Concurrencia.- En una red de computadores, la ejecución de programas concurrentes es la norma. Usted puede estar realizando un trabajo en su computador, mientras otra persona también y a la vez ambos comparten recursos como páginas web o ficheros, cuando es necesario. La capacidad del sistema para manejar recursos compartidos se puede incrementar añadiendo más recursos (por ejemplo computadoras) a la red. Ventajas: Trabajo Cooperativo. Inconvenientes: Programación Compleja.

•

Inexistencia necesitan

de

Reloj

cooperar

Global.-

coordinan

sus

Cuando

los

acciones

programas

mediante

el

intercambio de mensajes. La coordinación estrecha depende a menudo de una idea compartida del instante en el que ocurren las acciones de los programas pero resulta que hay límites a la precisión con lo que los computadores en una red pueden sincronizar

sus relojes, no hay una única noción global del

tiempo correcto. Esto es una consecuencia directa del hecho que la única comunicación

se realiza enviando mensajes

a

través de la red. •

Fallos Independientes.- Todos los sistemas informáticos pueden

fallar

y

los

diseñadores

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

7

computadores conectados a él, pero eso no significa que detengan su ejecución. 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 terminación inesperada de un programa en alguna parte del sistema no se da a conocer inmediatamente a los demás 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 tecnología emergente basada en dispositivos móviles. Se han elegido para proporcionar ejemplos del amplio rango de servicios y aplicaciones que son soportados por redes de computadoras y para comenzar la discusión de las cuestiones técnicas que entraña su implementación. Ejemplo 1: Internet: Es una vasta colección de redes de computadoras de diferentes tipos

interconectados.

Programas

ejecutándose

en

los

computadores conectados a ella interactúan mediante paso de mensajes, empleando un medio común de comunicación. Internet, también es un sistema distribuido muy grande. Permite a los usuarios, donde quiera que estén, hacer uso de servicios como el

8

World Wide Web, el correo electrónico, 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

implementación de internet y los servicios que mantiene ha implicado el desarrollo de soluciones prácticas para muchas cuestiones de sistemas distribuidos. Ejemplo 2: Intranets: Una intranet es una porción de internet que es, administrada separadamente y que tiene un límite que puede ser configurado para hacer cumplir políticas 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 electrónico, 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 podría permitir, sólo aquellos mensajes relacionados con el correo electrónico el acceso web entrar o salir de la intranet que protege. Ejemplo 3: Computación Móvil y Ubicua: Los avances tecnológicos en la miniaturización de dispositivos y en redes inalámbricas han llevado cada vez más a la integración de dispositivos de computación pequeños y portátiles en sistemas distribuidos. Estos dispositivos incluyen: Computadoras portátiles, Dispositivos de manos como asistentes digitales personales, teléfonos móviles, buscapersonas y videocámaras o cámaras digitales. También dispositivos que se puedan llevar puestos como relojes inteligentes con funcionalidad semejante a los asistentes

9

digitales personales, y Dispositivos insertados en aparatos como lavadoras, sistemas de alta fidelidad, coches y frigoríficos. Se llama computación móvil a la realización de tareas de cómputo mientras el usuario está en movimiento o visitando otros lugares distintos de su entorno habitual. En la computación móvil, los usuarios que están 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 están suficientemente próximos a donde se encuentren. Computación ubicua es la utilización concertada de muchos dispositivos de computación pequeños y baratos que están presentes en los entornos físicos de los usuarios, incluyendo la casa, la oficina y otros. El término ubicuo está pensado para sugerir que los pequeños dispositivos llegarán a estar tan extendidos en los objetos de cada día que apenas nos daremos cuenta de ellos. O sea, su comportamiento computacional estará ligado con su función física de forma ínfima y transparente. Por ejemplo, podría 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 podría avisar al usuario a través de una tarjeta inteligente o reloj cuando el lavado hubiera finalizado. La computación ubicua y móvil se solapan, puesto que un usuario moviéndose puede beneficiarse, en principio, de los computadores que están en cualquier parte. Pero, en general, son distintas. La computación ubicua podrá beneficiar

a los usuarios mientras

permanecen en un entorno sencillo como su casa o un hospital. De forma similar, la computación móvil tiene ventajas si sólo se consideran computadores convencionales y dispositivos como computadores portátiles 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 más específica como máquinas de búsqueda. Considerado desde el punto de vista de la provisión de hardware, se comparten equipos como impresoras y discos para reducir costes. En la práctica los patrones de compartir recursos varían mucho en su enlace y cuán estrechamente trabajan juntos los usuarios. Los recursos en un sistema distribuido están encapsulados físicamente con los computadores

y

solo

pueden

ser

accedidos

desde

otros

computadores

y

sólo

pueden

ser

accedidos

desde

otros

computadores a través de comunicación. Para que se compartan de forma efectiva, cada recurso debe ser gestionado por un programa que ofrece una interfaz de comunicación permitiendo que se acceda y actualice el recurso de forma fiable y consistente. El termino servidor es probablemente familiar para la mayoría de los lectores. Se refiere a un programa en ejecución (un proceso) en un computador en red que acepta peticiones de programas que se están ejecutando en otros computadores para realizar un servicio y responder adecuadamente. Los procesos solicitantes son llamados clientes. Las peticiones se envían a través de mensajes desde los clientes al servidor y las contestaciones se envían mediante mensajes desde el servidor a los clientes. Cuando un cliente envía una petición para que se realice una operación, decimos que el cliente invoca una operación del servidor. Se llama invocación remota a una interacción completa entre un cliente y un servidor, desde el instante en el que el cliente envía su petición 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 términos cliente y servidor se aplican a los roles desempeñados en una única solicitud. Ambos son distintos, en muchos aspectos, los clientes son activos y los servidores pasivos, los servidores se están ejecutando continuamente, mientras que los clientes sólo lo hacen el tiempo que duran las aplicaciones de las que forman parte.

Figura 5. Proceso Cliente – Proceso Servidor

Hay que señalar que por defecto los términos cliente y servidor se refieren a procesos no a los computadores en las que se ejecutan, aunque en lenguaje coloquial dichos términos se refieren también a los propios computadores. 2.1 El World Wide Web Es un sistema en evolución para publicar y acceder a recursos y servicios a través de internet. Utilizando el software de un navegador web, fácilmente 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 vídeos, y para

interaccionar con un

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 operación está basada en estándares de comunicación y en documentos estándares que están publicados libremente e

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 más simple, un recurso es una página web o algún otro tipo de contenido que puede ser almacenada en un fichero y presentado al usuario, como ficheros de programa, de imágenes, de sonido y documentos en formato PostScript o PDF. El Web está basado en tres componentes tecnológicos de carácter estándar básicos: •

El lenguaje

de etiquetado

de hipertexto (HTML,

Hypertext Markup Languaje) es un lenguaje para especificar el contenido y el diseño de las páginas 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 diseñar sistemas distribuidos teniendo en cuenta sus características 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 programación, etc.). A pesar de que internet consta de muchos tipos de redes diferente, sus diferencias se encuentran enmarcadas dado que todos los computadores

conectados a éste utilizan los

protocolos de internet para comunicarse una con otra. Por ejemplo

un computador conectado a Ethernet tiene una

implementación de los protocolos de Internet sobre ethernet, así un computador en un tipo de red diferente necesitará una implementación 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

representación 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

implementación

de

los

protocolos de internet, no todas presentan necesariamente la misma interfaz de programación 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 programación

•

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 heterogéneas. Funciona

como

una

capa

de

abstracción

de

software

distribuida, que se sitúa 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 programación, proporcionando una API para la fácil programación y manejo de aplicaciones distribuidas. Dependiendo del problema a resolver y de las funciones necesarias, serán útiles diferentes tipo de servicios de middleware Es el estrato de software que provee una abstracción de programación,

así

como

un

enmascaramiento

de

la

heterogeneidad subyacente de las redes, hardware, sistemas operativos y lenguajes de programación. Ejem: Corba, Java RMI.

Figura 7. Sistemas Distribuidos como MIddleware

16

3.1.2. Heterogeneidad y código móvil •

Código Móvil: código que puede enviarse desde un computador a otro y ejecutarse en este último.

•

El concepto de máquina virtual ofrece un modo de crear código ejecutable sobre cualquier hardware.

3.2. Extensibilidad Es la característica 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 inclusión de computadoras a la red y a nivel de software por la introducción de nuevos servicios y la reimplementación de los antiguos. Otro beneficio de los sistemas abiertos es su independencia de proveedores concretos. 3.3. Seguridad La seguridad tiene tres componentes: Confidencialidad: protección contra individuos no autorizados. Integridad: protección contra la alteración o corrupción. Disponibilidad: protección contra la interferencia que impide el acceso a los recursos. Existen dos desafíos que no han sido resueltos en su totalidad: Ataques de denegación de servicio. Seguridad del código móvil. 3.4. Escalabilidad Se dice que un sistema es escalable si conserva su efectividad cuando ocurre un incremento significativo en el número de recursos y en el número de usuarios. El diseño de SD escalables presenta los siguientes retos:

17

Control de costo de los recursos físicos: para que un sistema con n usuarios sea escalable, la cantidad de recursos físicos necesarios para soportarlo debería ser O(n). Controlar la degradación del rendimiento: Ejm: Los algoritmos que emplean estructuras jerárquicas se comportan mejor frente al crecimiento de la escala, que los algoritmos que emplean estructuras lineales. Evitar

cuellos

de

botella:

los

algoritmos

deberían

ser

descentralizados. Prevenir el desbordamiento de los recursos de software. 3. 5. Tratamiento de Fallos. • Detección

de fallos:

Ejem.

pueden

Se

utilizar

sumas

de

comprobación

(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 diseñarse para tolerar ciertos fallos. Esto implica que los usuarios tendrán también que tolerarlos. • Recuperación de fallos: Implica el diseño de software en el que, tras una caída del servidor, el estado de los datos puede reponerse o retractarse (rollback) a unasituación 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 través 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 idénticas. Transparencia de ubicación: permite acceder a los recursos sin conocer su localización. Transparencia de concurrencia: permite que varios procesos operen concurrentemente sobre recursos compartidos sin interferencia mutua. Transparencia de replicación: 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

reubicación

de

recursos y clientes en un sistema sin afectar la operación de los usuarios y los programas. Transparencia de rendimiento: permite reconfigurar el sistema para mejorar el desempeño según varíe su carga. Transparencia al escalado: permite al sistema y a las aplicaciones expandirse en tamaño sin cambiar la estructura del sistema o los algoritmos de aplicación. ACTIVIDAD  Tome World Wide Web como ejemplo para ilustrarel concepto de compartición 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 están por todas partes, internet permite que los usuarios de todo el mundo accedan a sus servicios donde quieran que estén situados. Cada organización 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 pequeños sistemas distribuidos con computadores portátiles y otros dispositivos computacionales pequeños conectados a una red inalámbrica. La compartición de recursos y servicios de red es el principal factor que motiva la construcción de sistemas distribuidos. Recursos como impresoras, archivos, páginas web o registros de base de datos se administran mediante servidores del tipo apropiado. Las infraestructuras físicas y lógicas 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 páginas 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 construcción de los sistemas distribuidos presentan muchos desafíos como la heterogeneidad, extensibilidad, seguridad, escalabilidad, tratamiento de fallas, concurrencia, transparencia los cuales deben ser abordados para su construccion. BIBLIOGRAFIA RECOMENDADA

20

o

George Colouris, “Sistemas Distribuidos” Conceptos y Diseño, Addison Wesley, España 2001 http://www.cdk3.net/

o

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

Un usuario llega a una estación de ferrocarril que no conoce, portando un PDA capaz de conectarse a una red inalámbrica. Sugiera como podría proporcionársele al usuario información sobre los servicios locales y las comodidades de la estación, sin necesidad de insertar el nombre de la estación o sus caracteristicas. ¿Qué dificultades hay que superar?.

o ¿Cuales son las ventajas y desventajas de HTML, URL, HTTP, como tecnologías de base para la consulta y visualización de la información?, ¿Son algunas de estas tecnolgias

adecuadas

como

plataforma

de

computo

cliente servidor en general? o ¿Cómo

podría

sincronizerse

los

relojes

de

dos

computadores unidos por una red local, sin hacer uso de referencia

temporal

externa?,

¿Cómo

podrían

21

sincronizarse

los

relojes

de

un

mayor

numero

de

computadores conectados a Internet?.

22

UNIDAD ACADÉMICA Nº 02

MODELOS DE SISTEMAS DISTRIBUIDOS Los sistemas pensados para trabajar en entornos reales deben diseñarse para funcionar correctamente en el rango de circunstancias mas amplio posible y considerando todas las dificultades de amenazas (modos de utilización 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 diseño comunes, en este capitulo se presenta las propiedades y temas de diseño comunes para los sistemas distribuidos bajo la forma de de modelos descriptivos. Cada modelo está pensado para proporcionar una descripción abstracta, simplificada pero consistente, de cada aspecto relevante del diseño de un sistema distribuido. En los modelos de Sistemas Distribuidos tenemos 2 tipos: •

Los modelos Arquitectónicos

•

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 arquitectónicos de Sistema Distribuidos y sus variantes. •

Definir y describir los

modelos fundamentales de

Sistemas Distribuidos. •

Realizar ejemplos de Sistemas Distribuidos arquitectónicos y fundamentales.

23

2.1 MODELOS ARQUITECTÓNICOS La arquitectura de un sistema es su estructura en términos 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 diseño arquitectónico de un edificio

tiene

aspectos

similares

y

determina

no

solo

su

apariencia, sino también su estructura general y su estilo arquitectónico (gótico, neoclásico, moderno), proporcionando un marco de referencia consistente para el diseño. Un Modelo Arquitectónico de un Sistema Distribuido, trata sobre la colocación de sus partes y las relaciones entre ellas, también simplifica

y

abstrae,

inicialmente

las

funciones

de

los

componentes individuales de dicho sistema y posteriormente considera 2 criterios:  La ubicación de los componentes en la red de computadores, buscando definir patrones utilizables para la distribución de datos y carga de trabajo. 

Las

interrelaciones

entre

los

componentes,

funcionales y los patrones de comunicación

sus

papeles

entre ellos el

modelo cliente-servidor y el modelo de procesos de ¨igual a igual¨ (peer to peer). 2.1.1 CAPAS DE SOFTWARE El término arquitectura de software se refería inicialmente a la estructuración 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 más bajas proporcionan servicios a las

capas que están sobre ellas, y son implementadas independientemente

en

cada

computador,

24

proporcionando una interfaz de programación del sistema a un nivel que facilita la comunicación y coordinación entre procesos. Ejemplo: Windows, Linux, Solaris etc. La plataforma 

Contiene los servicios propios de cada computadora concreta.

 Depende del Hardware y del Sistema Operativo Aplicación de servicios Middleware Sistema Operativo Computador y

Plataforma

Hw. de red ♦

Figura 1. Capas de servicio software y hardware en los sistemas distribuidos Middleware:

Es una capa de software cuyo propósito es enmascarar la heterogeneidad

y

proporcionar

un

modelo

de

programación conveniente para los programadores de aplicaciones. Aplicación de servicios

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

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

25

En particular mejora el nivel de las actividades de comunicación de los procesos de aplicación soportando abstracciones como: llamadas a procedimientos remotos, comunicación entre un grupo de procesos, etc. Ejem: Sun RPC (llamadas a procedimientos remotos), CORBA

(middleware

orientado

a

objeto),

Java

RMI

(invocación de objetos remotos en Java), DCOM (Modelo común de objetos distribuidos de Microsoft). El

middleware

también

puede

proporcionar

otros

servicios, aparte de la comunicación, para su uso en programas de aplicación. Por

ejemplo:

gestión

de

nombres,

seguridad,

almacenamiento persistente, etc. El middleware  Permite enmascarar la heterogeneidad.  Puede dar un modelo y una interfaz de programación utilizable  Puede soportar abstracciones como: –

Procedimientos de invocación remota (RPC).

– Comunicación entre grupos de procesos. –

Eventos, replicación, servicios multimedia, etc.

¿Qué forma tiene el Middleware? – Bibliotecas adicionales Procedimientos de invocación remota(RPC). Objetos Remotos (RMI, CORBA) – Herramientas de Programación. Lenguajes

de

definición

de

Interfaces

+

compiladores para ellos. – Servicios Básicos de ayuda Servicio de Nombres para buscar objetos De notificación de eventos De control de Transacciones, etc. ¿Qué limitaciones impone?

26

–

Se incrementa la complejidad arquitectónica. Hay mas niveles

–

Hay que aprender más 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 división de responsabilidades entre los componentes del sistema (aplicaciones, servidores y otros procesos) y la ubicación de los componentes en la red es el aspecto más importante en el diseño de un sistema distribuido. Sus implicancias fundamentales están en las prestaciones, fiabilidad y seguridad del sistema resultante. Principales modelos arquitectónicos. • Modelo cliente servidor • Múltiples 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 máquina del cliente. Tanto servidores

como

clientes

pueden

ser

iterativos

o

concurrentes. El más común 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 múltiples servidores. Los

servicios

procesos

de

pueden servidor

implementarse en

como

computadores

distintos separados

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 distribuírselo entre ellos mismos, o pueden mantener copias replicas de ellos en varias maquinas – Muy usada en DNS, Web y NIS. –

Cache almacena los recursos más 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.

• Servidores Proxy y Caches Cache:

almacén

de

objetos

de

datos

utilizados

recientemente, y se encuentra más próximo que los objetos en sí. Al recibir un objeto nuevo en un computador se añade al almacén de la cache reemplazando si fuera necesario algunos objetos existentes.

28

Figura 5. Un servidor proxy del

Los caches tipo pueden estar ubicados en los clientes o en un web servidor Proxy que se puede compartir desde varios clientes. El propósito 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 6. Como funciona un proxy

• Procesos Peer-to-Peer En esta arquitectura todos los procesos desempeñan tareas semejantes, interactuando cooperativamente como iguales para realizar una actividad distribuida de cómputo sin distinción entre clientes y servidores. Los procesos pares mantienen la consistencia de los recursos y sincroniza las acciones a nivel de aplicación.

Figura 7. Aplicación distribuida basa en proceso de igual a igual

29

Útil al descomponer aplicaciones en tareas coordinadas. Ejemplos:

Cooperación

descentralizados,

y

coordinación,

Coordinación

de

Algoritmos

agendas,

trabajo

colaborativo. 2.1.4 VARIACIONES DEL MODELO CLIENTE SERVIDOR Factores que determinan la variación del modelo cliente servidor: • El uso de código móvil y agente móvil • 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

añadir

o

eliminar

de

una

forma

conveniente los dispositivos móviles

Figura 8. Interfaz de un movilque puede ser enviado de un Código Móvil.dispositivo Es el código

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

30

Clientes Ligeros: en el cliente sólo se ejecuta una interfaz basada en ventanas, mientras que la aplicación si se ejecuta en

un

servidor

remoto,

usualmente

muy

potente

(multiprocesador, clusters, etc.).

Figura 9. Applet del tipo web.

Algunas Posibilidades: Según la ubicación del código del proceso del cliente:  Código estático  Código con movilidad (recolocación del proceso) Según la proporción 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 conexión a la red local 31

 Facilidad de integración con los servicios locales Problemas  Seguridad  Conectividad  Servicio de detección.

Figura 11. Intercomunicacion espontanea

Según en el diseño un hotel de la Interfaz entre procesos 

Interfaz estático (interfaz orientado al llamado a procesamiento remoto RPC)

2.1.5

INTERFACES Y OBJETOS Una interfaz de un proceso es la especificación del conjunto de funciones que se pueden invocar sobre él. En lenguajes orientados a objetos, los procesos distribuidos pueden ser construidos de una forma más orientada al objeto. Las referencias a estos objetos se pasan a otros procesos para que se pueda acceder a sus métodos de forma remota. Esta es la aproximación adoptada por CORBA y Java RMI.

2.1.6

REQUISITOS PARA EL DISEÑO 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 pequeña (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

críticos

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 límites. El satisfacer tales exigencias depende de la disponibilidad de los recursos en los instantes adecuados. Cada recurso crítico debe reservarse para las aplicaciones que requieren QoS. Los administradores de los recursos deben proporcionar la garantía. 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 comunicación se

emplean otras técnicas. Ejem. Retransmitir el mensaje. Seguridad Necesidad de ubicar datos y otros recursos sensibles sólo en aquellos computadores equipados de un modo eficaz contra el ataque. 33

34

2.2 MODELOS FUNDAMENTALES Los modelos fundamentales están implicados en una descripción más formal de las propiedades que son comunes en los modelos arquitectónicos. Ayudan a localizar los problemas clave para los diseñadores de Sistemas Distribuidos. Su propósito es especificar los problemas, dificultades y amenazas que deben superarse para desarrollar sistemas distribuidos fiables. Principales modelos •

De Interacción

•

De Fallo

•

De seguridad

2.2.1. Modelo de Interacción Trata sobre el rendimiento y sobre la dificultad de poner límites temporales en un sistema distribuido. La forma en que se produce el “paso de mensajes” entre los procesos restringe el modo de operación

Figura 12. Modelo de iteraccion de un Sistema Distribuido

En la comunicación hay retrasos. El modelo estudia cómo afectan estos retrasos la coordinación de los procesos. Entonces encontramos problemas de 2 tipos El Rendimiento de los canales de comunicaciones:

a. •

Latencia: retardo entre el envío de un mensaje por un proceso y su recepción por otro.

35

•

Ancho de banda: cantidad total de información que se puede transmitir en un momento dado

•

Jitter o fluctuación: variación en el tiempo invertido en completar el reparto de una serie de mensajes.

b.

Problemas presentados en la noción de Tiempo: •

Derivas Diferentes (diferencia de horaria)

•

Tasas de deriva Diferentes (Ritmo de deriva)

2.1.1.1 Variantes del Modelo de Interacción Sistemas distribuidos síncronos •

El tiempo de ejecución de cada etapa de un

proceso tiene límites superior e inferior conocidos. •

Cada mensaje se recibe en un tiempo limitado

conocido. •

Cada proceso tiene un reloj local cuya tasa de

deriva sobre el tiempo real tiene un límite conocido. •

Es posible sugerir valores para esos límites

pero es difícil obtener valores realistas y dar garantías sobre los valores elegidos. •

Se pueden tener timeouts. Cuando expiran

significa que ha fallado el proceso. •

Hay que garantizar ciclos suficientes de

procesador, capacidad de red y proveer relojes con tasa de deriva limitadas. Sistemas distribuidos asíncronos. Son aquellos donde no existen limitaciones sobre: •

La velocidad de procesamiento

•

Los retardos de transmisión de mensajes

•

Las tasas de deriva del reloj.

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

36

Ordenamiento de Eventos Aún cuando no hay relojes precisos la ejecución de un sistema se puede describir en términos de los eventos y su ordenación. Ejemplo: 1. X envía un mensaje de reunión 2. Y y Z responden 3. X envía 4. Y lee y responde 5. Z lee X, y Y envía 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 especificación precisa de los fallos que se pueden producir en procesos y en canales de comunicación. Fallos por omisión •

De procesos

•

De comunicaciones.

Fallos de procesos Ruptura accidentada del procesamiento. Es deseable si el resto de los procesos que interactúan con el proceso interrumpido, o bien funcionan correctamente o se detienen. El método de detección de ruptura descansa en timeouts. Fail- Stop: es cuando el resto de los procesos puede detectar con certeza que cierto proceso interrumpió su ejecución. Se puede detectar en un sistema síncrono por los timeouts. Fallos por omisión de comunicaciones. •

Fallos por omisión de envíos.

•

Pérdida de mensajes entre los buffers.

•

Fallos por omisión de recepción. Proceso p

Proceso q

Envia m

Recibe

{

}

Fallos por omisi de recepci.

Canal de Comunicaci

Fallos por omisi de envio.

Fallos por Omisi del canal

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

Enmascaramiento de fallos • Ocultar el fallo. • Convertirlo en un tipo razonable Fiabilidad

y

comunicación

uno

a

uno.

El

término

comunicación fiable se define en términos de validez e integridad.

39

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

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

• Amenazas de Integridad • Protocolos que retransmiten pero no usan números de secuencia para evitar que el mismo mensaje llegue duplicado. • Usuarios mal intencionados que insertan mensajes inválidos,

repiten

mensajes

antiguos

o

modifican

mensajes auténticos. 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 distribuidos

Protección de Objetos • Los objetos pueden contener datos privados y públicos 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.

40

• A cada invocación 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 invocación 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

Objeto

Invocaci

Client e

Servidor

Resultado Principal (cliente)

Principal (servidor)

Red

Figura 17. Objetos y principales

Asegurar procesos y sus interacciones • Cierto tipo de aplicaciones son más 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.

• Cómo

podemos

analizar

estas

amenazas

para

derrotarlas?. Modelo de amenazas de seguridad El enemigo: es capaz de enviar cualquier mensaje a cualquier proceso y también de leer o copiar cualquier mensaje entre un par de procesos. El ataque puede venir de un computador legítimamente

conectado

o

de

una

máquina

no

Copia de m autorizada. El enemigo

Proceso P

m

m` ^

Canal de comunicaci

Proceso Q 41

Figura 18. El enemigo

Cómo se pueden vencer las amenazas de seguridad? • Criptografía y secretos compartidos • Autenticación • 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 información se basan en multiples servidores, el uso de particiones sobre los datos y la replicación 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 código de un porceso a otro ha desembocado en algunas variantes del modelo cliente servidor, El ejemplo mas común de esto es el Apple cuyo código 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 básicos con que se construyen los sistemas distribuidos. El modelo de interaccion tiene que ver con las prestaciones de los procesos y los canales de comunicación y con la ausencia de un reloj global. También define un sistema asíncrono como uno en el que no hay límites en el tiempo de ejecución 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 comunicación básicos de un sistema distribuido. El enmascaramiento es una técnica con la que se construye un servicio más fiable sobre otro menos fiable, de modo que se enmascaran algunos fallos de este último en particular, se puede construir un servicio de comunicación fiable desde un canal de comunicación básico simplemente enmascarando sus fallos. El modelo de seguridad identifica las posibles amenazas a los procesos y los canales de comunicación 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

o

George Colouris, “Sistemas Distribuidos” Conceptos y Diseño, Addison Wesley, España 2001 http://www.cdk3.net/

o

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 búsqueda 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. ¿Cuáles son los requisitos de sincronización 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 idéntico 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 aplicación

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 ACADÉMICA 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

comportamiento

de

de

las

los

redes

sitemas

distribuidos. Los cambios en las necesidades de los usuarios han producido la irrupción de las redes inalámbricas 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 técnicas de interconexión 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 comunicación 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

y

direccionamiento de puertos CONCEPTOS GENERALES DE LA COMUNICACIÓN POR COMPUTADORAS. 1. ELEMENTOS DELA COMUNICACIÓN Para que exista comunicación deben existir los siguientes elementos: 

Origen del mensaje



Canal de transmisión



Destino del mensaje

La comunicación comienza con un mensaje o información que se debe enviar desde una persona o dispositivo a otro. Las personas intercambian ideas mediante diversos métodos de comunicación. Todos estos métodos tienen tres elementos en común. El primero de estos elementos es el origen del mensaje o emisor. Los orígenes de los mensajes son las personas o los dispositivos electrónicos que deben enviar un mensaje a otras personas o dispositivos. El segundo elemento de la comunicación 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 Comunicación 47

En teoría, una comunicación simple, como un video musical o un e-mail puede enviarse a través 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 ningún otro dispositivo podrá enviar o recibir mensajes en la misma red mientras esta transferencia de datos está en progreso. Estos grandes streams de datos originarán retrasos importantes. Además,

si

falló

un

enlace

en

la

infraestructura

de

red

interconectada durante la transmisión, se perderá todo el mensaje y tendrá que retransmitirse por completo. Un mejor enfoque para enviar datos a través de la red es dividir los datos en partes más pequeñas y más manejables. La división del stream de datos en partes más pequeñas se denomina segmentación. La segmentación de mensajes tiene dos beneficios principales. Primero: al enviar partes individuales más pequeñas 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 multiplexación. Segundo: la segmentación puede aumentar la confiabilidad de las comunicaciones de red. No es necesario que las partes separadas de cada mensaje sigan el mismo recorrido a través de la red desde el origen hasta el destino. Si una ruta en particular se satura con el tráfico de datos o falla, las partes individuales del mensaje aún pueden direccionarse hacia el destino mediante los recorridos alternativos. Si parte del mensaje no logra llegar al destino, sólo 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 físicos 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 través de la red. Para distinguir un host de otro, cada host en la red se identifica por una dirección. Cuando un host inicia una comunicación, utiliza la dirección del host de destino para especificar dónde debe ser enviado el mensaje. Ejemplos:  Computadoras (estaciones de trabajo, computadoras portátiles, servidores de archivos, servidores Web)  Impresoras de red  Teléfonos VoIP  Cámaras de seguridad  Dispositivos móviles de mano (como escáneres de barras inalámbricos, 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 información y servicios, como e-mail o páginas Web, a otros hosts en la red, Los clientes son hosts que tienen software instalado 50

que les permite solicitar y mostrar la información obtenida del servidor. 2.1.2

Dispositivos Intermedios Las redes dependen de dispositivos intermediarios para proporcionar conectividad y para trabajar detrás de escena y garantizar que los datos fluyan a través 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 inalámbricos),

•

Dispositivos de internetworking (routers),

•

Servidores de comunicación y módems.

•

Dispositivos de seguridad (firewalls), etc.

La administración de datos mientras fluyen a través de la red

también

es

una

función

de

los

dispositivos

intermediarios. Estos dispositivos utilizan la dirección host de destino, conjuntamente con información sobre las interconexiones de la red, para determinar la ruta que deben tomar los mensajes a través de la red. Los procesos que se ejecutan en los dispositivos de red intermediarios realizan las siguientes funciones: •

Regenerar y retransmitr señales de datos

•

Mantener información sobre qué rutas existen a través de la red y de la internetwork.

•

Notificar a otros dispositivos los errores y las fallas de comunicación,

•

direccionar datos por rutas alternativas cuando existen fallas en un enlace.

•

Clasificar y direccionar mensajes según 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 comunicación a través 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 metálicos dentro de los cables,

•

Fibras de vidrio o plásticas (cable de fibra óptica), y

•

Transmisión inalámbrica.

La codificación de señal que se debe realizar para que el mensaje sea transmitido es diferente para cada tipo de medio. En los hilos metálicos, los datos se codifican dentro de impulsos eléctricos que coinciden con patrones específicos. Las transmisiones por fibra óptica dependen de pulsos de luz, dentro de intervalos de luz visible o infrarroja. En las transmisiones

inalámbricas,

los

patrones

de

ondas

electromagnéticas muestran los distintos valores de bits. Los diferentes tipos de medios de red tienen diferentes características y beneficios. No todos los medios de red tienen las mismas características ni son adecuados para el mismo fin.

52

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

Luego tenemos que existen reglas para que se realice la comunicación, 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

conversación cara a carade dos personas, es posible que un protocolo para comunicar establezca que para indicar que la conversación ha finalizado, el emisor debe permanecer en silencio durante dos segundos completos. Sin embargo, este protocolo no especifica cómo el emisor debe permanecer en silencio durante los dos segundos. Los protocolos generalmente no describen cómo cumplir una función en particular. Al describir solamente qué funciones se requieren de una regla de comunicación en particular pero no cómo realizarlas, es posible que la implementación de un protocolo en particular sea independiente de la tecnología. Por ejemplo en un servidor Web, HTTP no especifica qué lenguaje de programación se utiliza para crear el explorador, qué software de servidor Web se debe utilizar para servir las páginas Web, sobre qué sistema operativo se ejecuta el software o los requisitos necesarios para mostrar el explorador. Tampoco describe cómo 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 teléfonos móviles o PDA, pueden acceder a una página Web almacenada en cualquier tipo de servidor Web que utilice cualquier tipo de sistema operativo desde cualquier lugar de Internet. Para visualizar la interacción entre varios protocolos, es común 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í también la interacción de las capas sobre y debajo de él. Existen dos tipos básicos 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 década de los setenta y se conoce con el nombre de modelo de Internet. Define cuatro categorías de funciones que deben tener lugar para que las comunicaciones sean exitosas. La arquitectura de la suite de protocolos TCP/IP

sigue la

estructura de este modelo. Por esto, es común que al modelo de Internet se lo conozca como modelo TCP/IP.

54

Figura 5. Modelo

El modelo TCP/IP describe la funcionalidad de los protocolos TCP/IP

que forman la suite de protocolos TCP/IP. Esos protocolos, que se implementan tanto en el host emisor como en el receptor, interactúan para proporcionar la entrega de aplicaciones de extremo a extremo a través de una red. Un proceso completo de comunicación incluye estos pasos: o

Creación de datos a nivel de la capa de aplicación del dispositivo final origen.

o

Segmentación y encapsulación de datos cuando pasan por la stack de protocolos en el dispositivo final de origen.

o

Generación de los datos sobre el medio en la capa de acceso a la red de la stack.

o

Transporte de los datos a través de la internetwork, que consiste de los medios y de cualquier dispositivo intermediario.

o

Recepción de los datos en la capa de acceso a la red del dispositivo final de destino.

o

Desencapsulación y rearmado de los datos cuando pasan por la stack en el dispositivo final.

o

Traspaso de estos datos a la aplicación de destino en la capa de aplicación del dispositivo final de destino

55

Figura 6. Transporte de un paquete

Encapsulamiento de Datos Mientras los datos de la aplicación bajan al stack del protocolo y se transmiten por los medios de la red, varios protocolos le agregan información en cada nivel. Esto comúnmente se conoce como proceso de encapsulación. PROCESOS DE ENCAPSULAMIENTO DE DATOS

Figura 7. Encapsulamiento de Datos

La forma que adopta una sección de datos en cualquier capa se denomina Unidad de datos del protocolo (PDU). Durante la encapsulación, 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 convención universal de nombres para las PDU, en este curso se denominan de acuerdo con los protocolos de la suite TCP/IP.  Datos: el término general para las PDU que se utilizan en la capa de aplicación.  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 físicamente datos a través de un medio.

Figura 8. Direccionamiento de PDU

Cuando se envían 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 envío de una página Web HTML a un cliente. El protocolo de la capa Aplicación, HTTP, comienza el proceso entregando los datos de la página Web con formato HTML a la capa Transporte. Allí, los datos de aplicación se dividen en segmentos TCP. A cada segmento TCP se le otorga una etiqueta, denominada encabezado, que contiene información sobre qué procesos que se ejecutan en la computadora de destino deben recibir el mensaje. También contiene la información

para

habilitar

el

proceso

de

destino

para

reensamblar nuevamente los datos a su formato original. La capa Transporte encapsula los datos HTML de la página Web dentro del segmento y los envía 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 rótulo denominado encabezado IP. El encabezado IP

57

contiene las direcciones IP de host de origen y de destino, como también la información necesaria para entregar el paquete a su correspondiente proceso de destino. Luego el paquete IP se envía al protocolo Ethernet de la capa de acceso a la red, donde se encapsula en un encabezado de trama y en un tráiler. Cada encabezado de trama contiene una dirección física de origen y de destino. La dirección física identifica de forma exclusiva los dispositivos en la red local. El tráiler

contiene

información

de

verificación

de

errores.

Finalmente, los bits se codifican en el medio Ethernet mediante el servidor NIC.

Figura 9. Operación de protocolo de envio y recepcion de

3.2

mensajes Modelo OSI

Inicialmente, el modelo OSI fue diseñado por la Organización Internacional

para

la

Estandarización

(ISO,

International

Organization for Standardization) para proporcionar un marco sobre el cual crear una suite de protocolos de sistemas abiertos. La visión 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 proporción en la que se expandió ocasionaron que el desarrollo y la aceptación de la

58

suite de protocolos OSI quedaran atrás. 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. Comunicación capa a capa El modelo OSI describe los procesos de codificación, formateo,

segmentación y encapsulación de datos para transmitir por la red. Un flujo de datos que se envía 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 información viajan por una red en cualquier momento. Es muy importante que cada parte

de

los

datos

contenga

suficiente

información

de

identificación para llegar al destino correcto. Existen varios tipos de direcciones que deben incluirse para entregar satisfactoriamente los datos desde una aplicación de origen que se ejecuta en un host hasta la aplicación de destino correcta que se ejecuta en otro.

59

Durante

el

proceso

de

encapsulación,

se

agregan

identificadores de dirección a los datos mientras Figura 11. Direccionamiento por bajan al stack del protocolo encapas el host de origen. Así como existen múltiples capas de protocolos que preparan los datos para transmitirlos a sus destinos, existen múltiples capas de direccionamiento para asegurar la entrega. El primer identificador, la dirección física 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 dirección de la Capa 2 es exclusiva en la red local y representa la dirección del dispositivo final en el medio físico. En una LAN que utiliza Ethernet, esta dirección se denomina dirección 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 información de la dirección 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 están diseñados principalmente para mover datos desde una red local a otra red local dentro de una internetwork. Mientras las direcciones de Capa 2 sólo 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 dirección IP host contiene información sobre la red en la que está ubicado el host. En los límites de cada red local, un dispositivo de red intermediario, por lo general un router, desencapsula la trama para leer la dirección host de destino contenida en el

60

encabezado del paquete, la PDU de Capa 3. Los routers utilizan la porción del identificador de red de esta dirección 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 envía 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 información 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 específico 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

simultáneamente. personales

ejecutar La

múltiples

gente

generalmente

que

tiene

un

aplicaciones utiliza

de

red

computadoras

cliente

de

correo

electrónico que se ejecuta al mismo tiempo que el explorador Web, un programa de mensajería instantánea, algún streaming media y, tal vez, incluso algún juego. Todos estos programas ejecutándose en forma separada son ejemplos de procesos individuales. Ver una página Web invoca al menos un proceso de red. Hacer clic en un hipervínculo hace que un explorador Web se

61

comunique con un servidor Web. Al mismo tiempo, en segundo plano, es posible que cliente de correo electrónico esté enviando o recibiendo un e-mail y un colega o amigo enviando un mensaje instantáneo. Piense en una computadora que tiene sólo una interfaz de red. Todos los streams de datos creados por las aplicaciones que se están ejecutando en la PC ingresan y salen a través de esa sola interfaz, sin embargo los mensajes instantáneos 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 aplicación o servicio es representado por un número de puerto en la Capa 4. Un diálogo único entre dispositivos se identifica con un par de números de puerto de origen y de destino de Capa 4 que son representativos de las dos aplicaciones de comunicación. Cuando los datos se reciben en el host, se examina el número de puerto para determinar qué aplicación o proceso es el destino correcto de los datos

Figura 13. Direccionamiento en la capa lo 4 mejor para garantizar la comunicación Cada capa ofrece

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 segmentación de datos y brinda el control necesario para reensamblar las partes dentro de los distintos

streams

de

comunicación.

Las

responsabilidades

principales que debe cumplir son: •

seguimiento

de

la

comunicación

individual

entre

aplicaciones en los hosts origen y destino, •

segmentación de datos y gestión de cada porción,

•

reensamble

de

segmentos

en

flujos

de

datos

de

aplicación, e • 4.1 4.1.1

identificación de las diferentes aplicaciones. Responsabilidades de la capa de Red Seguimiento de Conversaciones individuales: Cualquier host puede tener múltiples aplicaciones que se están comunicando a través de la red. Cada una de estas aplicaciones se comunicará con una o más aplicaciones en hosts remotos. Es responsabilidad de la capa de Transporte

mantener

los

diversos

streams

de

comunicación entre estas aplicaciones. 4.1.2 Segmentación de datos: Debido a que cada aplicación genera un stream de datos para enviar a una aplicación 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

de

Aplicación.

Esto

incluye

la

encapsulación

necesaria en cada sección de datos. Cada sección de datos

de

aplicación

requiere

que

se

agreguen

encabezados en la capa de Transporte para indicar la comunicación a la cual está asociada. 4.1.3

Reensamble de segmentos: En el host de recepción, cada sección de datos puede ser direccionada a la aplicación adecuada. Además, estas

63

secciones

de

datos

individuales

también

deben

reconstruirse para generar un stream completo de datos que sea útil para la capa de Aplicación. Los protocolos de la capa de Transporte describen cómo se utiliza la información

de

reensamblar las

encabezado secciones

de

de

dicha

datos

capa

en

para

streams

y

enviarlas a la capa de Aplicación. 4.1.4

Identificación de las aplicaciones: Para

poder

transferir

los

streams

de

datos

a

las

aplicaciones adecuadas, la capa de Transporte debe identificar la aplicación de destino. Para lograr esto, la capa de Transporte asigna un identificador a la aplicación. Los protocolos TCP/IP denominan a este identificador número de puerto. A todos los procesos de software que requieran acceder a la red se les asigna un número de puerto exclusivo en ese host. Este número de puerto se utiliza en el encabezado de la capa de Transporte para indicar con qué aplicación está asociada esa sección de datos. La capa de Transporte es el enlace entre la capa de Aplicación y las capas inferiores, que son responsables de la transmisión 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 través del medio. Las aplicaciones no necesitan conocer los detalles de operación de la red en uso. Las aplicaciones generan datos que se envían desde una aplicación 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 congestión en un enlace o el tamaño de la red. Además, las capas inferiores no tienen conocimiento de que existen varias aplicaciones que envían 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 aplicación adecuada. Los requerimientos de datos varían, 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 específica 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 aplicación puede tolerar cierta pérdida de datos durante la transmisión a través 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 sólo las funciones básicas 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 comunicación más sólida entre aplicaciones

de

la

capa

de

Transporte,

representan

la

necesidad de utilizar recursos adicionales y generan un mayor número 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 más comunes de la capa de Transporte del conjunto de protocolos TCP/IP son el Protocolo de control de transmisión (TCP) y el Protocolos de datagramas de usuario (UDP).

Ambos

protocolos

gestionan

la

comunicación

de

múltiples aplicaciones. Las diferencias entre ellos son las funciones específicas que cada uno implementa. 4.2.1

Protocolo de datagramas de usuario (UDP)

UDP es un protocolo simple, sin conexión, descrito en la RFC 768. Cuenta con la ventaja de proveer la entrega de datos sin utilizar muchos recursos. Las porciones de comunicación protocolo

de

en

UDP

la

capa

se de

llaman

datagramas.

Transporte

envía

Este estos

datagramas como "maximo esfuerzo". Entre las aplicaciones que utilizan UDP se incluyen: Sistema de nombres de dominios (DNS), streaming de vídeo, y Voz sobre IP (VoIP). 4.2.2

Protocolo de control de transmisión (TCP)

TCP es un protocolo orientado a la conexión, descrito en la RFC 793. TCP incurre en el uso adicional de recursos para agregar

funciones.

Las

funciones

adicionales

especificadas por TCP están 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

Aplicación, mientras que cada segmento UDP sólo posee 8 bytes

de

carga.

Ver

la

figura

para

obtener

una

comparación. Las aplicaciones que utilizan TCP son: exploradores Web, e-mail, y transferencia de archivos

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

envía e-mails, mensajes instantáneos, páginas Web y llamadas telefónicas VoIP de manera simultánea. 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 aplicación, tanto TCP como UDP cuentan con campos de encabezado que pueden identificar de manera exclusiva estas aplicaciones. Estos identificadores únicos son los números de los puertos. En el encabezado de cada segmento o datagrama hay un puerto de origen y destino. El número de puerto de origen es el número para esta comunicación asociado con la aplicación que origina la comunicación en el host local. El número de puerto de destino es el número para esta comunicación asociado con la aplicación de destino en el host remoto. Los números de puerto se asignan de varias maneras, en función de si el mensaje es una solicitud o una respuesta. Mientras que los procesos en el servidor poseen números de

67

puertos estáticos asignados a ellos, los clientes eligen un número de puerto de forma dinámica para cada conversación. Cuando una aplicación de cliente envía una solicitud a una aplicación de servidor, el puerto de destino contenido en el encabezado es el número de puerto que se asigna al daemon de servicio que se ejecuta en el host remoto. El software del cliente debe conocer el número de puerto asociado con el proceso del servidor en el host remoto. Este número de puerto de

destino

se

puede

configurar,

ya

sea

de

forma

predeterminada o manual. Por ejemplo, cuando una aplicación de explorador Web realiza una solicitud a un servidor Web, el explorador utiliza TCP y el número 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 número de puerto. El número de puerto actúa como dirección de retorno para la aplicación que realiza la solicitud. La capa de Transporte mantiene un seguimiento de este puerto y de la aplicación que generó la solicitud, de manera que cuando se devuelva una respuesta, pueda ser enviada a la aplicación correcta. El número de puerto de la aplicación que realiza la solicitud se utiliza como número de puerto de destino en la respuesta que vuelve del servidor. La combinación del número de puerto de la capa de Transporte y de la dirección IP de la capa de Red asignada al host identifica de manera exclusiva un proceso en particular que se ejecuta en un dispositivo host específico. Esta combinación se denomina socket. Un par de sockets, que

68

consiste en las direcciones IP y los números de puerto de origen y de destino, también es exclusivo e identifica la conversación entre dos hosts. Ejemplo: una solicitud de página Web HTTP que se envía a un servidor Web (puerto 80) y que se ejecuta en un host con una dirección IPv4 de Capa 3 192.168.1.20 será destinada al socket 192.168.1.20:80. Si el explorador Web que solicita la página Web se ejecuta en el host 192.168.100.48 y el número de puerto dinámico asignado al explorador Web es 49152,

el

socket

para

la

página

Web

será

192.168.100.48:49152, tal como se muestra en la fig.16. Se debe considerar que TCP no envía datos a la red hasta que advierte que el destino está preparado para recibirlos. Luego TCP administra el flujo de datos y reenvía 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 dinámico de ventanas para llevar a cabo

estas

funciones

confiables.

Sin

embargo,

esta

confiabilidad representa cierta sobrecarga en la red en términos de encabezados de segmentos más grandes y mayor tráfico de red entre el origen y el destino que administra el transporte de datos.

69

Figura 16. Direccionamiento de puertos

Si los datos de aplicación necesitan ser entregados a la red de manera rápida 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

recepción

de

datagramas en el destino, sólo envía los datagramas recibidos a la capa de Aplicación a medida que llegan, y no reenvía datagramas

perdidos.

Sin

embargo,

esto

no

significa

necesariamente que la comunicación no es confiable; puede haber mecanismos en los protocolos y servicios de la capa de Aplicación que procesan datagramas perdidos o demorados si la aplicación cuenta con esos requerimientos. El desarrollador de la aplicación toma una decisión 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 tendrán influencia en el rendimiento. ACTIVIDAD 

Un cliente envía 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 operación en cada uno de los siguientes casos: o

Utilizando

una

comunicación

de

datagramas

no

orientado a conexión (por ejemplo UDP). o

Utilizando una comunicación orientada a conexión (por ejemplo TCP).

70

o

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 conexión (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 atención en los conceptos y en las técnicas 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 diseñador 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 difusión de paquetes en un medio común, y Ethernet es la tecnolgia dominante. Las redes área amplia se basan en la conmutación de paquetes para encaminar los paquetes hacia sus destinos a través 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 básico 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 países

71

diferentes.

Los

estándares

de

internet

incluyen

varios

protocolos del nivel de aplicación que resultan adecuadas para su uso en aplicaciones distribuidas a gran escala.IPv6 tiene el espacio de direccionamiento necesario para la evolución futura de internet y aporta los medios para satisfacer los requisitos de las nuevas aplicaciones tales como calidad de servicio y seguridad. Los usuarios móviles tiene soporte de IP móvil 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. Transmisión de Datos y Redes de Computadores. Pearson. Prentice Hall. (2003) o CISCO Systems, Guía del 1er año CCNA1 y CCNA2. Academia de Networking de Cisco Systems. CiscoPress. Editorial Pearson. Madrid(2005) o

George Colouris, “Sistemas Distribuidos” Conceptos y Diseño, Addison Wesley, España 2001 http://www.cdk3.net/

o

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 información de encaminamiento para

72

todos

los

nodos.

¿Cómo

resuelve

el

esquema

de

encaminamiento de Internet este problema? o ¿Cuál 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 debería interceptar? o

¿Explique el proceso de encapsulamiento?

o

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

Figura 17. Aplicaciones de internet

UNIDAD ACADÉMICA Nº 04

COMUNICACION ENTRE PROCESOS EN SISTEMAS DISTRIBUIDOS

73

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

Definir, describir que es la comunicación entre procesos en sistemas distribuidos.

•

Definir, describir la comunicación por paso de mensajes

•

Definir y describir el llamado a un procediemiento remoto (RPC)

•

Definir y describir la comunicación Cliente – Servidor.

•

Definir y describir la comunicación en grupo. Aplicaciones, servicios. RMI y RPC Este cap 咜 ulo

{

Protocolo petici respuesta Empaquetado y representaci externa de datos

}

Capas Middleware

UDP y TCP Figura 1. Capas Middleware

¿Qué es un proceso? Es un programa en ejecucion. COMUNICACIÓN

ENTRE

PROCESOS

EN

SISTEMAS

DISTRIBUIDOS Después de haber revizado los

conceptos de

redes para la

comunicacion ahora introduscamonos en nuestro tema comunicación de procesos en Sistemas Distribuidos. El sistema de comunicación es la

espina dorsal de los

Sistemas

Distribuidos.

74

La comunicación entre procesos en S.D. necesita compartir información:

Figura 2. Proceso de compartir informacion

La comunicación entre procesos en un ambiente distribuido no puede hacerse por memoria compartida; la única posibilidad es por intercambio de mensajes.

1

COMUNICACION POR PASO DE MENSAJE La comunicación por paso de mensajes entre dos proceso se puede basar en dos operaciones envía y recibe, definidas en función del destino y del mensaje. Para que un proceso se comunique con otro, el proceso envía un mensaje (secuencia de bytes)

a un destino

y otro proceso en el destino recibe el

mensaje, esta actividad implica la comunicación de datos desde el proceso emisor hasta el proceso receptor, puede implicar además la sincronización de los dos procesos. Características deseables de un buen sistema de paso de mensajes 1.1

Simplicidad

• Simple y fácil de usar (uso directo) • Hacer sin preocuparse de aspectos de la red/sistema 1.2

Semántica uniforme en:

• Comunicaciones locales •

1.3

Comunicaciones remotas Eficiencia

75

Criterio: reducción del número de mensajes intercambiados por que las IPC son costosas. Optimización 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 conexión. −

Optimizar los reconocimientos cuando hay una serie de mensajes entre el send y receive.

1.4

Flexibilidad

Deben permitir alguna clase de control de flujo entre procesos cooperativos,

incluyendo

send/receive

sincrónicos

y

asincrónicos. 1.5

Seguridad − Autenticación

del receptor de un mensaje por el enviador

− Autenticación

del enviador de un mensaje por el receptor

−Encriptación del mensaje 1.6

Confiabilidad

La caída del nodo o enlace implica pérdida de mensaje. Se usan timeouts (duplicación de mensajes) 1.7

Correctitud

Pueden enviarse multicast − Atomicidad − Orden

de despacho

− Persistencia

1.8

Portabilidad

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

76

Heterogeneidad de máquinas

compatibilización de

representación.

2

ESTRUCTURA TIPICA DE MENSAJES El enviador determina el contenido del mensaje. El receptor tiene en cuenta como interpretar los datos Estructura t厓ica de mensaje

Figura 3. Estructura tipica de un mensaje

3 RENDIMIENTO DE UN SISTEMA DISTRIBUIDO El

rendimiento

de

un

sistema

de

computación

distribuida

depende en gran medida de la comunicación rápida entre procesos. Para que la comunicación entre procesos sea rapida depende de dos partes: •

Las primitivas de comunicación entre procesos

•

El protocolo de transporte sobre el cual trabajan esas

primitivas. 3.1

PRIMITIVAS DE COMUNICACIÓN

El paso de mensajes entre un par de procesos se puede basar en dos operaciones primitivas, envía y recibe definidas en función del destino y del mensaje. Para que un proceso se pueda comunicar con otro, el proceso envía 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 semántica sin bloqueo cuando su ejecución no produce un retardo en el proceso que la invoca; de otra manera la primitiva es con bloqueo. Existen básicamente cuatro tipos de comunicación para este tipo de primitivas: 

Send

con

bloqueo

(CPU

inactivo

durante

la

transmisión de los mensajes) 

Send sin bloqueo, sin copia (no se puede sobrescribir hasta que el mensaje haya sido leído)



Send sin bloqueo, con copia (se desperdicia el tiempo del CPU para la copia adicional)



Send sin bloqueo, con interrupción (dificulta la programación).

Figura 4. Mensajes Bloqueantes Vs. No bloqueantes

3.1.2

Primitivas

almacenadas

con

buffer

y

no

almacenadas. Cuando se efectúa un

intercambio de mensajes se

presentan dos casos en relación a donde se va a almacenar la información. En el primero de estos es el proceso servidor es el que destina una área para recibir un mensaje al efectuar la operación

receive

(no

almacenado); mientras que en el segundo el proceso servidor solicita la creación de un buzón para alojar los mensajes que van a ser recibidos mientras los puede procesar (almacenamiento con buffers).

78

En sistemas sin buffer, la ejecución 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 ejecución. Ambos procesos se sincronizan o se encuentran cuando el mensaje es transferido. Los sistemas con buffer son más difíciles de controlar debido a la necesidad de crear, destruir y mantener los buffers.

Figura 5. Transferencia de

3.1.3

mensajes

Primitivas confiables y no confiables

Existen tres distintos enfoques de este problema. El Primero consiste en volver a definir la semántica de mensaje envía (send) para hacerlo no confiable. El sistema no da garantía alguna acerca de la entrega de mensajes. La implantación de una comunicación se deja enteramente en manos de los usuarios El

Segundo

método

exige

que

el

núcleo

de

la

máquina receptora envíe un reconocimiento al núcleo de

la

máquina

emisora. Sólo cuando se reciba este

reconocimiento, el núcleo emisor liberará al proceso usuario (cliente). El reconocimiento va de un núcleo 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 núcleo del servidor, la respuesta del servidor de regreso al

79

cliente es reconocida por el núcleo del cliente. Así una solicitud de respuesta consta de cuatro mensajes. El

Tercer método aprovecha el hecho de que la

comunicación cliente-servidor se estructura como una solicitud del cliente al servidor, seguida de una respuesta del servidor al cliente. En este método, el cliente se bloquea después de enviar un mensaje. El núcleo del servidor no envía 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 núcleo emisor puede volver a enviar la solicitud para protegerse contra la posibilidad de una pérdida del mensaje. Una consideración más dentro de

la

comunicación

por

paso

de

mensajes

es

la

determinación del receptor o receptores de un mensaje. Se tienen tres opciones: • Transmisión a un sólo receptor (unicast) • Transmisión radial (broadcast) • Transmisión radial múltiple (multicast) 3.2

PROTOCOLOS

DE

INTERCOMUNICACIÓN

DE

PROCESOS En el diseño de un protocolo de intercomunicación entre procesos el programador debe considerar lo siguiente: • ¿Quién envía ? • ¿Quién 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 ABSTRACCIÓN EN COMUNICACIÓN CON PASO DE MENSAJES: Diferentes conjuntos de primitivas pueden ser usados en la comunicación entre procesos remotos. Los tres más comunes están basados en:

• Paso de mensajes puro. • Llamado a procedimientos remotos • Transacciones. El

orden

en

la

lista

anterior

indica

que

cada

forma

de

comunicación puede ser construida en base a la anterior. En otras palabras, a mayor número, mayor nivel de abstracción. 4.1 PASO

DE MENSAJES PURO

Un mensaje es una colección de datos de cierto tipo consistente en un encabezado y un cuerpo de longitudes fijas

o

variables,

la

cual

puede

ser manejada por un

proceso y entregada a su destinatario. La

comunicación

orientada a mensajes está íntimamente ligada al modelo cliente-servidor.

El

proceso

cliente

envía

un

mensaje

(petición) a un proceso servidor y espera una respuesta o continúa ejecutándose. Las primitivas de comunicación 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 semánticas de las primitivas: 4.1.1

Direccionamiento:

Para que un cliente pueda enviar un mensaje a un servidor, debe conocer la dirección de éste.

Existen

varios métodos por los que un cliente puede conocer o determinar la dirección del servidor, a continuación se mencionan tres de ellas: 4.1.1.1 Asignación

numérica

fija

predeterminada

82

en este caso la dirección 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

podría

funcionar

en

un

sistema

particularmente sencillo, es necesaria una forma más sofisticada de direccionamiento. Aquí cabe señalar que no se ha determinado que es lo que significa el número asignado, es decir, no especifica si es la identificación de un proceso o de un equipo.

Figura 6. Asignacion fija predeterminada

4.1.1.2 Asignación aleatoria de número de proceso Este método 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 número es muy pequeña. Este método puede utilizarse en sistemas grandes. Sin embargo existe el problema de saber ¿a que máquina enviar el mensaje?. Para ello el emisor podría enviar un paquete especial de localización con la dirección del proceso destino. Puesto que es un paquete de transmisión, será recibido por todas

83

las máquinas de la red. Todos los núcleos verifican si la dirección es la suya y, en caso de que lo sea, regresa el mensaje de aquí estoy con su dirección en la red (número de máquina).

Figura 7. Asignacion Aleatoria de numero de proceso 4.1.1.3

Servidor de nombres

Aun asi el esquema anterior es

transparente, la

transmisión provoca carga adicional en el sistema. Esta carga se puede evitar mediante una máquina adicional

para

la

asociación

a

alto

nivel

(es

decir en ASCII) de los nombres de servicios con las direcciones de las máquinas. 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 números en binario de las máquinas o procesos. Cada vez que se ejecute un cliente, en su primer intento por utilizar el servidor, el cliente envía una solicitud de cuestionamiento a un servidor especial de asociaciones, el cual se conoce como servidor de nombres para pedirle el número de máquina 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 envía una petición 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 cómputo centralizado. Una de las principales ventajas de este esquema de comunicación 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 programación y manejar los tipos de datos de alto nivel traduciéndolos en llamadas a servicios del nivel de Transporte en una red. El mecanismo RPC está asociado con servicios en los niveles de Presentación y Sesión en el modelo OSI: Las primitivas de comunicación 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 comunicación

no

resuelve

problemas

específicos de interacción entre dos procesos (por ejemplo, un retiro de una cuenta bancaria). La interacción entre los procesos puede ser una secuencia de comunicaciones y cálculos. En estas situaciones, es adecuado operar en base a transacciones. El concepto de transacción se desarrolló en sistemas de manejo de bases de datos para mantener la consistencia de la información almacenada. Los mecanismos de transacciones simplifican la construcción de sistemas confiables, y son transparentes para las aplicaciones de usuario (nivel de Sesión en el modelo OSI). En general, el término transacción describe una secuencia de operaciones sobre una o más 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

aseveraciones

cambios

que describen

no

son

los

permitidos.

cambios

Las

permitidos

reciben el nombre de restricciones de consistencia. Propiedades:

Las

transacciones

tienen

las

siguientes

propiedades: • Consistencia.-

debe

mantener

la

consistencia

del

sistema en que se aplica. • Atomicidad.-

debe

ejecutarse

completamente

o

no

ejecutarse. • Durabilidad.- una vez que se completó con buen éxito, una transacción no se puede cancelar (al menos que se aplique otra transacción). Los

sistemas

siguientes recuperación

de

transacciones

deben

operaciones: terminación, (Commitment,

soportar

las

concurrencia

y

Concurrency

and Recovery

[CCR]).

86

5 SINCRONIZACION DE PROCESOS Como mencionamos anteriormente el paso de mensajes entre un par de procesos se puede basar en dos operaciones, envía y recibe definidas en función del destino y del mensaje. Para que un proceso se pueda comunicar con otro, el proceso envía un mensaje (una secuencia de bytes) a un destino y otro proceso en el

destino

recibe

el

mensaje.

Esta

actividad

implica

la

comunicación de datos desde el proceso emisor al proceso receptor y puede implicar además la sincronización de los procesos. Entonces a cada destino de mensajes se asocia una cola, los procesos emisores producen mensajes que serán añadidos a las colas remotas mientras que los procesos receptores locales eliminaran mensajes de las colas locales. La comunicación entre los proceso emisor y receptor puede ser Síncrona o asíncrona. 5.1

Comunicación Síncrona

Lo procesos emisor y receptor

se sincronizan con cada

mensaje, aquí tanto envía como recibe son operaciones bloqueantes, es decir a cada envía 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 Comunicación

Asíncrona

En la comunicación asíncrona la utilización de la operación asíncrona 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 transmisión del mensaje se lleva a cabo en paralelo con el proceso emisor. La operación recibe puede tener variantes bloqueantes y no bloqueantes. Comunicación Síncrona Vs Comunicación Asíncrona

87

Figura 9. Comunicación Sincrona Vs. Comunicación 

Asincrona

Envío no bloqueante (comunicación asíncrona): [1:8] El emisor continúa al pasar el mensaje al núcleo.



Envío

bloqueante

no

fiable

(comunicación

asíncrona):

[1:2:7:8] El emisor espera a que el núcleo transmita por red el mensaje. 

Envío

bloqueante

fiable

(comunicación

asíncrona):

[1:2:3:6:7:8]: El emisor espera a que el núcleo receptor recoge el mensaje. 

Envío

bloqueante

explícito

(comunicación

síncrona):

[1:2:3:4:5:6:7:8]: Idem al anterior, pero es la aplicación receptora la que confirma la recepción. 

Petición-Respuesta

(cliente/servidor)

:

[1:2:3:4::5:6:7:8]: Emisor espera a que el receptor procese la operación. Respuesta puede servir de ACK.

6

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 (dirección de internet, puerto local). Un puerto local es el destino del mensaje dentro de un computador, especificado con un número entero. Un puerto tiene exactamente un receptor pero puede tener muchos emisores. Los procesos pueden utilizar múltiples puertos para recibir los mensajes. Cualquier proceso que conozca el número de puerto apropiado puede enviarle un mensaje. Generalmente los servidores hacen público sus números 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 recepción.

•

Existen buffers para los mensajes.

•

Envio => Colocar mensajes en buffer.

•

Recepción => Sacar mensajes en buffer.

•

Sincronia => bloqueo

•

Asincronía => no hay bloqueo en el envió.

•

Uso de threads (hilos).

Entonces tenemos dos formas de comunicación de procesos, enviando paquetes a través de los protocolos UDP y TCP, ambas utilizan

la

abstracción

de

sockets

(conectores)

para

la

comunicación, estas se encargan de proporcionar los puntos extremos de la comunicación entre procesos.

7

COMUNICACIÓN EN CLIENTE – SERVIDOR Esta forma de comunicación esta orientada a soportar los roles y el intercambio de las interacciones típicas cliente-servidor. En el caso normal, la comunicación petición - respuesta es síncrona, ya que el proceso cliente se bloquea hasta que llega la respuesta del servidor. Esta comunicación también 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 interacción • Cliente: Solicita servicio. Petición: Operación + Datos • Servidor: Proporciona servicio. Respuesta: Resultado

Figura 10. Comunicación peticion respuesta cliente servidor

Modelo con proxy o cache.

89

Tres roles diferentes en la interacción • Cliente: Solicita servicio. • Servidor: Proporciona servicio. • Proxy: Intermediario (si tiene memoria se denomina caché)

Figura 11. Comunicación peticion respuesta con proxy

Modelo Multicapa Servidor puede ser cliente de otro servidor, Típico en aplicaciones web: • Presentación + Lógica de negocio + Acceso a datos • En Microsoft: ASP + COM + ADO • En Java: JSP + EJB + JDBC

Figura 12. Comunicación peticion respuesta Servidor - Servidor

Los modelos de comunicación basados en cliente-servidor con paso de mensajes responden al esqueleto:

90

Figura 13. Esqueleto de la comunicación cliente – Servidor con paso de mensajes 8

COMUNICACIÓN EN GRUPO El intercambio de mensajes entre iguales no es mejor modelo para la comunicación 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,

quizás

para

proporcionar tolerancia a fallos o mejorar la disponibilidad. Resulta mas apropiada una operacion multidifusión, esta es una operación que envía 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 comunicación en grupo Provee confiabilidad, disponibilidad de servicios desde la perspectiva de replicación, la operación más apropiada para comunicar un mensaje a un grupo es el multicasting y la comunicación debe ser hecha de forma transparente Posibles usos en los sistemas distribuidos: • Uso de datos replicados: actualizaciones múltiples. • Uso de servicios replicados. • Operaciones colectivas en cálculo paralelo. La implementación 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 dirección de grupo que los distingue a cada uno. El grupo suele tener carácter dinámico • Se pueden incorporar y retirar procesos del grupo •

Gestión de pertenencia debe coordinarse con la comunicación.

8.1

Modelos de grupos:

• Grupo abierto. 

Proceso externo puede mandar mensaje al grupo 91

Suele usarse para datos o servicios replicados



• Grupo cerrado. 

Sólo 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 recepción de los mensajes Tres alternativas: Orden FIFO: Los mensajes de una misma fuente



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

No hay ninguna garantía sobre mensajes de distintos

emisores 

Ordenación causal: Si entre los mensajes enviados por

dos emisores existe una posible relación “causa-efecto”, todos los procesos del grupo reciben primero el mensaje “causa” y después el mensaje “efecto”. −

Si no hay relación, no se garantiza ningún orden de

entrega −

Concepto

de

“causalidad”

se

estudia

en

capítulo

“Sincronización” 

Ordenación 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

diseño

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 petición-respuesta que se puede construir un protocolo

específico

para

sistemas

distribuidos

efectivo

basándose en datagramas UDP. El mensaje de respuesta se considera como un reconocimiento del mensaje de petición, 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 garantía de que el envio del de un mensaje de petición desencadene la ejecucion de un método, 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 retransmisión de los mensajes, de modo que nos aseguremos que los métodos serna ejecutados. Otras aplicaciones necesitan que los mensajes de respuesta sean transmitidos sin tener que volver a ejecutar el método 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 comunicación entre lo miembros de un grupo de procesos.el protocolo de multidifusión IP proporciona un servicio de multidifusión 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

o

The

Second

Computing

International

and

Conference

Communication

on

Autonomic

Systems,

September

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

George Colouris, “Sistemas Distribuidos” Conceptos y Diseño, Addison Wesley, España 2001 http://www.cdk3.net/

o

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 implementación de un servidor mostrando el modo en que se utilizan las operaciones damePeticion y envíaRespuesta por un servidor que crea un nuevo hilo para ejecutar cada petición de un cliente. Indique el modo en que el servidor copiara la IdPeticion del mensaje de petición en el mensaje de respuesta y como obtendrá la dirección 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 peticiónrespuesta ocultan la heterogeneidad de los sistemas operativos y de las redes de computadores.

94

UNIDAD ACADÉMICA Nº 05

COMUNICACIÓN A BAJO NIVEL, SOCKETS En este capitulo como el que sigue están realcionados con el Middleware, este capitulo se centra en el como el Midleware y los programas de aplicación pueden utilizar los protocolos de la capa de transporte de internet TCP y UDP. En este capitulo se presenta las caracteristicas de comunicación 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

1

COMUNICACIÓN A BAJO NIVEL, SOCKETS 1.1.

¿Qué es un socket?

Un socket es un extremo o un punto terminal de un canal de comunicación entre dos procesos. Obviamente, para formar un canal de comunicación se requieren dos sockets, a los cuales se les conoce como socket local y socket remoto. La comunicación a través de una conexión 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 también 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

conexión

de

red

entre

dos

procesos

queda

completamente definida por una asociación, la cual es una quinteta

formada

de

dirección_local,

la

siguiente

manera:

proceso_local,

{protocolo,

dirección_remota,

puerto_remoto} Un ejemplo de asociación usando la suite de protocolos TCP/IP es el siguiente:

{tcp,

192.43.235.2,

1500,

192.43.235.6,

21} Con base en el concepto de asociación, se puede definir un socket como una media-asociación, la cual tiene dos posibles definiciones: {protocolo, dirección_local, proceso_local} {protocolo, dirección_remota, proceso_remoto}. A una media-asociación también se le llama dirección de transporte.

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 están familiarizados con el manejo de archivos por medio de las operaciones básicas open-read-write-close. La interfaz de

sockets intenta que la

programación en ambientes distribuidos se realice con las

96

mismas operaciones, sólo que en lugar de actuar sobre un archivo actúan sobre un punto terminal de un canal de comunicaciones

(socket).

De

esta

manera

tenemos

las

siguientes analogías:

Figura 2. Tabla de operaciones en archivos Vs

1.3.

Operaciones en Sockets Tipos de sockets

•

Stream (SOCK_STREAM): •

Orientado a conexión.

•

Fiable, se asegura el orden de entrega de mensajes.

•

No

mantiene

separación

entre

mensajes

(tamaño

variable). •

AF_INET se corresponde con el protocolo TCP.

• Datagrama (SOCK_DGRAM): •

Sin conexión.

•

No fiable, no se asegura el orden en la entrega.

•

Mantiene la separación 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.

1.4

Asignamiento de direcciones

Cada socket debe tener asignada una dirección única, esta son dependientes del dominio. • Las direcciones se usan para: •

Asignar una dirección local a un socket (bind).

•

Especificar una dirección remota (connect o sendto).

97

• Se utiliza la estructura genérica de dirección: •

struct sockaddr mi_dir;

• Cada dominio usa una estructura específica. •

Uso de cast en las llamadas.

•

Direcciones en AF_INET (struct sockaddr_in).

•

Direcciones en AF_UNIX (struct sockaddr_un

1.5

Creación de un socket

La función 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 más adecuado.

•

Especificados en /etc/protocols.

El socket creado no tiene dirección asignada. 1.6 Transmisión de datos con streams Envío: • 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.

Recepción: • 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 Envío:Figura 3. Proceso de transmision de datos con Streams

int sendto(int s,char *mem,int tam, int flags,struct sockaddr *dir, int *tam) Recepción: int recvfrom(int s,char *mem,int tam, int flags,struct sockaddr *dir, int *tam) No se establece una conexión (connect/accept) previa. Para usar un socket para transferir basta con crear el socket y reservar la dirección (bind).

Figura 3. Proceso de transmision de datos con 2

datagramas.

PROTOCOLO DE INTERFAZ DE APLICACION (API) DE JAVA PARA LAS DIRECCIONES DE INTERNET Como los paquetes IP que subyacen a TCP y UDP se envían 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.

Comunicación 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

99

transmite un datagrama entre proceso cuando uno lo envía y el otro lo recibe, cualquier proceso que necesite enviar o recibir mensajes debe crear primero un conector asociado a una dirección 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 método recibe devolverá, además del mensaje, la dirección de internet y el puerto del emisor, permitiendo al receptor enviar la correspondiente respuesta. API java para datagramas UDP. La API java proporciona una comunicación 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 dirección internet y el número de puerto local del conector destino. Cadena de bytes

Longitud del

Dirección

Numero de

conteniendo el mensaje

mensaje.

de internet

puerto

Figura 3. Paquete del

Las

datagrama instancias de DatagramaPacket

podrán

ser

transmitidas entre procesos cuando uno la envía 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.

También proporciona un constructor sin argumentos que permite que el sistema elija un puerto de entre los libres. Estos

constructores

pueden

lanzar

una

excepción

SocketException si el puerto ya esta siendo usado o si se especifica un puerto reservado.

100

 Código java de un cliente UDP enviando un mensaje a un servidor y recogiendo su respuesta: El código muestra un programa de un cliente que crea un conector, envía un mensaje a un servidor en el puerto 6789, y después espera una respuesta. Los argumentos para el método 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 dirección 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();} } }



Código java de un servidor UDP recibiendo peticiones y las devuelve al cliente en forma repetitiva. El

código

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 petición 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.

Comunicación de Streams TCP La API para el prtocolo TCP, proporciona la abstracción de un

flujo de bytes (stream) en el que pueden escribirse y leerse datos. La API para la construcción por streams supone que en el momento de establecer una conexión uno de ellos juega el papel de cliente y el otro juega de servidor, aunque después se comuniquen de igual a igual. El rol del cliente implica la creación de un conector, de tipo

stream, sobre cualquier

puerto y la posterior petición de conexión con el servidor en su puerto de servicio. El papel del servidor involucra la creación 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 conexión. En el modelo de Sockets, cuando un servidor acepta una conexión, crea una nuevo conector para mantener la comunicación con el cliente, mientras que se reserva el conector del puerto de servicio para escuchar las peticiones de conexión de otros clientes. El par de conestores el del cliente y el del servidor, se conectan por un par de streams, uno en cada dirección. Asi cada conector tiene su propio stream de entrada y de salida. Uno de los procesos del par puede enviar información al otro escribiendo en un stream de salida, y el otro puede obtener la información leyendo de su stream de entrada.

103

Cuando una aplicación 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 indicación de que el stream ha sido roto. El proceso en el destino puede leer los datos en la cola, pero cualquier lectura después de que la cola este vacía resultara una indicación del final del stream. Cuando un proceso finaliza su ejecución o falla, todos sus conectores se cierran y cualquier proceso que intente con él descubrirá que la conexión se ha roto. Utilización del TCP Muchos

de

los

servicios

utilizados

se

ejecutan

sobre

conexiones TCP, con números de puerto reservados. Entre ellos se encuentran los siguientes. HTTP: El protocolo de transferencia de Hipertexto se utiliza en la comunicación 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 conexión. 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 electrónicos 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á diseñada para ser utilizada por un servidor para crear un conector en el puerto de servidor que escucha las peticiones de conexión de los clientes. Su método Accept toma una petición connect de la cola, o si la cola esta vacía, se bloquea hasta que llega una petición. 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 conexión. 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 también se conecta con el computador remoto especificado con el puerto indicado. Puede lanzar una excepción 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 métodos getinputstream y getoutputstream para accesder a los streams asociados con un conector. 

Un cliente TCP realiza una conexión a un servidor, envía una petición y recibe una respuesta El código muestra un programa cliente donde se le da como argumento al método main un mensaje y nombre DNS del host servidor. El cliente crea un conector ligado al nombre

del

host

y

al

puerto

7896.

Obtiene

DataInputStream y DataOuputStream delos streams de los conectores

de

entrada

y

salida

respectivamente,

y

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 conexión para cada cliente y les reenvía peticiones. El código muestra un programa servidor que en realiza la siguiente acción, abre un conecctor de servidor en su puerto de servicio 7896 y escucha las peticiones de conexión, connect, cuando llega una conexión 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 información almacenada dentro d elos programas de ejecución se representa mediante estructuras de datos (por ejemplo, por conjuntos

de

objetos

interrelacionados)

mientras

que

la

información transportada en los mensajes consiste en secuencias de bytes. Independientemente utilizada,

las

estructuras

de

de la forma de comunicación datos

deben

ser

apalanadas

(covertidas a una secuencia de bytes) antes de su transmisión 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 métodos siguientes: •

Los valores se convierten a un formato externo acordado

antes de la transmisión y se revierte al formato local en la recepción, si los dos computadores son del mismo tipo y lo saben, se puede omitir la transformación al formato externo. •

Los valores se transmiten según el formato del emisor

junto con una indicación 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 transmisión. Para soportar RMI o RPC. Al estándar acordado para la representación de estructuras de datos y valores primitivos se denomina represetacion externa de datos.

107

ACTIVIDAD  Utilice el código 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 debería ser capaz de variar el numero y el tamaño de los mensajesque envía; el servidor debería 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 relación de compromiso entre estos dos protocolos: UDP proporciona la posibilidad de un simple paso de mensajes que adolece de fallos de omisión pero lleva asociada penalización 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 aplicación para UDP proporciona una abstracción del tipo de paso de mensajes, la forma mas simple de comunicación 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 aplicación de TCP proporciona la abstracción de un flujo (stream) de dos direcciones enrte pares de procesos. La información intercambiada consiste en un

108

stream de datos sin limites entre mensajes. Los streams son un bloque

básico

para

la

construcción

de

la

comunicación

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 disposición 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 Diseño, Addison Wesley, España 2001 http://www.cdk3.net/

o

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 código de Streams TCP de modo que el cliente obtenga de forma repetida una línea 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 código de datagrama UDP para construir

un

programa cliente que lea repetidamente una línea 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 código de datagrama UDP, para probar el efecto causado sobre el emisor cuandoel receptor se cae y viceversa.

110

UNIDAD ACADÉMICA Nº 06

OBJETOS DISTRIBUIDOS E INVOCACION REMOTA Los modelos de programación 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 programación 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 métodos Remotos (RMI).

El primero y quizás el mas conocido fue la extensión 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 programación basado en objetos ha sido extendido para permitir que los objetos de diferentes procesos se comuniquen uno con otro por medio de ina invocación a un método remoto (RMI). RMI es una extensión de la invocación a métodos locales que permite que un objeto que vive en un proceso invoque los métodos de un objeto que reside

en otro

proceso.

111

•

El modelo de programación basado en eventos permite a los objetos recibir notificaciones de los eventos que ocurren en otros objetos en los que se ha mantenido el interés. Este modelo ha sido extendido para permitir escribir programas distribuidos basados en eventos.

Notese que usamos el termino RMI para referirnos a una invocación de un método remoto de forma genérica. No debemos confundir con ejemplos particulares de invocación de un método remoto como Java RMI. Idea Central: “¿Cómo hacer para que objetos remotos se comuniquen entre sí?” COMUNICACION DE OBJETOS REMOTOS

Figura 1. Comunicación de Objetos remotos

1. MIDDLEWARE Al software que proporciona un modelo de programación sobre bloques básicos arquitectónicos, 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

}

Capas Middleware

UDP y TCP 112

Figura 2. Capas middleware

Middleware capa que oculta los aspectos de comunicación, paso de mensajes y notificación de eventos, en algunas formas pretende modelar el sistema como si fuese local y no distribuida, y la vez que los componentes del programa estén escritos en diferentes lenguajes de programación teniendo en cuenta lo siguientes criterios: • •

Transparencia Frente a la ubicación Protocolos de comunicación

•

Hardware de los Computadores y empaquetados de datos

•

Sistemas Operativos

•

Uso de diversos lenguajes de programación

2. INTERFACES La

mayoría

de

los

lenguajes

de

programacion

modernos

proporciona medios para organizar un programa en conjuntos de modulos

que

puedan

comunicarse

unos

con

otros.

La

comunicación entre los modulos se puede realizar mediante llamadas

a procedimientos entre los modulos accediendo

directamente a las variables de otro modulo. Para controlar las interacciones posibles entre los modulos, se define explícitamente una interfaz para cada modulo, de tal manera que oculte toda la información excepto aquella que se haga disponible a través de su interfaz. De este modo, mientras la interfaz

permanezca

inalterada, la implementación podrá cambiar sin afectar a los usuarios. Un programa puede organizarse en módulos que se comunican entre sí, cada módulo posee su propia interfaz (Nombre+argumentos+resultado), el algoritmo del módulo puede variar pero no su interfase.

113

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

En los sistemas distribuidos las interfaces tienen las siguientes características. ♦

Cada proceso posee su propio espacio de memoria,

♦

Los módulos locales corren bajo un mismo proceso,

♦

Módulos de dos procesos distintos no pueden acceder a las variables del otro.

♦ Los tipos de datos punteros sólo están 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 módulos disponibles que entregarán dicho servicio Ejemplo: Servidor de archivos x ß Leer(archivo) Escribir(archivo,x) Interfaces Remotas. Cada objeto remoto pone a disposición algunos o todos los métodos para que sean accesibles por otros objetos.Al conjunto de esos métodos accesibles, se les llama interfaz remota.

2.2.

Lenguajes de Definición de Interfaces IDL Corresponde al lenguaje que hace un paralelo o traducción de los tipos de datos de los argumentos y de los resultados,

114

traduciendo tipos de datos remotos a tipos de datos locales. En particular, permite definir interfaces entre los objetos remotos. Lenguajes de definición de interfaces IDL. permite escribir interfaces correspondientes a objetos escritos en diferentes lenguajes (C, C++, Java, COBOL,..) Ejemplo : lenguaje de definición 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 múltiple 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. COMUNICACIÓN 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 métodos. Un objeto se comunica con otro objeto invocando a sus métodos, generalmente pasándole argumentos y recibiendo resultados. Los objetos pueden encapsular sus datos y el código de sus métodos. Algunos lenguajes, por ejemplo Java y C++, permiten que los programadores definan objetos en los que las variables de sus instancias estén accesibles de modo directo. Pero para su uso en un sistema distribuido de objetos, los datos de un objeto solo deberían ser accesibles mediante sus métodos. •

Referencia a Objetos: Forma de acceder a un objeto

•

Interfaces: Métodos (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 código principal del módulo

•

Liberación de Memoria: Cuando un objeto deja de ser accesible

3.2. Objetos Distribuidos En el paradigma de la programación 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 están fraccionados lógicamente, la distribución física de los objetos en deiferentes procesos o computadores de un sistema distribuido es una excepción natural. Un sistema COMUNICACI podría estar compuestos de un conjunto de ﾓ N ENTRE OBJETOS DISTRIBUIDOS objetos locales, ese mismo sistema podría “esparcir” sus objetos en computadores o procesos diferentes,

bajo este

esquema, algunos objetos podrían 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. Comunicación entre objetos

objetos remotos, lo que facilita la programación 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 parámetros o como resultado de las invocaciones.

Figura 5. Referencia a objetos 3.3.2.

remotos Interfaces Remotas.

Solo pone a disposición métodos remotos, Se puede utilizar un IDL, CORBA usa IDEL, JAVA utiliza la misma forma de definir interfaces en un contexto local, Ambos soportan herencias múltiples 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 también remotos. En cada caso se emplea RMI, para tener acceso a los objetos remotos.

Figura 7. Acciones de un objeto 3.3.4.

Compactaciónremoto Automática memoria en un sistema de objetos distribuido Si el lenguaje lo permite, la compactación 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, además 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 Diseño sobre RMI 3.4.1.

Semántica de la invocación RMI. Un objeto local es invocado sólo una vez pero no es así necesariamente con un objeto distribuido. ♦

Reenvío del mensaje de petición (reintento)

♦

Filtrado de mensajes duplicados

♦

Reenvío de mensajes de resultados

119

Figura 8. Invocaciones semanticas

3.4.1.1.

Invocación Pudiera ser: Un método se invoca solamente una vez, después de un time out no se reintenta Es útil en aplicación donde se puede tolerar esos tipos de fallos: ♦ Fallo por omisión de la invocación o de la respuesta ♦

Fallo del servidor donde reside el método remoto

3.4.1.2.

Invocación Al menos una vez: A menos que reciba una respuesta o una excepción, reenvía el mensaje de invocación. ♦ Fallo por caída del servidor ♦

Fallo producto invocar más de una vez un método (pude generar resultados erróneos.

Aceptable si la invocación a un método es idempotente (si se activa más de una vez produce los mismos resultados, ejemplo: saldo de una cuenta) 3.4.1.3.

Invocación Máximo una vez: El proceso envía sólo un mensaje de invocación al método remoto, Recibe una respuesta o una excepción. Es necesario considerar todos los fallos posibles para enmascararlos.

120

3.4.2.

Transparencia. Semántica de invocación, Ubicación, Empaquetado, Paso deMensaje, Recuperación ante fallos, Latencia es mayor al invocar un objeto remoto, Ante una invocación fallida, construir mecanismos para restaurar el estado del objeto remoto

4. IMPLEMENTACIÓN RMI En una invocación de método remoto están involucrados varios objetos y modulos separados. Como se muestra en la figura en la que un objeto A del nivel de aplicación invoca a unmetodo en un objeto remoto B del nivel de aplicación 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 comunicación y referencias remotas y después con el software RMI que se ejecuta en ellas.

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

Modulo de Comunicación:

Figura 9. Invocacion a metodos

Implementa en el envío de mensajes de petición 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 10. Modulo de comunicacion 121

4.2.

Modulo de Referencias Remotas: Traduce referencias locales y remotas, Utiliza una tabla de referencias de métodos locales y métodos 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

4.3.

El software de RMI (capa RMI) Este consiste en una capa de software entre los objetos del nivel de aplicación y los modulos de comunicación y de referencia remota. Proxy : Representa al objeto remoto, redirigiendo mensajes de invocación y entregando resultados o excepciones.Esqueleto del objeto remoto Distribuidor del mensaje de petición/respuesta

5. CASO DE ESTUDIO: RMI DE JAVA. El sistema de Invocación Remota de Métodos (RMI) de Java permite a un objeto que se está ejecutando en una Máquina Virtual Java (VM) llamar a métodos de otro objeto que está en otra VM diferente. Nota:

RMI proporciona comunicación remota entre programas escritos en Java. Si unos de los programas está escrito en otro lenguaje, deberemos considerar la utilización de IDL en su lugar.

5.1. Aplicaciones RMI de Java Las

aplicaciones

programas

RMI

separados:

normalmente un

servidor

comprenden y

un

cliente.

dos Una

aplicación servidor típica crea un montón de objetos remotos, hace accesibles unas referencias a dichos objetos remotos, y espera a que los clientes llamen a estos métodos u objetos remotos. Una aplicación cliente típica obtiene una referencia

122

remota de uno o más objetos remotos en el servidor y llama a sus métodos. RMI proporciona el mecanismo por el que se comunican y se pasan información del cliente al servidor y viceversa. Cuando es una aplicación algunas veces nos referimos a ella como Aplicación 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 operación normal. • Comunicar con Objetos Remotos Los detalles de la comunicación entre objetos remotos son manejados

por

el

RMI;

para

el

programador,

la

comunicación remota se parecerá a una llámada estándard a un método 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 código del objeto, así como la transmisión de sus datos.

Figura 11. Aplicación RMI de java

123

La figura muestra una aplicación 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 método. Esta ilustración también 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 Dinámica de Código

Una de las principales y únicas características de RMI es la habilidad de descargar los bytecodes (o simplemente, código) de una clase de un objeto si la clase no está definida en la máquina virtual del recibidor. Los tipos y comportamientos de un objeto, anteriormente sólo disponibles en una sóla máquina virtual, ahora pueden ser transmitidos a otra máquina 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 máquina virtual. Esto permite que los nuevos tipos sean introducidos en máquinas

virtuales

remotas,

y

así

extender

el

comportamiento de una aplicación dinámicamente. El ejemplo del motor de cálculo de este capítulo utiliza la capacidad

de

RMI

para

introducir

un

nuevo

comportamiento en un programa distribuido. 5.1.2.

Interfaces, Objetos y Métodos Remotos

Una aplicación distribuida construida utilizando RMI de Java,

al

igual

que

otras

aplicaciones

Java,

está

compuesta por interfaces y clases. Los interfaces definen métodos, mientras que las clases implementan los métodos definidos en los interfaces y, quizás, también definen algunos métodos adicionales. En una aplicación

124

distribuida, se asume que algunas implementaciones residen en diferentes máquinas virtuales. Los objetos que tienen métodos que pueden llamarse por distintas máquinas virtuales son los objetos remotos. Un objeto se convierte en remoto implementando un interface remoto, que tenga estas caracterísitcas. •

Un

interface

remoto

desciende

del

interface

java.rmi.Remote. •

Cada método del interface declara que lanza una java.rmi.RemoteException

además

de

cualquier

excepción específica de la aplicación. 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 máquina virtual a otra. En vez de hacer una copia de la implementación del objeto en la máquina virtual que lo recibe, RMI pasa un stub para

un

objeto

remoto.

El

stub

actúa

como

la

representación local o proxy del objeto remoto y básicamente, para el llamador, es la referencia remota. El llamador invoca un método 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

que

el

objeto

remoto

implementa.

Sin

embargo, esto también significa que sólo aquellos métodos

definidos

en

un

interface

remoto

están

disponibles para ser llamados en la máquina virtual que lo recibe. 5.1.3.

Crear Aplicaciones Distribuidas utilizando RMI

Cuando se utiliza RMI para desarrollar una aplicación distribuida, debemos seguir estos pasos generales.

125

•

Diseñar e implementar los componentes de nuestra aplicación distribuida.

•

Compilar los Fuentes y generar stubs.

•

Hacer las clases Accesibles a la Red.

•

Arrancar la Aplicación.

• Construir un Motor de Cálculo Genérico

5.1.4.

Diseñar e implementar los componentes de

nuestra aplicación distribuida. Primero, decidimos la arquitectura de nuestra aplicación y determinamos qué componentes son objetos lcoales y cuales deberían ser accesibles remotamente. Este paso incluye. •

Definir

los

Interfaces

remoto

especifica

los

Remotos.

métodos

Un

que

interface

pueden

ser

llamados remotamente por un cliente. Los clientes programan

los

interfaces

remotos,

no

la

implementación de las clases de dichos interfaces. Parte

del

diseño

de

dichos

interfaces

es

la

determinación de cualquier objeto local que sea utilizado como parámetro y los valores de retorno de esos métodos; si alguno de esos interfaces o clases no existen aún también tenemos que definirlos. •

Implementar los Objetos Remotos. Los objetos remotos deben implementar uno o varios interfaces remotos. La clase del objeto remoto podría incluir implementaciones remotos)

y

otros

de

otros

métodos

interfaces (que

(locales

sólo

o

estarán

disponibles localmente). Si alguna clase local va a ser utilizada como parámetro o cómo valor de retorno de alguno

de

esos

métodos,

también

debe

ser

implementada.

126

•

Implementar los Clientes. Los clientes que utilizan objetos remotos pueden ser implementados después de haber definido los interfaces remotos, incluso después 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 través de un servidor Web. 5.1.7.

Arrancar la Aplicación.

Arrancar la aplicación incluye ejecutar el registro de objetos remotos de RMI, el servidor y el cliente. El resto de este capítulo muestra cómo seguir estos pasos para crear un motor de cálculo. 5.1.8.

Construir un Motor de Cálculo Genérico

Esta sección se enfoca a una sencilla pero potente aplicación distribuida llamada motor de cálculo. Este motor de cálculo es un objeto remoto en el servidor que toma tareas de clientes, las ejecuta, y devuelve los resultados. Las tareas se ejecutan en la máquina en la que se está ejecutando el servidor. Este tipo de aplicación distribuida podría permitir que un número de

127

máquinas clientes utilizaran una máquina potente, o una que tuviera hardware especializado. El aspecto novedoso del motor de cálculo es que las tareas que ejecuta no necesitan estar definidas cuando se escribe el motor de cálculo. Se pueden crear nuevas clases

de

tareas

en

cualquier

momento

y

luego

entregarlas el motor de cálculo 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 cálculo y ejecutada, incluso si la clase que define la tarea fue escrita mucho después de que el motor de cálculo fuera escrito y arrancado. El código necesita conseguir que una tarea sea descargada por el sistema RMI al motor de cálculo, y que éste ejecute la tarea utilizando los recursos de la máquina en la que está ejecutando el motor de cálculo. El RMI carga dinámicamente el código de las tareas en la máquina virtual del motor de cálculo y ejecuta la tarea si tener

un

conocimiento

anterior

de

la

clase

que

implementa la tarea. Una aplicación como ésta que tiene la habilidad de descargar código dinámicamente recibe el nombre de "aplicación basada en comportamiento". Dichas

aplicaciones

normalmente

requieren

infraestructuras que permitan agentes. Con RMI, dichas aplicaciones

son

parte

del

mecanismo

básico

de

programación distribuida de Java. 5.2.

Diseñar e implementar los componentes de nuestra aplicación distribuida. Escribir un Servidor RMI El servidor del motor de cálculo 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 definición de los métodos que pueden ser

128

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

Diseñar una Interface Remoto Interface Compute es el pegamento que conecta el cliente y el servidor. En el corazón del motor de cálculo hay un protocolo que permite que se le puedan enviar trabajos, el motor de cálculo ejecuta esos trabajos, y los resultados son devueltos al cliente. Este protocolo está expresado en interfaces soportados por el motor de cálculo y por los objetos que le son enviados. Cada uno de los interfaces contiene un sólo método. El interface del motor de cálculo Compute, permite que los Figuraenviados 12. Interfaz trabajos sean al compute motor, mientras que el

interface Task define cómo el motor de cálculo ejecuta una tarea enviada. El interface compute.Compute define la parte accesible remotamente - el propio motor de cálculo. Codigo interface remoto con su único método. 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 métodos que pueden ser llamados desde cualquier máquina virtual. Cualquier objeto que implemente este interface se convierte en un objeto remoto. Como miembro de un interface remoto, el método executeTask es un método remoto. Por lo tanto, el método debe ser definido como capaz de lanzar una

129

java.rmi.RemoteException. Esta excepción es lanzada por el sistema RMI durante una llamada a un método remoto para indicar que ha fallado la comunicación o que ha ocurrido un error de protocolo. La segunda interface necesitada por el motor de cálculo define el tipo Task. Este tipo es utilizado como un argumento

del

método

executeTask

del

interface

Compute. El interface compute.Task define la interface entre el motor de cálculo y el trabajo que necesita hacer, proporcionando la forma de iniciar el trabajo. Código tipo task package compute; import java.io.Serializable; public interface Task extends Serializable { Object execute(); } El interface Task define un sólo método, execute. Este método devuelve un Object, y no tiene parámetros ni lanza excepciones. Como este interface no extiende Remote,

el

método

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 también propociona el resto del código que configura el programa servidor: un método main que crea un ejemplar del objeto remoto, lo registra con la facilidad de nombrado, y configura

un

controlador

de

seguridad,

la

implementación de la clase para un interface remoto debería al menos. •

Declarar los Interfaces remotos que están siendo implementados.

•

Definir el constructor del objeto remoto.

•

Proprorcionar una implementación para cada método remoto de cada interface remoto.

130

El servidor necesita crear e instalar los objetos remotos. Este proceso de configuración puede ser encapsulado en un método main en la propia clase de implementación del objeto remoto, o puede ser incluido completamente en otra clase. El proceso de configuración debería. •

Crear e instalar un controlador de seguridad.

•

Crear uno o más ejemplares del objeto remoto.

•

Registrar al menos uno de los objetos remotos con el registro de objetos remotos de RMI (a algún otro servicio de nombrado que utilice JNDI).

Código motor de cálculo. La clase engine.ComputeEngine implementa el interface remoto Compute y también incluye el método main para configurar el motor de cálculo. 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 están siendo Implementados La clase que implementa el motor de cálculo se declara como. public class ComputeEngine extends UnicastRemoteObject implements Compute Esta declaración 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, podríamos indicar el puerto específico que un objeto remoto utiliza para aceptar peticiones. • Proporcionar una Implementación para cada Método Remoto La

clase

para

un

objeto

remoto

proporciona

implementaciones para todos los métodos remotos especificados en los interfaces remotos. El interface Compute

contiene

un

sólo

método

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 métodos remotos pueden ser de casi cualquier tipo Java, incluyendo objetos locales, objetos remotos y tipos primitivos. Más precisamente, una entidad de cualquier tipo Java puede ser pasada como un argumento o devuelta por un método 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

utilizando

el

locales

son

macanismo

pasados de

por

copia

serialización

de

objetos de Java. Por defecto, todos los campos se copian, excepto aquellos que están marcados como static o transient. El comportamiendo de la serialización por defecto puede ser sobrecargado en una básica clase-por-clase. • El método main() del Servidor El método más complicado de la implementación de ComputeEngine es el método main. Este método es utilizado para arrancar el ComputeEngine, y, por lo

133

tanto, necesita hacer la inicialización necesaria para preparar el servidor para aceptar llamadas de los clientes. Este método no es un método remoto, lo que significa que no puede ser llamado desde otra máquina virtual que no sea la suya. Cómo el método main se declara static, no está asociado con ningún objeto, sino con la clase ComputeEngine. • Crear e Instalar un Controlador de Seguridad Lo primero que hace el método main es crear e instalar un controlador de seguridad. Éste protege los accesos a los recursos del sistema por parte de código no firmado que se ejecute dentro de la máquina virtual. El controlador de seguridad determina si el código descargado tiene acceso al sistema

de

ficheros

local

o

puede

realizar

cualquier otra operación privilegiada. Aquí temos el código que crea e instala el controlador de seguridad. if (System.getSecurityManager() == null) { System.setSecurityManager(new RMISecurityManager());} • Poner el Objeto Remoto a Disposición de los Clientes Luego, el método main crea un ejemplar de ComputeEngine. Esto se hace con la sentencia. Compute engine = new ComputeEngine(); Antes de que un llamador pueda invocar un método 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 obteniéndolo como parte del valor de

134

retorno de un método o como parte de una estructura

de

datos

que

contenga

dicha

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 están ejecutando el registro y el objeto remoto, y un nombre Compute, que identifica el objeto remoto en el registro. Luego está el código necesario para añadir el nombre al registro RMI que se está ejecutando en el servidor. Esto se hace después (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 método 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

está

disponible

para

aceptar

llamadas y no será reclamado hasta que. •

su nombre sea eliminado del registro, y

•

ningún cliente remoto mantenga una

referencia al objeto ComputeEngine. La

pieza

final

de

código

del

método

ComputeEngine.main maneja cualquier excepción que pudiera producirse. 5.2.3.

Crear un Programa Cliente

135

El motor de cálculo es un bonito y sencillo programa ejecuta las tareas que le son enviadas. Los clientes del motor de cálculo son más complejos. Un cliente necesita llamar al motor de cálculo, pero también 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 cálcilo. El trabajo de la clase Pi es calcular el valor del número pi, con algún número 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 máquina virtual remota como parte de una llamada a un método remoto. Podríamos haber elegido hacer que la implementación 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 también implemente el interface Serializable. Dado esto, hemos asociado explícitamente los dos interfaces en el tipo system, asegurando que todos los objetos Task sean serializables. El código que llama a los métodos del objeto Compute debe obtener una referencia a ese objeto, crear un

136

objeto Task, y luego pedir que se ejecute la tarea. Más adelante veremos la definición de la tarea Pi. Un objeto Pi se construye con un sólo argumento, la precisión deseada en el resultado. El resultado de la ejecución de la tarea es un java.math.BigDecimal que representa el número pi calculado con la precisión 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 podría descargar código en el cliente. En este ejemplo, el stub ComputeEngine es descargado al cliente. Siempre que el RMI descargue código, 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 propósito. Después 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 línea de comandos args[0], es el nombre del host remoto, en el que se están ejecutando los objetos Compute. Usando el método Naming.lookup, el cliente busca el objeto remoto por su nombre en el registro del host remoto. Cuando se hace la búsqueda del nombre, el código crea una URL que específica el host donde se está ejecutando el servidor. El nombre pasado en la llamada a Naming.lookup nombre

pasado

tiene la misma síntaxis URL que el a

la

llamada

Naming.rebind

que

explícamos en páginas anteriores. Luego, el cliente crea un objeto Pi pasando al constructor de Pi el segundo argumento de la línea de comandos, args[1], que indica el número de decimales utilizados en el cálculo. Finalmente, el cliente llama al método 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 mensajeentre el cliente ComputePi, Flujo de mensajes rmiregistry, y el ComputeEngine.

el

Finalmente, echemos un vistazo a la clase Pi. Esta clase implementa el interface Task y cálcula el valor del número pi con un número de decimales especificado. Desde el punto de vista de este ejemplo, el algoritmo real no es importante (excepto, por supuesto, para la fiabilidad del cálculo). Todo lo importante es que el cálculo consume numéricamene muchos recursos (y por eso es el tipo que cosa que querríamos hacer en un servidor potente). Aquí tenemos el código de la clase Pi, que implementa Task. package client; import compute.*; import java.math.*; public class Pi implements Task { /** constantes utilizadas en el cálculo 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 cálculo*/ private static final int roundingMode = BigDecimal.ROUND_HALF_EVEN; /** número de dígitos tras el punto decimal*/ private int digits; /** * Construye una tarea para calcular el núemro pi * con la precisión específicada. */ public Pi(int digits) { this.digits = digits; } /** * Calcula pi. */ public Object execute() { return computePi(digits); 139

} /** * Calcula el valor de Pi con el número de decimales especificados. * El valor se calcula utilizando la fórmula de Machin. * * pi/4 = 4*arctan(1/5) - arctan(1/239) * * y una poderoas serie de expansiones de arctan(x) * para una precisión 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 número 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 característica más interesante de este ejemplo es que el objeto Compute no necesita una definición de la clase Pi hasta que se le pasa un objeto Pi como un argumento del método executeTask. Hasta este punto, el código de la clase se ha cargado por el RMI dentro de la máquina virtual del objeto Compute, se ha llamado al método execute, y se ha ejecutado el código 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, también podríamos implementar una tarea que generara un número primo aleatorio utilizando un algoritmo probabilistico. (Esto también consume muchos recursos y por tanto es un candidato para ser enviado al ComputeEngine).

Este

código

también

podría

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 método execute, no

sabe

(y

tampoco

le

interesa)

qué

hace

la

implementación. 5.3. Compilar el Ejemplo Ahora aprenderemos cómo crear un fichero JAR, las clases del servidor, y las clases del cliente. Veremos como la clase Pi será descargada al servidor durante la ejecución. También

141

veremos

como

el

stub

remoto

ComputeEngine

será

descargado desde el servidor hasta el cliente durante la ejecución. El ejemplo separa los interfaces, la implementación de los objetos remotos y el código del cliente en tres paquetes diferentes. •

compute (Los interfaces Compute y Task)

•

engine (Implementación de la clase, el interface y el stub de ComputeEngine)

•

client (la implementación 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

c:\home\waldo\src\compute

(en

fuente UNIX

en sería,

/home/waldo/src/compute). Con estos paths podemos utilizar los siguientes comandos para compilar los intefaces y crear el fichero JAR. Detalles específicos 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 opción -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 código cuando sea necesario. En vez de definir su propio protocolo para descargar código, RMI utiliza un protocolo URL soportado por Java (por ejemplo, HTTP) para descargar el código. 5.3.2.

Construir las Clases del Servidor

El paquete engine sólo contiene la implementación de la clase

del

lado

implementación

del del

servidor, objeto

ComputeEngine,

remoto

del

la

interface

Compute. Como ComputeEngine es una implementación 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

public_html,

c:\home\ana\public_html\classes (en UNIX podría ser /home/ana/public_html/classes,

accesible

mendiante

algún 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 Específicos de la Plataforma: Compilar el Motor de Cálculo 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 cómo seleccionar la variable de entorno CLASSPATH. Detalles Específicos 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 implementación de los objetos remotos que deberían encontrarse en el path de clases. El comando rmic toma uno o más nombres de clase como entrada y produce, como salida, ficheros de clases

con

opcionalmente

la

forma

ClassName_Stub.class

ClassName_Skel.class).

El

(y

fichero

esqueleto no será generado si llamamos a rmic con la opción -v1.2. Esta opción sólo debería utilizarse si todos nuestros clientes van a utilizar el JDK 1.2 o posterior. La opción -d le dice al compilador rmic que situe los ficheros de clases generados, ComputeEngine_Stub y

144

ComputeEngine_Skel,

en

c:\home\ana\src\engine.

el

También

directorio

necesitamos

poner

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, también necesitamos poner estas clases disponibles en la red. Por eso,

el

paso

compute.jar

final

es

desempaquetar

en

el

el

c:\home\ann\public_html\classes

para

fichero

directorio hacer

que

los

interfaces Compute y Task estén disponibles para su descarga. Detalles Específicos 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

Asumamos que el usuario jones ha creado el código del cliente

en

el

directorio

c:\home\jones\src\client

y

colocará la clase Pi (para que sea descargada por el motor de cálculo) en el directorio accesible a la red c:\home\jones\public_html\classes mediante

algunos

(también

servidores

disponible como

http://host/~jones/classes/). Las dos clases del lado del cliente están contenidas en los ficheros Pi.java y ComputePi.java en el subdirectorio client. Para construir el código 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 Específicos 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

Sólo 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 máquina virtual del motor de cálculo. 5.4. Ejecutar el Ejemplo Una Nota sobre la Seguridad El modelo de seguridad del JDK 1.2 es más sofisticado que el modelo utilizado en el JDK 1.1. Contiene ampliaciones para seguridad de grano fino y requiere código que permita los permisos específicos para realizar ciertas operaciones. En el JDK 1.1, todo el código que haya en el path de clases se considera firmado y puede realizar cualquier operación, el código 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 policía cuando ejecutemos el servidor y el cliente. Aquí tenemos un fichero de policía general que permite al código 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 código disponible mediante URLs HTTP, deberíamos ejecutar el fichero de policía anterior cuando ejecutemos este ejemplo. Sin embargo, si utilizarámos un fichero de URLs en su lugar, podemos utilizar el fichero de policía siguiente. Observa que en entornos windows, la barra invertida necesita ser representada con dos barras invertidas en el fichero de policía. 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 policía se llama java.policy y contiene los permisos apropiados. Si ejecutamos este ejemplo en el JDK 1.1, no necesitamos un fichero de policía ya que el RMISecurityManager proporciona toda la protección que necesitamos. Arrancar el Servidor Antes de arrancar el motor de cálculo, necesitamos arrancar el registro de RMI con el comando rmiregistry. Como explicamos en páginas 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

implementación 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 aplicación servidor). Como resultado, el rmiregistry no enviará a los clientes un codebase asociado con las clases stub, y consecuentemente, nuestros clientes no podrán 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 Específicos 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 número de puerto en la línea de comandos. No olvidemos borrar el CLASSPATH. Detalles Específicos 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 implementación del objeto remoto (que es lo que vamos a arrancar) están en nuestro path de clases.

148

Detalles Específicos 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

cálculo,

necesitamos

especificar, utilizando la propiedad java.rmi.server.codebase, donde están 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 Específicos de la Plataforma: Arrancar el Motor de Cálculo 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 están ejecutando, podemos arrancar el cliente, especificando. •

la localización donde el cliente sirve sus clases (la clase Pi) utilizando la propiedad java.rmi.server.codebase.

•

como argumentos de la línea de comandos, el nombre del host (para que el cliente sepa donde localizar el objeto remoto) y el número de decimales utilizado en el cálculo del número Pi.

149

•

java.security.policy,

una

propiedad

utilizada

para

especificar el fichero de policía que contiene los permisos adecuados. 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 Específicos 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

Después de arrancar el cliente, deberíamos ver la siguiente salida en nuesta pantalla. 3.14159265358979323846

ACTIVIDAD 

Discuta la semántica de invocación que puede lograrse cuando se implementa el protocolo petición-respuesta, sobre una conexión TCP/IP, que garantiza que los datos se entrean en el orden de su envio. Sin pérdidas y sin duplicación. Tenga en cuenta todas las condiciones que puedan causar la ruptura de una conexión.

RESUMEN Este capitulo ha mostrado dos paradigmas de la programación distribuida: la invocación de métodos 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 método en la interfaz remota de un objeto en particular es

150

invocado

sincrónicamente

(el

que

invoca

espera

por

la

respuesta). En el segundo caso se envían notifcaciones asincrónicamente a varios multiples suscriptores cuando quiera que ocurra un evento publicado hacia el objeto interesado. El modelo de objetos distribuidos es una extensión del modelo de objetos locales que se emplea en los lenguajes de programación badaos en objetos. Los objetos encapsulados constituyen componentes utiles en un sistema distribuido, puesto

que

la

encapsulación

los

hace

enteramente

responsables de gestionar su propio estado, y la invocación de métodos locales puede extenderse hacia la invocación 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 invocación a un método local da una semántica del tipo exactamente una vez, mientras que una invocación remota no puede dar las mismas garantías dado que los objetos participantes stan en computadoras diferentes, que pueden fallar independientemente y están ligados por una red, que también podría fallar. Lo mejor que podemos obtener es una semántica del tipo como máximo 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 invocación remota parezca idéntica a una invocación 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 localización de los objetos remotos desde los programas cliente y servidor. Estos componentes pueden generarse mediante un compilador de interfaces. Java RMI extiende la invocación local en invoacion remota emplenado la misma sintaxis, pero habrá

151

que especificar las interfaces remotas como una extensión de una interfaz denominada Remote y también cada método deberá lanzar la excepción RemoteException. Esto garantiza que los programadores son conscientes de que realizan llamadas

remotas

permitiéndoles

o

implemnetan

gestionar

los

objetos

errores

o

remotos,

diseñar

y

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/

o

George Colouris, “Sistemas Distribuidos” Conceptos y Diseño, Addison Wesley, España 2001 http://www.cdk3.net/

o

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. ¿Cuáles 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 ACADÉMICA Nº 07

SISTEMAS DE ARCHIVOS DISTRIBUIDOS Los sistemas de archivos distribuidos soportan la compraticion de información en forma de archivos a través de internet. Un servicio de archivos

bien

alamacenados semejantes

(y

diseñado en en

un

proporciona

servidor

algunos

con

casos

acceso

a

prestaciones

mejor)

que

la

los

archivos

y

fiabilidad

de

archivos

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 implementación distribuida del clásico 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. CARACTERÍSTICAS DE LOS SISTEMAS DE ARCHIVOS Los sistemas de archivos son responsables de la organización, almacenamiento,

recuperación,

nominación,

compartición

y

154

protección

de

los

archivos.

Proporcionan

una

interfáz

de

programación característica de la abstracción de archivo, liberando a los programadores de la preocupación por los detalles de la asignación y la disposición del almacenamiento. Los archivos se almacenan en Discos y otros medios de almacenamiento no volátiles. Los sistemas de archivos están diseñados para almacenar y gestionar gran número de archivos, con posibilidades de crear, nombrar y borrar archivos. La nomenclatura de los archivos está respaldada por la utilizaciónde directorios. Un directorio es un archivo. En la figura 1 se muestra una estructura típica de niveles para la implementación de un sistema de archivos no distribuidos en un sistema operativo convencional. Cada nivel depende sólo de los niveles que se encuentran debajo de él. La implementación de un servicio de archivos distribuidos requiere todos los componentes Tamaño del Archivo Marca temporal de

indicados, junto a

creación Marca temporal de

adicionales

lectura Marca temporal de escritura Marca temporal de

componentes ocuparse

para de

la

comunicación cliente – servidor y de la nomenclatura

atributos Contador de

y ubicación de los

referencias Propietario Tipo de archivos Lista de control de

distribuidos.

archivos

acceso

155

Figura 1. Estructura tipica de un sitema de archivos

156

2. REQUISITOS DEL SISTEMA DE ARCHIVOS DISTRIBUIDOS Muchos de los requisitos y potenciales obstáculos en el diseño de servicios distribuidos fueron ya observados en los primeros desarrollos de sistemas de archivos distribuidos. Inicialmente ofrecían transparencia de acceso y transparencia de ubicación, 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

más

fuertemente cargado en una intranet, por lo que su funcionalidad y prestaciones son críticas. El diseño 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 operación

de otros

clientes que acceden o cambian

simultáneamente el mismo archivo. 2.2.

Replicación 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 múltiples 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.

El papel central de un servicio de archivos

en los sistemas

distribuidos hace que sea esencial que el servicio continúe funcionando aun en el caso de fallos del cliente y del servidor. Afortunadamente un diseño moderadamente tolerante a fallos es inmediato para servidores sencillos. Para manejar los fallos de comunicación transitorios, el diseño puede estar basado en la semántica de invocación de cómo máximo una vez. O puede utilizarse la semántica más sencilla al menos una vez con un protocolo de servidor diseñado en términos de operaciones idempotentes,

asegurando

que

solicitudes

duplicadas

no

producen actualizaciones inválidas en los archivos. 2.5.

Consistencia.

Los sistemas de archivos

convencionales, como los se

proporcionan en UNIX, ofrecen una semántica de actualización 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 verían 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

en

identificar al usuario correcto y proteger el contenido de los mensajes

de solicitud y respuesta con firmas digitales

y

(opcionalmente) encriptación de datos secretos. 2.7.

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

y

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 módulo 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 módulo cliente proporciona una interfaz sencilla

con

operaciones

sobre

archivos

de programación semejantes

a

las

encontradas en los sistemas de archivos convencionales. El diseño es abierto en el sentido que pueden utilizarse diferentes módulos cliente para implementar

diferentes interfaces de programación,

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

Servicio de directorio

Programa De aplicaci

Servicio de archivos plano Mulo 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 almacén de archivos remotos. El protocolo NFS es independiente

del

sistema

operativo

pero

fue

desarrollado

159

originalmente para su utilización en redes de sistemas UNIX. El módulo servidor NFS reside en el núcleo de cada computador que actúa como un servidor NFS. Las solicitudes que se refieren a archivos en un sistema de archivos remoto se traducen en el módulo cliente a operaciones del protocolo NFS y después se trasladan al módulo servidor NFS en el computador que mantiene el sistema de archivos relevante. Los módulos

cliente y servidor NFS se comunican utilizando

llamadas a procedimientos remotos.

Computador Cliente Programa De aplicaci

N 昱 leo UNIX

Programa De aplicaci

N 昱 leo UNIX Sistema de archivos virtual

Sistema de archivos virtual

Local Sistema de archivos UNIX

Otro sistema de archivos

LLamadas al sistema UNIX

Computador servidor

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, podrían integrarse de la misma forma. La integración se obtiene mediante

un módulo de

archivos virtual (VFS), que ha sido añadido al núcleo de UNIX para distinguir entre

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 están actualmente disponibles tanto local como remotamente, pasa cada solicitud al módulo del sistema local apropiado (el sistema de archivos UNIX, el módulo cliente NFS o el módulo 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 información que necesita el servidor para distinguir un archivo individual. •

Integración del Cliente.- El cliente NFS juega el papel descrito

para

el

módulo

cliente

en

nuestro

modelo

arcquitectónico, proporcionado una interfaz idóneo para su uso por programas de aplicación convencionales. Pero a diferencia del módulo cliente de nuestyro modelo, emula la semántica de las primitivas del sistema de archivos estándar de UNIX de forma precisa y está integrado con un nucleo UNIX. Está integrado con el núcleo y no proporcionado como una librería 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 recopilación o recarga.

–

Un único módulo cliente sirve a todos los procesos del nivel del usuario, con una caché compartida de los bloques utilizados recientemente.

–

La clave de encriptación utilizada para autentificar ID del usuario pasadas al servidor puede retenerse en el núcleo, previniendo la impersonaciónpor clientes a nivel de usuario.

El módulo cliente de NFS coopera con el sistema de archivos virtual en cada máquina 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 máquinas 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 podría 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 diseño 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 cachés de los clientes cuando son actualizadas.

•

La recuperación después de un fallo en el servidor o en el cliente.

•

El alto rendimiento en la lectura y escriturade archivos de todos los tamaños,

•

La escalabilidad.

BIBLIOGRAFIA RECOMENDADA o

George Colouris, “Sistemas Distribuidos” Conceptos y Diseño, Addison Wesley, España 2001 http://www.cdk3.net/

o

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

o

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 operación Abre y Cierra en nuestra interfaz de servicio de archivos planos o en el servicio de directorio? ¿Cuáles son las diferencias entre operación 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? ¿Cómo se asegura la unicidad para los UFID?

164

UNIDAD ACADÉMICA 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,

suplantación,

modificación

y

denegación del servicio. Los diseñadores 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 mayoría de los tipos de redes locales es fácil 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 podría situarse a si mismo en lugar del autentico servidor de archivos y

165

asi obtener copias de información confidencial que los clientes, inconcientemente envían para su almacenamiento. Además del peligro de pérdida o daño de información, o de recursos por violaciones directas también pueden aparecer reclamos fraudulentos contra el propietario de un sistema que no sea demostrablemente seguro. Para evitar tales reclamos, el propietario debe estar en situación de desacreditar el reclamo mostrando que el sistema es seguro contra tales violaciones o también

produciendo

un

registro

histórico

de

todas

las

transacciones durante el periodo en cuestión. 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 información y los recursos de modo que solo tengan acceso aquellos principales autorizados. Las amenazas de seguridad caen en tres amplias clases: •

Fuga:

la

adquisición

de

información

por

receptores

no

autorizados. •

Alteración:

la modificación no autorizada de información.

•

Vandalismo:

interferencia con el modo de operación adecuado de

un sistema, sin ganancia alguna para el perpetrador. Los ataques en los sistemas distribuidos dependen de la obtención de acceso a los canales de comunicación existentes o del establecimiento de canales nuevos que se suplantan a las conexiones(empleamos el termino canal para hacer alusión a cualquier mecanismo de comunicación de procesos). Los métodos pueden clasificarse más aun en función 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 autorización. •

Alterar mensajes: Interceptar mensaje y alterar sus contenidos antes de pasarlos al receptor pretendido.

•

Reenviar : almacenar mensajes interceptados y enviarlos mas tarde.

• Dengacion de servicio: desbordar un canal u otros recursos con mensajes con el fin de impedir que otros accedan a él. En teoría 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 CÓDIGO MÓVIL. Varios lenguajes de programcion, recientemente desarrollados han sido diseñados 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 ejecución pueden quedar expuestos a un ataque por código móvil. 3. FUGAS DE INFORMACIÓN Si pudiera observarse la sucesión de mensaes en la comunicación entre

dos

procesos,

seria

posible

vislumbrar

información

importante aun de su sola existencia, por ejemplo: un flujo de mensajes hacia un vendedor hacerca de una mercancía en particular podría indicar un alto nivel de comercio en esa mercancía. Hay muchas formas sutiles de fugas de información algunas maliciosas y otras que son consecuencias de errores inadvertidos. 4. SEGURIDAD DE LAS TRANSACCIONES ELECTRÓNICAS

167

Muchas ampliaciones de internet en la industria el comercio y demás implican transacciones que dependen crucialmente de la seguridad: • Email:

aunque los sistemas originales de correo

electrónico 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 ejem´plo cuando se remite una puja a una subasta por email), la seguridad criptográfica basada en las técnicas 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

otro

tipo

de

producto

puede

venderse

desde

comercios en internet estos se envían mediante un servicio de reparto. • Transacciones bancarias:

los bancos electrónicos de hoy en

dia ofrecen virtualmente a los usuarios todos los servicos que proporcionan los bancos convencionales estos proporcionan la comprobación

de

los

cargos

y

balances

de

cuentas,

transferencias de efectivo entre cuentas, el establecimiento de cargos regulares automaticos y demás desde la cuenta. • Microtransacciones :

internet

se

presta

a

proporcionar

pequeñas cantidades de información y otros servicios a sus clientes, por ejemplo el acceso a la mayoría de las paginas web no exige ningún pago, pero el desarrollo del web como un medio de publicacon de alta calidad seguramente depende de

168

que hasta que punto los proveedores de información puedan obtener beneficio de los clientes de esta información. 5. VISIÓN GENERAL DE LAS TÉCNICAS DE LA SEGURIDAD El objetivo de esta sección es presentar al lector algunas de las técnicas y mecanismos mas importantes para asegurar sistemas y aplicaciones distribuidas.

169

6. CRIPTOGRAFÍA. La encriptación es el proces de codificación de un mensaje de forma que puedan ocultar sus contenidos, la criptografía 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 criptográfica es un parámetro empleado en un algoritmo de encritptacion de forma que la encriptación no sea reversible sin el conocimiento de una clave. a) Criptoalgorítmos Clásicos Revisión de la historia de la cifra. Cifra de sustitución: Monoalfabética. Polialfabética. Distribución de claves. Poligramas. Homofónica. Cifra de transposición. Ruptura mediante el uso del análisis de frecuencia. Teoría de Shanon del secreto perfecto y sus aplicaciones prácticas. Data Encryption Standard – primer intento de estandarizar la protección de la información en redes de computadoras. Revisión histórica de los criptosistemas Los roles de NBS – NSA – IBM. Aceptación por parte de organismos

oficiales

y

sectores

comerciales.

Principales

características del algoritmo. Criterios de diseño. Criptoanálisis diferencial y lineal. Vulnerabilidad a un ataque de búsqueda exhaustiva de clave. Triple DES: Modos de operación. Seguridad de los diferentes modos de operación. Otras cifras de bloque de clave simétrica. IDEA, RC5, Blowfish, DESX, Skipjack. Algoritmos de cifrado para una implementación rápida por software. Implementación de cifras de bloque de clave secreta Arquitecturas

generales

de

hardware

y

software.

Implementaciones básicas, operación 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 implementación. Desarrollos de nuevo Advanced Encryption Standard –AES. Contexto de desarrollo. Criterios de evaluación. Algoritmos candidatos a AES. Comparación de los candidatos a AES: Seguridad; Eficiencia en la implementación por software; Eficiencia en la implementación por hardware; Flexibilidad; Procesos de evaluación. b) Criptoalgoritmos de clave pública. Criptosistemas RSA (Rivest, Shamir, Adleman) – el primer criptosistema de clave pública exitoso. Cómo se gestó RSA. RSA como una función de una sola vía con “trapdoor”. La factorización como principio de seguridad en RSA:

registro

números

de

mediante

computadoras.

factorización; el

Desafíos

uso de

factorización

de

redes

RSA.

de

grandes

distribuidas

Tamaños

de

de

clave

recomendados en los criptosistemas RSA. Generación de claves en los criptosistemas RSA. Propósitos generales vs propósitos especiales en los algoritmos de factorización. RSA para paranoicos. Fortaleza de los números primos.

Test

probabilístico

para

detectar

primos.

Test

determinístico para detectar primos. Construcción de números primos grandes y randómicos. Implementación de cifrado de clave pública. Algoritmos de exponenciación básicos. Uso del teorema de los restos chinos para una rápida exponenciación. Algoritmos básicos para multiplicación y reducción modular por software. Arquitecturas básicas para multiplicación y reducción modular por hardware. Dependencia entre la longitud de clave y el tiempo de transformación criptográfica. Reconocimiento de implementaciones existentes de RSA.

171

c) Servicios de Seguridad Firma Digital. Digital Signature Standard – DSS. Clasificación de firmas digitales. Ataques contra la firma digital. Relleno de seguridad para firmas. Digital Signature Standard (DSS). Análisis comparativo de RSA y DSS – Seguridad, perfomance, funcionalidad. Temas legales respecto a la firma digital. Integridad de datos y autenticación – dos faces del mismo problema. Funciones de hash y MACs. Requerimientos

para

una

función

de

hashing

segura.

Clasificación de las funciones de hashing. Ataques contra funciones de hashing. Aplicaciones estándar y no estándar.: firma digital y códigos de autenticación; detección de virus; almacenamiento de password; cifrado rápido. Familias de algoritmos

para

funciones

de

hashing

y

su

seguridad.

Requerimientos para Message Authentication Code (MAC). Familias de MACs y su seguridad. Combinación de autenticación y confidencialidad. d) Administración de claves Intercambio de claves para criptosistemas de clave simétrica. Clave de sesión y clave de encripción. Intercabio de claves usando centros de distribución. Protocolo de intercambio de clave de Diffie-Hellman. Intercambio de claves simétricas utilizando criptosistemas de clave pública. Certificados de clave pública e infraestructuras de autoridades de certificación. Generación y registro del par de claves públicas. Concepto de certificado de clave pública. Formatos de los certificados (X.509; EDIFACT; etc.). Estructura jerárquica y autoridades de certificación en una estructura de clave pública. Revocación de certificados.

172

e) Estándares criptográficos y protocolos seguros para Internet. Estándares critptográficos de USA y resto del mundo. Organizaciones que administran estándares. Principales grupos de estándares criptográficos: Estándares federales ( USA); Estándares

ANSI;

Estándares

del

IEEE;

Estándares

ISO;

Estándares informales de la industria. Estándares para la criptografía clásica. Estándares para la criptografía de clave pública. Protocolos seguros para Internet. Correo electrónico seguro: S/MIME; Open PGP. Web Site seguros: SSL; S-HTTP. Protocolos de seguridad para pagos con tarjeta: SET; dinero electrónico; micropagos. Redes privadas virtuales seguras: IPSec; PPTP. Controles

de

importación

y

exportación

de

dispositivos

criptográficos. Evolución de las políticas de USA. Reglamentación actual en USA. f) Capítulos

7:

Criptografía

cuántica

y

computación

cuántica Criptografía cuántica – Criptografía para el siglo XXI ..? Conceptos básicos de la criptografía cuántica – traslado del principio de Hisenberg para una seguridad ideal. Primeras implementaciones perfomance;

prácticas

costos;

de

actuales

la

criptografía

limitaciones.

cuántica Hacia

–

una

computación cuántica. Ruptura de cifras usando la computación cuántica – sueño o realidad .?. Reemplazará la física a la matemática como la base para el desarrollo de la seguridad en redes

de

computadoras.?.

Tendencia

de

las

corrientes

investigaciones en criptografía y seguridad en redes.

173

ACTIVIDAD 

Describa algunas de las políticas de seguridad de su organización. Expréselas en términos 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 comunicación de cualquier sistema que trate con información que sea suceptible de ser atacada. El correo personal,

el

coemrsio

electrónico

y

otras

transacciones

financieras son ejemplos de tal tipo de información. Los protocolos de seguridad se diseñan cuidadosamente para evitar trampas. El diseño 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 criptografía de clave publica y de clave secreta. Los algoritmos criptográficos disfrazan los mensajes de forma que no pueda revertirse el proceso sin el conocimiento de la clave de desencriptacion. La criptografía de la clave secreta es simetrica: la misma clave sirve tanto para la encriptación como para la desencriptacion. Si dos partes compraten una clave secreta, podrán intercambiar información

encriptada

sin

riesgo

que

sea

desvelada

o

modificada y con garantías de autenticidad. La criptografía de clave publica es asimétrica: se utlizan claves separadas

para

la

encriptación

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 delegación de derechos a acceso pero son difíciles 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 Diseño, Addison Wesley, España 2001 http://www.cdk3.net/

o

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

¿Cómo podria enviarse un correo electronico a un lista de receptores utilizando PGP o un esquema similar?

176