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ónLa 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 DistribuidosUn 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 de Sistema

Distribuido tiene las siguientes

consecuencias significativas:

• 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 de Reloj Global.- Cuando los programas

necesitan cooperar coordinan sus acciones 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

Figura 2.

Internet

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

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

Figura 3. Red LAN,

WAN

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

11

Figura 4. Computacion Movil y

Ubicua

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.

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

Figura 5. Proceso Cliente – Proceso

Servidor

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.

14

Figura 6. Recursos Compartidos en

la web

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.

16

Figura 7. Sistemas Distribuidos como

MIddleware

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. Se pueden 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

DISTRIBUIDOSLos 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, sus papeles

funcionales y los patrones de comunicación 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

serviciosMiddleware

Sistema

OperativoComputador y

Hw. de red

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

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

Aplicación de

serviciosMiddleware

Sistema

OperativoComputador y

Hw. de red

Plataforma

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

Figura 2.

Middleware

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 )

27

Figura 3. Clientes que invocan a servidores

individuales.

• Servicios proporcionados por múltiples servidores.

Los servicios pueden implementarse como distintos

procesos de servidor en computadores 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

• 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

Cliente

Cliente

Servidor

Servidor

Servidor

Figura 4. Un servicio proporcionado por multiples

servidores.

Los caches pueden estar ubicados en los clientes o en un

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

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

29

Figura 5. Un servidor proxy del

tipo web

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

Figura 6. Como funciona un

proxy

Útil al descomponer aplicaciones en tareas coordinadas.

Ejemplos: Cooperación y coordinación, Algoritmos

descentralizados, Coordinación de 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

Código Móvil. Es el código que puede ser enviado de un

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

Figura 8. Interfaz de un

dispositivo movil

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

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

Red Espontanea

Ventajas

Facilidad de conexión a la red local

31

Figura 9. Applet del tipo web.

Figura 10. Distribucion de carga

Facilidad de integración con los servicios locales

Problemas

Seguridad

Conectividad

Servicio de detección.

Según el diseño 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

Figura 11. Intercomunicacion espontanea

en un hotel

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

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

a. El Rendimiento de los canales de comunicaciones:

• Latencia: retardo entre el envío de un mensaje por

un proceso y su recepción por otro.

35

Figura 12. Modelo de iteraccion de un Sistema

Distribuido

• 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

Si estuvieran sincronizados seria así

37

Figura 13. Ordenamiento de

eventos

Figura 14. Tabla de entrada de

mensajes

38

Envia m Recibe

Proceso p Proceso q

Canal de Comunicaci

Buffer de Mensajes entrantes.

Fallos por Omisi del canal Buffer de

