Upload
carlosalmidon
View
1.772
Download
0
Embed Size (px)
Citation preview
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 com-
partimos 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 vis-
ta de la provisión de hardware, se comparten equipos como im-
presoras y discos para reducir costes. En la práctica los patrones
de compartir recursos varían mucho en su enlace y cuán estrecha-
mente 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 co-
municación. Para que se compartan de forma efectiva, cada recur-
so 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 men-
sajes 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, deci-
mos que el cliente invoca una operación del servidor. Se llama in-
vocació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
servidores. Los términos cliente y servidor se aplican a los roles
12
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 navega-
dor 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 secuen-
cias de vídeos, y para interaccionar con un conjunto ilimitado de
servicios.
El Web es un sistema abierto, puede ser ampliado e implementa-
do 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
implementados en muchos casos sobre diferentes plataformas; y
existen muchas implementaciones de servidores web.
13
Figura 5. Proceso Cliente – Proceso
Servidor
Segundo, el web es abierto respecto a los tipos de recursos que
pueden ser publicados y compartidos en él. En su forma más sim-
ple, 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 documen-
tos 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 Ma-
rkup 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 almacena-
dos 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 carac-
terí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, sis-
temas operativos, lenguajes de programación, etc.).
A pesar de que internet consta de muchos tipos de redes dife-
rente, sus diferencias se encuentran enmarcadas dado que to-
dos los computadores conectados a éste utilizan los protoco-
los 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 computa-
dor 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 alterna-
tivas para ordenar los bytes en el caso de los enteros. Hay que
tratar con estas diferencias de representación si se va a inter-
cambiar mensajes entre programas que se ejecutan en dife-
rente hardware.
Aunque los sistemas operativos de todos los computadores de
internet necesitan incluir una implementación de los protoco-
los 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 diferen-
tes 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 compu-
tador 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_tanenbaum/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,
proporcionando una interfaz de programación del sistema
24
a un nivel que facilita la comunicación y coordinación
entre procesos. Ejemplo: Windows, Linux, Solaris etc.
La plataforma
Contiene los servicios propios de cada computadora
concreta.
Depende del Hardware y del Sistema Operativo
Aplicación de
servicios
Middleware
Sistema
Operativo
Computador y
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.
25
Aplicación de
servicios
Middleware
Sistema
Operativo
Computador y
Hw. de red
Plataforma
Figura 1. Capas de servicio software y hardware en los sistemas distribuidos
Figura 2.
Middleware
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. 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
26
Servicio de Nombres para buscar objetos
De notificación de eventos
De control de Transacciones, etc.
¿Qué limitaciones impone?
– 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
28
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.
29
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.
30
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.
31
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
32
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).
33
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 em-
plean 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.
34
35
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.
36
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.
37
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í
38
Figura 13. Ordenamiento de
eventos
Figura 14. Tabla de entrada de
mensajes
Envia m Recibe
Proceso p Proceso q
Canal de Comunicación
Buffer de Mensajes entrantes.
Fallos por Omisión del canal Buffer de
Mensajes Salientes.
}Fallos por omisión de recepción.{Fallos por
omisión 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ón
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.
41
Proceso P Proceso Q
El enemigo
Copia de m
mm`^
Canal de comunicación
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_tanenbaum/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 nin-
gú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. Ade-
má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 seg-
mentació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 conversacio-
nes 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 separa-
das 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 satu-
ra con el tráfico de datos o falla, las partes individuales del mensa-
je aún pueden direccionarse hacia el destino mediante los recorri-
dos 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 ba-
rras 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 intermedia-
rios. Estos dispositivos utilizan la dirección host de des-
tino, conjuntamente con información sobre las intercone-
xiones de la red, para determinar la ruta que deben tomar
los mensajes a través de la red. Los procesos que se eje-
cutan 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 configu-
raciones 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 men-
saje desde el origen hasta el destino.
Las redes modernas utilizan principalmente tres tipos de me-
dios 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 men-
saje 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 transmi-
siones por fibra óptica dependen de pulsos de luz, dentro de
intervalos de luz visible o infrarroja. En las transmisiones ina-
lámbricas, los patrones de ondas electromagnéticas muestran
los distintos valores de bits.
Los diferentes tipos de medios de red tienen diferentes carac-
terí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
funcionamiento de los protocolos que se produce dentro de cada
53
Figura 3. Elementos de
una Red
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 dis-
positivo 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 acce-
so 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 interme-
diario.
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 Orga-
nization 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 de-
sarrollar una red internacional que no dependiera de sistemas
propietarios.
Lamentablemente, la velocidad a la que fue adoptada la Inter-
net basada en TCP/IP y la proporción en la que se expandió
ocasionaron que el desarrollo y la aceptación de la suite de
58
Figura 9. Operación de protocolo de envio y recepcion de
mensajes
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 reali-
zado aportes importantes para el desarrollo de otros protoco-
los 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 mensa-
jes 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 identificado-
res de dirección a los datos mientras bajan al stack del proto-
colo en el host de origen. Así como existen múltiples capas de
protocolos que preparan los datos para transmitirlos a sus des-
tinos, existen múltiples capas de direccionamiento para asegu-
rar 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 lo-
cal ú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 satis-
factoriamente por el host de destino, la información de la di-
rección de la Capa 2 se elimina mientras los datos se desen-
capsulan 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 utili-
zan 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 direc-
ció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 interme-
diario, por lo general un router, desencapsula la trama para
leer la dirección host de destino contenida en el encabezado
del paquete, la PDU de Capa 3. Los routers utilizan la porción
60
Figura 11. Direccionamiento por
capas
del identificador de red de esta dirección para determinar qué
ruta utilizar para llegar al host de destino. Una vez que se de-
termina 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 eje-
cuta en el dispositivo host de destino que actuará en los datos
que se entregan. Los hosts, sean clientes o servidores en Inter-
net, pueden ejecutar múltiples aplicaciones de red simultánea-
mente. La gente que utiliza computadoras personales general-
mente tiene un cliente de correo electrónico que se ejecuta al
mismo tiempo que el explorador Web, un programa de mensa-
jería instantánea, algún streaming media y, tal vez, incluso al-
gún juego. Todos estos programas ejecutándose en forma se-
parada 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 comu-
nique con un servidor Web. Al mismo tiempo, en segundo pla-
no, es posible que cliente de correo electrónico esté enviando
61
Figura 12. Direccionamiento en la capa 3
o recibiendo un e-mail y un colega o amigo enviando un men-
saje 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 emer-
gen 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 des-
tino 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
La capa de Transporte permite la segmentación de datos y brinda
el control necesario para reensamblar las partes dentro de los
62
Figura 13. Direccionamiento en la
capa 4
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.1Seguimiento 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.3Reensamble de segmentos:
En el host de recepción, cada sección de datos puede ser
direccionada a la aplicación adecuada. Además, estas
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
63
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.
Luego la capa de Transporte ordena estas secciones antes de
entregarlas a la aplicación adecuada.
64
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
Aplicación, mientras que cada segmento UDP sólo posee 8
66
Figura 14. Habilitacion de los dispositivos para la
comunicacion
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_tanenbaum/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ón respuesta Empaquetado y representación externa de datos
UDP y TCP
} Capas Middleware{Este
capítulo
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ípica 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.1 PASO DE MENSAJES PURO
Un mensaje es una colección de datos de cierto tipo
consistente en un encabezado y un cuerpo de longitudes
fijas o variables, la cual puede ser manejada por un
proceso y entregada a su destinatario. La comunicación
orientada a mensajes está íntimamente ligada al modelo
cliente-servidor. El proceso cliente envía un mensaje
(petición) a un proceso servidor y espera una respuesta o
continúa ejecutándose. Las primitivas de comunicación por
paso de mensajes son send y receive. En algunos sistemas,
la primitiva receive puede ser selectiva o condicional si se
agrega un guardia al llamar a la primitiva. Existen diversas
formas o interpretaciones semánticas de las primitivas:
4.1.1Direccionamiento:
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
en este caso la dirección del servidor es acordada
en forma anterior o durante el desarrollo de las
82
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
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,
83
Figura 6. Asignacion fija
predeterminada
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
Dentro de los sistemas distribuidos, hay muchos casos en
que una sola comunicación no resuelve problemas
85
Figura 7. Servidor de nombres
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]).
5 SINCRONIZACION DE PROCESOS
86
Como mencionamos anteriormente el paso de mensajes entre un
par de procesos se puede basar en dos operaciones, envía y
recibe definidas en función del destino y del mensaje. Para que un
proceso se pueda comunicar con otro, el proceso envía un
mensaje (una secuencia de bytes) a un destino y otro proceso en
el destino recibe el mensaje. Esta actividad implica la
comunicación de datos desde el proceso emisor al proceso
receptor y puede implicar además la sincronización de los
procesos.
Entonces a cada destino de mensajes se asocia una cola, los
procesos emisores producen mensajes que serán añadidos a las
colas remotas mientras que los procesos receptores locales
eliminaran mensajes de las colas locales.
La comunicación entre los proceso emisor y receptor puede ser
Síncrona o asíncrona.
5.1 Comunicación Síncrona
Lo procesos emisor y receptor se sincronizan con cada
mensaje, aquí tanto envía como recibe son operaciones
bloqueantes, es decir a cada envía producido el proceso
emisor se bloquea hasta que se produce el correspondiente
recibe y cuando se invoca un recibe el proceso se bloquea
hasta que llegue un mensaje
5.2 Comunicación Asíncrona
En la comunicación asíncrona la utilización de la operación
asíncrona es no bloqueante de tal forma que el proceso emisor
pueda continuar tan pronto como el mensaje haya sido
copiado en el buffer local, la transmisión del mensaje se lleva a
cabo en paralelo con el proceso emisor. La operación recibe
puede tener variantes bloqueantes y no bloqueantes.
Comunicación Síncrona Vs Comunicación Asíncrona
87
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.
• Ideal conceptualmente, pues solo hay 2 mensajes: envió y re-
cepción.
88
Figura 9. Comunicación Sincrona Vs. Comunicación
Asincrona
• 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.
Tres roles diferentes en la interacción
Cliente: Solicita servicio.
89
Figura 10. Comunicación peticion respuesta cliente -
servidor
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
Suele usarse para datos o servicios replicados
Grupo cerrado.
91
Figura 13. Esqueleto de la comunicación cliente – Servidor con paso
de mensajes
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?
RESUMEN
Los protocolos petición-respuesta que se puede construir un
protocolo específico para sistemas distribuidos efectivo
92
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/
o The Second International Conference on Autonomic
Computing and Communication Systems, September
2325, 2008, TURIN, http://www.autonomics.eu/
93
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_tanenbaum/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).
Se utiliza la estructura genérica de dirección:
97
Figura 2. Tabla de operaciones en archivos Vs
Operaciones en Sockets
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 di-
recciones internet, java proporciona una clase InetAddres, para re-
presentar las direcciones internet. Los usuarios de esta clase se
refieren a los computadores por sus nombres de host en el servi-
cio 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 trans-
mite un datagrama entre proceso cuando uno lo envía y el otro
lo recibe, cualquier proceso que necesite enviar o recibir men-
99
Figura 3. Proceso de transmision de datos con
Streams
Figura 3. Proceso de transmision de datos con
datagramas.
sajes debe crear primero un conector asociado a una dirección
de internet y a un puerto local. Un servidor enlazara su conec-
tor a un puerto de de servidor (uno que resulte conocido a los
clientes de forma que puedan enviarle mensajes). Un cliente li-
gara su conector a cualquier puerto local libre. El método reci-
be devolverá, además del mensaje, la dirección de internet y
el puerto del emisor, permitiendo al receptor enviar la corres-
pondiente 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 instan-
cia 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 transmiti-
das entre procesos cuando uno la envía y el otro la recibe.
DatagramaSocket:
Esta clase maneja conectores para enviar y recibir datagra-
mas UDP. Proporciona un constructor que toma un numero
de puerto como argumento, apropiado para los procesos
que necesitan utilizar un puerto concreto. También propor-
ciona un constructor sin argumentos que permite que el
sistema elija un puerto de entre los libres. Estos construc-
tores pueden lanzar una excepción SocketException si el
puerto ya esta siendo usado o si se especifica un puerto re-
servado.
Código java de un cliente UDP enviando un men-
saje a un servidor y recogiendo su respuesta:
100
Figura 3. Paquete del
datagrama
El código muestra un programa de un cliente que crea
un conector, envía un mensaje a un servidor en el puer-
to 6789, y después espera una respuesta. Los argumen-
tos 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());
}catch (IOException e){System.out.println("IO: " +
e.getMessage());}
}finally {if(aSocket != null) aSocket.close();}
101
}
}
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);
}
}catch (SocketException e)
{System.out.println("Socket: " + e.getMessage());
}catch (IOException e)
{System.out.println("IO: " + e.getMessage());}
102
}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.
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
103
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
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
104
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(); 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());}
105
}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());}
}public void run(){ try { // an echo server
String data = in.readUTF(); out.writeUTF(data);
} catch(EOFException e) {System.out.println("EOF:"+e.getMessage());
106
} 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.
ACTIVIDAD
Utilice el código de datagramas UDP (cliente-servidor), para
hacer un prototipo que pruebe las condiciones en las que los
107
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
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
108
í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_tanenbaum/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ón respuesta Empaquetado y representación 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
120
Figura 8. Invocaciones
semanticas
excepción. Es necesario considerar todos los
fallos posibles para enmascararlos.
121
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.
122
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
123
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 mecanis-
mos para obtener referencias a objetos remotos. Puede re-
gistrar 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 comunica-
ció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.
La figura muestra una aplicación RMI distribuida que utiliza
el registro para obtener referencias a objetos remotos. El
124
Figura 11. Aplicación RMI de
java
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éto-
do. Esta ilustración también muestra que el sistema RMI
utiliza una servidor Web existente para cargar los byteco-
des 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
distribuida, se asume que algunas implementaciones
residen en diferentes máquinas virtuales. Los objetos
125
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.r-
mi.Remote.
Cada método del interface declara que lanza una ja-
va.rmi.RemoteException además de cualquier excep-
ció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.
Diseñar e implementar los componentes de nuestra
aplicación distribuida.
Compilar los Fuentes y generar stubs.
126
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 remo-
to especifica los métodos que pueden ser llamados re-
motamente 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 inter-
faces 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 re-
motos deben implementar uno o varios interfaces re-
motos. La clase del objeto remoto podría incluir imple-
mentaciones de otros interfaces (locales o remotos) y
otros métodos (que sólo estarán disponibles localmen-
te). 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.
Implementar los Clientes. Los clientes que utilizan
objetos remotos pueden ser implementados después
de haber definido los interfaces remotos, incluso des-
pués de que los objetos remotos hayan sido desplega-
dos.
127
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
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
128
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
llamados desde el cliente. Esencialmente, el interface define
lo que el cliente ve del objeto remoto. La clase proporciona la
implementación.
5.2.1. Diseñar una Interface Remoto
129
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 RemoteExcep-tion; }
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
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.
130
Figura 12. Interfaz compute
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 una Interface Remoto
La clase que implementa el interface Compute,
implementa un objeto remoto. Esta clase también
propociona el resto del código que configura el programa
servidor: un método main que crea un ejemplar del
objeto remoto, lo registra con la facilidad de nombrado, y
configura un controlador de seguridad, la
implementación de la clase para un interface remoto
debería al menos.
Declarar los Interfaces remotos que están siendo im-
plementados.
Definir el constructor del objeto remoto.
Proprorcionar una implementación para cada método
remoto de cada interface remoto.
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
131
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 ser-
vicio 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 UnicastRemo-teObject 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 RMISecurity-Manager());
} String name = "//localhost/Compute"; try { Compute engine = new ComputeEngine(); Naming.rebind(name, engine); System.out.println("ComputeEngine bound"); } catch (Exception e) { System.err.println("ComputeEngine excep-
tion: " + e.getMessage()); e.printStackTrace();
} }}
132
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 UnicastRemo-
teObject
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 imple-
mentaciones para todos los métodos remotos espe-
cificados en los interfaces remotos. El interface
Compute contiene un sólo método remoto, execute-
Task, que se implementa de esta forma.
public Object executeTask(Task t) {
return t.execute();
}
Pasar Objetos en RMI
Los argumentos y los tipos de retorno de los méto-
dos remotos pueden ser de casi cualquier tipo Java,
133
incluyendo objetos locales, objetos remotos y tipos
primitivos. Más precisamente, una entidad de cual-
quier tipo Java puede ser pasada como un argumen-
to 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 imple-
menta 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 re-
moto.
Los objetos locales son pasados por copia utilizan-
do el macanismo de serialización de objetos de
Java. Por defecto, todos los campos se copian, ex-
cepto aquellos que están marcados como static o
transient. El comportamiendo de la serialización
por defecto puede ser sobrecargado en una bási-
ca 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
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
134
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 de-
termina si el código descargado tiene acceso al
sistema de ficheros local o puede realizar cual-
quier otra operación privilegiada.
Aquí temos el código que crea e instala el contro-
lador de seguridad.
if (System.getSecurityManager() == null) {
System.setSecurityManager(new RMISecurity-
Manager());}
Poner el Objeto Remoto a Disposición de los
Clientes
Luego, el método main crea un ejemplar de Com-
puteEngine. Esto se hace con la sentencia.
Compute engine = new ComputeEngine();
Antes de que un llamador pueda invocar un méto-
do de un objeto remoto, debe obtener una refe-
rencia al objeto remoto. Este puede hacerse de la
misma forma que en que se obtiene cualquier
otra referencia en un programa Java, que es obte-
niéndolo como parte del valor de 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
135
/Compute";
Este nombre incluye el nombre del host localhost,
en el que se están ejecutando el registro y el ob-
jeto remoto, y un nombre Compute, que identifica
el objeto remoto en el registro. Luego está el códi-
go 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 sen-
tencia.
Naming.rebind(name, engine);
Una vez que el servidor se ha registrado en el re-
gistro RMI local, imprime un mensaje indicando
que está listo para empezar a manejar llamadas,
y sale del método main. Como el programa entre-
ga una referencia de ComputeEngine en el regis-
tro, é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 lla-
madas y no será reclamado hasta que.
su nombre sea eliminado del registro, y
ningún cliente remoto mantenga una referen-
cia al objeto ComputeEngine.
La pieza final de código del método ComputeEngi-
ne.main maneja cualquier excepción que pudiera
producirse.
5.2.3. Crear un Programa Cliente
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 defi-
nir la tarea que éste va a realizar.
136
Nuestro ejemplo está compuesto por dos clases separa-
das. la primera clase ComputePi, busca y llama a un ob-
jeto Compute. La segunda clase Pi, implementa el inter-
face 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 re-
mota 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 Se-
rializable, y hubiera tenido el mismo efecto. Sin embar-
go, 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 ex-
plícitamente los dos interfaces en el tipo system, asegu-
rando 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 obje-
to Task, y luego pedir que se ejecute la tarea. Más ade-
lante 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.
137
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 RMISecurity-
Manager());
}
try {
String name = "//" + args[0] + "/Compute";
Compute comp = (Compute)
Naming.lookup(name);
Pi task = new Pi(Integer.parseInt(args[1]));
BigDecimal pi = (BigDecimal) (comp.execute-
Task(task));
System.out.println(pi);
} catch (Exception e) {
System.err.println("ComputePi exception: " +
e.getMessage());
e.printStackTrace();
}
}
}
Al igual que el servidor ComputeEngine, el cliente empie-
za instalando un controlador de seguridad. Esto es nece-
sario 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
138
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 re-
moto 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 re-
moto 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 pasa-
do a la llamada Naming.rebind que explícamos en pági-
nas 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 execu-
teTask del objeto remoto Compute. El objeto pasado en
la llamada a executeTask devuelve un objeto del tipo ja-
va.math.BigDecimal, por eso el programa fuerza el resul-
tado a ese tipo y almacena en resultado en la variable
result. Finalmente el programa imprime el resultado.
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
139
Figura 13. Flujo de
mensaje
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); } /** * 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.
140
*/ 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).sub-tract(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) { 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
141
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
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)
142
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
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.
143
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 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
144
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
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\
145
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
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
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.java
146
javac -d /home/jones/public_html/classes client/Pi.java
Sólo necesitamos situar la clase Pi en el directorio
public_html\classes\client (el directorio client lo crea el
javac si no existe). Esto es así por esta clase es la única
que necesita ser desacargada por la máquina virtual del
motor de cálculo.
5.4. Ejecutar el Ejemplo
Una Nota sobre la Seguridad
El modelo de seguridad del JDK 1.2 es más sofisticado que el
modelo utilizado en el JDK 1.1. Contiene ampliaciones para
seguridad de grano fino y requiere código que permita los
permisos específicos para realizar ciertas operaciones.
En el JDK 1.1, todo el código que haya en el path de clases se
considera firmado y puede realizar cualquier operación, el
código descargado está gobernado por las reglas del
controlador de seguridad instalado. Si ejecutamos este
ejemplo en el JDK 1.2 necesitaremos especificar un fichero de
policía cuando ejecutemos el servidor y el cliente. Aquí
tenemos un fichero de policía general que permite al código
descargado desde cualquier codebase, hacer dos cosas.
conectar o acceptar conexiones en puertos no privilegia-
dos (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.
147
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
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).
148
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.
Detalles Específicos de la Plataforma - Seleccionar la variable 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
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
149
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.
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
150
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
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
151
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á
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/
rmi/
o RMI y CORBA (RMI sobre IIOP);
http://developer.java.sun.com/developer/earlyAccess/idlc/
152
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_tanenbaum/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
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 Archivo
Marca temporal de
creación
Marca temporal de
lectura
Marca temporal de
escritura
Marca temporal de
atributos
Contador de
referencias
Propietario
Tipo de archivos
Lista 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ón
ProgramaDe
aplicación
Módulo 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 sis-
tema de UNIX, y si lo hacen, podrían integrarse de la misma for-
ma. La integración se obtiene mediante un módulo de archivos
virtual (VFS), que ha sido añadido al núcleo de UNIX para distin-
guir entre archivos remostos y locales y para traducir los iden-
tificadores de archivos, independientes de UNIX y otros siste-
mas de archivos. En resumen, VFS mantiene la pista de los sis-
temas de archivos que están actualmente disponibles tanto lo-
cal como remotamente, pasa cada solicitud al módulo del siste-
ma local apropiado (el sistema de archivos UNIX, el módulo
cliente NFS o el módulo de servicio de otro sistema de archi-
vos).
160
ProgramaDe
aplicación
ProgramaDe
aplicación
Sistema de archivos virtual
Sistema de archivos UNIX O
tro
sist
ema
de
arch
ivos
Cliente NFS
Local Remoto
ProtocoloNFS
Núcleo UNIX
Servidor NFS
Sistema de archivos UNIX
Sistema de archivos virtual
Computador servidorComputador Cliente
LLamadas al sistema UNIX
Núcleo UNIX
Figura 3. Sistema de archivos en
red de SUN
Los identificadores de archivos utilizados en NFS se llama apun-
tadores de archivos (file handles). Un apuntador de archivo es
opaco para los clientes y contiene toda la información que ne-
cesita el servidor para distinguir un archivo individual.
Integración del Cliente.- El cliente NFS juega el papel descri-
to 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 primiti-
vas 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 ni-
vel 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 usua-
rio.
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_tanenbaum/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_tanenbaum/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