Mensajes Salientes.

}Fallos por omisi de recepci .{Fallos por

omisi de envio.

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.

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

Figura 15. Fallos por omision de

canal

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

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

Figura 16. Modelo de Seguridad de sistemas

distribuidos

Cliente

Servidor

Derechos de acceso

Objeto

Principal (servidor)

RedPrincipal (cliente)

Invocaci

Resultado

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

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

autorizada.

41Proceso P Proceso Q

El enemigo

Copia de m

m

m`^

Canal de comunicaci

Figura 17. Objetos y principales

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

Figura 18. El enemigo

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 REDESLos sistemas distribuidos utlizan redes de area local, redes de area

extendido e interredes para comunicarse. Las prestaciones, fiabilidad,

escalabilidad, movilidad y calidad del servicio de las redes

subyacentes influyen en el comportamiento de los 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

47

Figura 1. Elementos de la

Comunicación

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.

48

SEGMENTACION DE PAQUETES

49

Figura 2. Segmentacion de

Paquetes

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

3.REGLAS QUE RIGEN LAS COMUNICACIONES

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

Figura 3. Elementos de

una Red

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.

3.1 Modelo TCP/IP

Es 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 4. Modelos de

Red

El modelo TCP/IP describe la funcionalidad de los protocolos

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 5. Modelo

TCP/IP

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.

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

PROCESOS DE ENCAPSULAMIENTO DE DATOS

Figura 6. Transporte de un

paquete

Figura 7. Encapsulamiento

de Datos

Bits: una PDU que se utiliza cuando se transmiten

físicamente datos a través de un medio.

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

Figura 8. Direccionamiento de

PDU

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.

3.2 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

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

mensajes

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.

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

Figura 10. Comunicación

capa a capa

Durante el proceso de encapsulación, se agregan

identificadores de dirección a los datos mientras bajan al stack

del protocolo en 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

Figura 11. Direccionamiento por

capas

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.

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 ejecutar múltiples aplicaciones de red

simultáneamente. La gente que utiliza computadoras

personales generalmente tiene un 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

Figura 12. Direccionamiento en la capa 3

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

Cada capa ofrece lo mejor para garantizar la comunicación

entre procesos. Durante la clase, observamos que los Sistemas

Distribuidos se desarrollan sobre la capa transporte.

4.CAPA DE TRANSPORTE

62

Figura 13. Direccionamiento en la

capa 4

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

• identificación de las diferentes aplicaciones.

4.1 Responsabilidades de la capa de Red

4.1.1 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.2Segmentació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 encabezado de dicha capa para

reensamblar las secciones de datos en 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

4.2 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 en UDP se llaman datagramas. Este

protocolo de la capa de Transporte envía 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

Figura 14. Habilitacion de los dispositivos para la

comunicacion

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

Considere el siguiente ejemplo, una computadora que recibe y

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

Figura 15. Encabezado TCP y UDP

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

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

Figura 16. Direccionamiento de

puertos

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

UNIDAD ACADÉMICA Nº 04

COMUNICACION ENTRE

PROCESOS EN SISTEMAS

DISTRIBUIDOS

73

Figura 17. Aplicaciones de

internet

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.

¿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

Aplicaciones, servicios.

RMI y RPC

Protocolo petici respuesta Empaquetado y representaci externa de datos

UDP y TCP

} Capas Middleware{Este cap

咜 ulo

Figura 1. Capas Middleware

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

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

• Comunicaciones remotas

1.3 Eficiencia

75

Figura 2. Proceso de compartir

informacion

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

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

Estructura t厓ica de mensaje

Figura 3. Estructura tipica de un

mensaje

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

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

Figura 4. Mensajes Bloqueantes Vs. No

bloqueantes

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.

3.1.3 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

Figura 5. Transferencia de

mensajes

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.1PASO 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.

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

Figura 6. Asignacion fija

predeterminada

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

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. Asignacion Aleatoria de numero

de proceso

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

Figura 7. Servidor de nombres

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 cambios no son permitidos. Las

aseveraciones que describen los cambios 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 de transacciones deben soportar las

siguientes operaciones: terminación, concurrencia y

recuperación (Commitment, 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.2Comunicació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

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:<servicio>: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

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

Asincrona

• 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

Modelo con proxy o cache.

89

Figura 10. Comunicación peticion respuesta cliente -

servidor

Tres roles diferentes en la interacción

• Cliente: Solicita servicio.

• Servidor: Proporciona servicio.

• Proxy: Intermediario (si tiene memoria se denomina caché)

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

Los modelos de comunicación basados en cliente-servidor

con paso de mensajes responden al esqueleto:

90

Figura 11. Comunicación peticion respuesta

con proxy

Figura 12. Comunicación peticion respuesta

Servidor - Servidor

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

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

de mensajes

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 International Conference on Autonomic

Computing and Communication 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ón-

respuesta 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 la siguiente manera: {protocolo,

dirección_local, proceso_local, 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.

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

Figura 1. Sockets y Puertos

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:

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

Figura 2. Tabla de operaciones en archivos Vs

Operaciones en Sockets

• 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:

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

2 PROTOCOLO DE INTERFAZ DE APLICACION (API) DE JAVA

PARA LAS DIRECCIONES DE INTERNET

Como los paquetes IP que subyacen a TCP y UDP se 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

Figura 3. Proceso de transmision de datos con

Streams

Figura 3. Proceso de transmision de datos con

datagramas.

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

conteniendo el mensaje

Longitud del

mensaje.

Dirección

de internet

Numero de

puerto

Las 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

Figura 3. Paquete del

datagrama

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 destinationSocket 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 de la forma de comunicación

utilizada, las estructuras de 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 REMOTALos 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

COMUNICACION DE OBJETOS REMOTOS

• 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í?”

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.

112

Aplicaciones, servicios.

RMI y RPC

Protocolo petici respuesta Empaquetado y representaci externa de datos

UDP y TCP

} Capas Middleware{

Figura 1. Comunicación de Objetos

remotos

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 2. Capas middleware

2.1. Interfaces en los sistemas distribuidos

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

Figura 3. Modulos e

Interfaces

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

COMUNICACI ﾓ N ENTRE OBJETOS DISTRIBUIDOS

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 podría estar compuestos de un conjunto de

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

objetos remotos, lo que facilita la programación de este tipo

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.

3.3.2. 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 4. Comunicación entre objetos

distribuidos

Figura 5. Referencia a objetos

remotos

118

Figura 3. Modulos e

Interfaces

Figura 6. Interfaces

remotas

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.

3.3.4. Compactación 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 7. Acciones de un objeto

remoto

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

Figura 8. Invocaciones

semanticas

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.

4.1. Modulo de Comunicación:

Implementa en el envío de mensajes de petición y mensaje

de respuesta entre objetos remotos.

Hace el protocolo request-reply y utiliza el tipo de msg, reqId

y el objId a invocar.

121

Figura 9. Invocacion a metodos

remotos (RMI)

Figura 9. Invocacion a metodos

remotos (RMI)

Figura 10. Modulo de

comunicacion

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 RMI normalmente comprenden dos

programas separados: un servidor y un cliente. 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.

123

Figura 11. Aplicación RMI de

java

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 Remotos. Un interface

remoto especifica los métodos que 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 de otros interfaces (locales o

remotos) y otros métodos (que sólo 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 un a 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

trabajos sean enviados al 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

Figura 12. Interfaz compute

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 taskpackage 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 un a 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 locales son pasados por copia

utilizando el macanismo de 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 tiene la misma síntaxis URL que el

nombre pasado 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

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

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

Figura 13. Flujo de

mensaje

} /** * 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).multiply(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 fuente en

c:\home\waldo\src\compute (en UNIX 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 del servidor, ComputeEngine, la

implementación del objeto remoto del 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

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 la forma ClassName_Stub.class (y

opcionalmente ClassName_Skel.class). El 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

Detalles Específicos de la Plataforma: Compilar el Motor de Cálculo y sus Stubs

Windows.

cd c:\home\ana\srcjavac engine\ComputeEngine.javarmic -d . engine.ComputeEnginemkdir c:\home\ana\public_html\classes\enginecp engine\ComputeEngine_*.class c:\home\ana\public_html\classes\engine

Unix.

cd /home/ana/srcjavac engine/ComputeEngine.javarmic -d . engine.ComputeEnginemkdir /home/ana/public_html/classes/enginecp engine/ComputeEngine_*.class

ComputeEngine_Skel, en el directorio

c:\home\ana\src\engine. También 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 final es desempaquetar el fichero

compute.jar en el directorio

c:\home\ann\public_html\classes para 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\classesjar xvf compute.jar

Unix.

cd /home/ana/public_html/classesjar xvf compute.jar

El comando jar muestra esta salida.

created: META-INF/extracted: META-INF/MANIFEST.MFextracted: compute/Compute.classextracted: 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 (también disponible

mediante algunos servidores 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\classes\compute.jarcd c:\home\jones\srcjavac client\ComputePi.javajavac -d c:\home\jones\public_html\classes client\Pi.java

UNIX. setenv CLASSPATH /home/jones/src:/home/jones/public_html/classes/compute.jarcd /home/jones/srcjavac client/ComputePi.javajavac -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 CLASSPATHstart rmiregistryUNIX. unsetenv CLASSPATHrmiregistry &

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 2001UNIX. 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.jarjava -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.jarjava -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 o implemnetan objetos remotos, y

permitiéndoles gestionar los errores o diseñar 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

DISTRIBUIDOSLos sistemas de archivos distribuidos soportan la compraticion de

información en forma de archivos a través de internet. Un servicio de

archivos bien diseñado proporciona acceso a los archivos

alamacenados en un servidor con prestaciones y fiabilidad

semejantes (y en algunos casos mejor) que la 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

indicados, junto a

componentes

adicionales para

ocuparse de la

comunicación

cliente – servidor y

de la nomenclatura

y ubicación de los

archivos

distribuidos.

155

Tamaño del ArchivoMarca temporal de

creaciónMarca temporal de

lectura Marca temporal de

escritura Marca temporal de

atributosContador de

referenciasPropietarioTipo de archivosLista de control de

acceso

156

Figura 1. Estructura tipica de un sitema

de archivos

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

ProgramaDe

aplicaci

ProgramaDe

aplicaci

M ulo de cliente

Servicio de directorio

Servicio de archivos plano

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 de programación

sencilla con operaciones sobre archivos 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.

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

Figura 2. Arquitectura del servicio de

archivos

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.

• 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

ProgramaDe

aplicaci

ProgramaDe

aplicaci

Sistema de archivos virtual

Sistema de archivos UNIX

Otr

o si

stem

a de

ar

chiv

os

Cliente NFS

Local Remoto

ProtocoloNFS

N 昱 leo UNIX

Servidor NFS

Sistema de archivos UNIX

Sistema de archivos virtual

Computador servidorComputador Cliente

LLamadas al sistema UNIX

N 昱 leo UNIX

Figura 3. Sistema de archivos en

red de SUN

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 de factorización; factorización de grandes

números mediante el uso de redes distribuidas de

computadoras. Desafíos de RSA. Tamaños 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 prácticas de la criptografía cuántica –

perfomance; costos; actuales limitaciones. 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