Sistemas Distribuidos UPLA PDF

Copyright©2005 UNIVERSIDAD PERUANA LOS ANDES
Programa de Educación a Distancia.

Huancayo – Perú
Prohibida la reproducción total o parcial sin autorización

por escrito del Rector de la Universidad.
La redacción de este texto estuvo a cargo de

Ing. Carlos Alcides Almidón Ortiz.
1
Presentación
La evolución de las tecnologías de la información y comunicación en el mundo
nos permite implementar diferentes aplicaciones en la red, debido esto la
generalización del termino cloud computing (servicios en el internet), la
popular nube, como paradigma de todo tipo, tanto organizativo como de
diseño de sistemas, conlleva a una interesante reflexión.
Si la nube permite a los clientes y usuarios poder obtener funcionalidades a
través de servicios, de los cuales solo conocen su contrato de servicio pero
ignoran el diseño y la localización. Muchas veces olvidamos que los servicios
han de ser fabricados y que para ese trabajo hay que prepararse, entonces aquí
ingresa el diseño de los sistemas distribuidos.
Un sistema distribuido es un sistema de información en el cual las funciones se
reparten por áreas de trabajo diferentes que trabajan de forma coordinada para
asumir los objetivos que la organización asigna a ese sistema de información.
En este manual se trata de dar un alcance al estudiante de cómo diseñar
sistemas distribuidos, que consiste en crear aplicaciones de software que,
utilizando servicios y ayudándose de la conectividad, participen y se integren
en este entorno de forma transparente a las plataformas de proceso y de
almacenamiento de datos, dotándolas de los recursos necesarios para
gestionarse de forma integrada con el resto del sistema distribuido.
Los sistemas distribuidos que se diseñen y construyan deben estar alineados
con los objetivos de negocio de la empresa, aumentar la eficacia y eficiencia
operacional de la compañía y permitir el mayor rendimiento con el menor
costo en las estructuras informáticas que dan soporte.
El autor
2
Programación general
Conceptos de los Sistemas Distribuidos

Autoaprendizaje 3 horas
Unidad 1
Modelos de Sistemas Distribuidos
Unidad 2
Comunicación a Nivel de Redes.
Autoaprendizaje, 3 horas
Unidad 3
Comunicación de procesos en los Sistemas Distribuidos.
Unidad 4
Comunicación a bajo nivel, Sockets.
Unidad 5
Objetos Distribuidos e Invocacion Remota
Unidad 6
Sistemas de Archivos Distribuidos
Unidad 7
Seguridad en Sistemas Distribuidos

Unidad 8
3
Tabla de contenido Página
Presentación
Programa general
Unidad Académica 01
Sistemas Distribuidos 4
1. Caracteristicas de los sistemas distribuidos 4
2. Recursos compartidos y web. 10
3. Desafios de los sistemas distribuidos 13
Unidad Académica 02
Modelos de Sistemas Distribuidos

1. Modelos Arquitectónicos 21
2. Modelos Fundamentales
2.1 Modelo de Interacción 31
4
UNIDAD ACADÉMICA Nº 01
Sistemas Distribuidos
Un sistemas Distribuido es aquel en el que los componentes hardware o
software, localizados en computadores unidos mediante red, comunican y
coordinan sus acciones sólo mediante paso de mensajes.
Figura 1. Representación de un Sistema Distribuido
INDICADORES DE LOGRO
Al terminar esta unidad el estudiante estará en condiciones de:
 Definir y describir que es un Sistemas Distribuidos.
 Describir las caracteristicas de un Sistema Distribuidos.
 Describir los desafíos de los Sistemas Distribuidos.
 Realizar ejemplos de Sistemas Distribuidos.
1. CARACTERISTICAS DE LOS SISTEMAS DISTRIBUIDOS

Existen redes de computadoras en cualquier parte. Una de ellas es Internet,
como los son las muchas redes de las que se compone. Las redes de
teléfonos móviles, las redes corporativas, las de las empresas, los campus,
las casas, redes dentro del coche, todas, tanto separados, como combinadas,
comparten las características esenciales que las hacen elementos
importantes para su estudio bajo el título de Sistemas Distribuidos.
5
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: Figura 2. Internet
 Concurrencia.- En una red de computadores, la ejecución de programas

concurrentes es la norma. Usted puede estar realizando un trabajo en su
computador, mientras otra persona también y a la vez ambos comparten
recursos como páginas web o ficheros, cuando es necesario. La capacidad
del sistema para manejar recursos compartidos se puede incrementar
añadiendo más recursos (por ejemplo computadoras) a la red.
Ventajas: Trabajo Cooperativo.
Inconvenientes: Programación Compleja.
 Inexistencia 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
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
6
lenta. De forma similar, la parada de un computador o la terminación
inesperada de un programa en alguna parte del sistema no se da a
conocer inmediatamente a los demás componentes con los que se
comunica.
 Razones de Su Origen.-
Compartir Recursos:
 Procesos
 Archivos
 Servicios
Figura 3. Red LAN, WAN
Ejemplos de Sistemas Distribuidos

Planteamos ejemplos basados en redes de computadoras conocidas y
utilizadas ampliamente Internet, Intranets y la tecnología emergente basada
en dispositivos móviles. Se han elegido para proporcionar ejemplos del
amplio rango de servicios y aplicaciones que son soportados por redes de
computadoras y para comenzar la discusión de las cuestiones técnicas que
entraña su implementación.
Ejemplo 1:
Internet:
Es una vasta colección de redes de computadoras de diferentes tipos
interconectados. Programas ejecutándose en los computadores conectados a
ella interactúan mediante paso de mensajes, empleando un medio común
de comunicación. Internet, también es un sistema distribuido muy grande.
Permite a los usuarios, donde quiera que estén, hacer uso de servicios como
el 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.
7
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 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
8
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.
Figura 4. Computacion Movil y Ubicua
9
2. RECURSOS COMPARTIDOS Y WEB.
Como estamos viendo hasta ahora que los sistemas distribuidos trabajan a
nivel de redes, y en este escenario normalmente compartimos recursos
hardware como impresoras, recursos de datos como ficheros, y recursos con
una funcionalidad más específica como máquinas de búsqueda.
Considerado desde el punto de vista de la provisión de hardware, se
comparten equipos como impresoras y discos para reducir costes. En la
práctica los patrones de compartir recursos varían mucho en su enlace y
cuán estrechamente trabajan juntos los usuarios. Los recursos en un sistema
distribuido están encapsulados físicamente con los computadores y solo
pueden ser accedidos desde otros computadores y sólo pueden ser
accedidos desde otros computadores a través de comunicación. Para que se
compartan de forma efectiva, cada recurso debe ser gestionado por un
programa que ofrece una interfaz de comunicación permitiendo que se
acceda y actualice el recurso de forma fiable y consistente.
El termino servidor es probablemente familiar para la mayoría de los
lectores. Se refiere a un programa en ejecución (un proceso) en un
computador en red que acepta peticiones de programas que se están
ejecutando en otros computadores para realizar un servicio y responder
adecuadamente. Los procesos solicitantes son llamados clientes. Las
peticiones se envían a través de mensajes desde los clientes al servidor y las
contestaciones se envían mediante mensajes desde el servidor a los clientes.
Cuando un cliente envía una petición para que se realice una operación,
decimos que el cliente invoca una operación del servidor. Se llama
invocación remota a una interacción completa entre un cliente y un
servidor, desde el instante en el que el cliente envía su petición hasta que
recibe la respuesta del servidor.
El mismo proceso puede ser tanto un cliente como un servidor, puesto que
los servidores a veces invocan operaciones en otros servidores. Los
términos cliente y servidor se aplican a los roles desempeñados en una
única solicitud. Ambos son distintos, en muchos aspectos, los clientes son
10
activos y los servidores pasivos, los servidores se están ejecutando
continuamente, mientras que los clientes sólo lo hacen el tiempo que duran
las aplicaciones de las que forman parte.
Figura 5. Proceso Cliente – Proceso Servidor
Hay que señalar que por defecto los términos cliente y servidor se refieren
a procesos no a los computadores en las que se ejecutan, aunque en
lenguaje coloquial dichos términos se refieren también a los propios
computadores.
2.1 El World Wide Web
Es un sistema en evolución para publicar y acceder a recursos y servicios a
través de internet. Utilizando el software de un navegador web, fácilmente
disponible como Netscape o Internet Explorer, los usuarios utilizan el Web
para recuperar y ver documentos de muchas clases, para escuchar
secuencias de audio y ver secuencias de vídeos, y para interaccionar con un
conjunto ilimitado de servicios.
El Web es un sistema abierto, puede ser ampliado e implementado en
nuevas formas sin modificar su funcionalidad existente.
Primero, su operación está basada en estándares de comunicación y en
documentos estándares que están publicados libremente e implementados
en muchos casos sobre diferentes plataformas; y existen muchas
implementaciones de servidores web.
Segundo, el web es abierto respecto a los tipos de recursos que pueden ser
publicados y compartidos en él. En su forma más simple, un recurso es una
11
página web o algún otro tipo de contenido que puede ser almacenada en un
fichero y presentado al usuario, como ficheros de programa, de imágenes,
de sonido y documentos en formato PostScript o PDF.
El Web está basado en tres componentes tecnológicos de carácter estándar
básicos:
 El lenguaje de etiquetado de hipertexto (HTML, Hypertext Markup
Languaje) es un lenguaje para especificar el contenido y el diseño de las
páginas que son mostradas para los navegadores.
 Localizadores Uniformes de Recursos (URL, Uniform Resource Locator)
que identifican documentos y otros recursos almacenados como parte de
la Web.
 El protocolo de transferencia hipertexto – (HTTP, hyperText Transfer
Protocol) mediante la cual los navegadores y otros clientes obtienen
documentos y otros recursos de los servidores web.
Figura 6. Recursos Compartidos en la web
12
3. DESAFIOS DE LOS SISTEMAS DISTRIBUIDOS
En la actualidad tenemos muchos sistemas distribuidos a nuestro servicio
en la vida diaria, aquí tratamos de dar algunos criterios para diseñar
sistemas distribuidos teniendo en cuenta sus características
3.1 Heterogeneidad
Se refiere a la variedad y diferencia que podemos encontrar en los
elementos que componen una red de computadores sobre la que se
ejecuta un sistema distribuido. (Redes, hardware, sistemas operativos,
lenguajes de programación, etc.).
A pesar de que internet consta de muchos tipos de redes diferente, sus

diferencias se encuentran enmarcadas dado que todos los
computadores conectados a éste utilizan los protocolos de internet para
comunicarse una con otra. Por ejemplo un computador conectado a
Ethernet tiene una implementación de los protocolos de Internet sobre
ethernet, así un computador en un tipo de red diferente necesitará una
implementación de los protocolos de internet para esa red. Los tipos de
datos, como los enteros, pueden representarse de diferente forma en
diferentes clases de hardware, por ejemplo hay dos alternativas para
ordenar los bytes en el caso de los enteros. Hay que tratar con estas
diferencias de representación si se va a intercambiar mensajes entre
programas que se ejecutan en diferente hardware.
Aunque los sistemas operativos de todos los computadores de internet
necesitan incluir una implementación de los protocolos de internet, no
todas presentan necesariamente la misma interfaz de programación
para estos protocolos. Por ejemplo, las llamadas para intercambiar
mensajes en UNIX son diferentes de las llamadas en Windows 2003
server.
La heterogeneidad se aplica en los siguientes elementos:
 Redes
 Hardware de computadores
 Sistemas operativos
13
 Lenguajes de programación
 Implementaciones de diferentes desarrolladores.
3.1.1. Middleware
El middleware es un software de conectividad que ofrece un conjunto
de servicios que hacen posible el funcionamiento de aplicaciones
distribuidas sobre plataformas heterogéneas. Funciona como una capa
de abstracción de software distribuida, que se sitúa entre las capas de
aplicaciones y las capas inferiores (sistema operativo y red). El
middleware nos abstrae de la complejidad y heterogeneidad de las
redes de comunicaciones subyacentes, así como de los sistemas
operativos y lenguajes de programación, proporcionando una API para
la fácil programación y manejo de aplicaciones distribuidas.
Dependiendo del problema a resolver y de las funciones necesarias,
serán útiles diferentes tipo de servicios de middleware
Es el estrato de software que provee una abstracción de programación,
así como un enmascaramiento de la heterogeneidad subyacente de las
redes, hardware, sistemas operativos y lenguajes de programación.
Ejem: Corba, Java RMI.
Figura 7. Sistemas Distribuidos como MIddleware
14
3.1.2. Heterogeneidad y código móvil
 Código Móvil: código que puede enviarse desde un computador a
otro y ejecutarse en este último.
 El concepto de máquina virtual ofrece un modo de crear código
ejecutable sobre cualquier hardware.
3.2. Extensibilidad
Es la característica que determina si el sistema puede extenderse de
varias maneras. Un sistema puede ser abierto o cerrado con respecto a
extensiones de hardware o de software.
Para lograr la extensibilidad es imprescindible que las interfaces clave
sean publicadas.
Los Sistemas Distribuidos Abiertos pueden extenderse a nivel de
hardware mediante la inclusión de computadoras a la red y a nivel de
software por la introducción de nuevos servicios y la reimplementación
de los antiguos.
Otro beneficio de los sistemas abiertos es su independencia de
proveedores concretos.
3.3. Seguridad
La seguridad tiene tres componentes:
Confidencialidad: protección contra individuos no autorizados.
Integridad: protección contra la alteración o corrupción.
Disponibilidad: protección contra la interferencia que impide el acceso a
los recursos.
Existen dos desafíos que no han sido resueltos en su totalidad:
servicio.
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:
15
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.
Cada objeto que represente un recurso compartido debe
responsabilizarse de garantizar que opera correctamente en un entorno
concurrente.
16
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.
o Proporcione ejemplos de tres tipos de recursos web a los que
puede darse el nombre de URL.
17
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
o George Colouris, “Sistemas Distribuidos” Conceptos y Diseño,
Addison Wesley, España 2001
http://www.cdk3.net/
18
o Tanenbaum, Distributed Systems: Principles and Paradigms,
Prentice Hall, Mexico 2002.
http://www.prenhall.com/divisions/esm/app/author_tanenbau
m/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 sincronizarse los relojes de un mayor
numero de computadores conectados a Internet?.
19
MODELOS DE SISTEMAS
DISTRIBUIDOS
Los sistemas pensados para trabajar en entornos reales deben diseñarse para
funcionar correctamente en el rango de circunstancias mas amplio posible y
considerando todas las dificultades de amenazas (modos de utilización muy
variable, amplio rango de entornos, problemas internos, amenazas externas).
Esto conlleva a sugerir que los sistemas distribuidos de tipos diferentes
comparten importantes propiedades subyacentes y dan lugar a problemas de
diseño comunes, en este capitulo se presenta las propiedades y temas de diseño
comunes para los sistemas distribuidos bajo la forma de de modelos
descriptivos. Cada modelo está pensado para proporcionar una descripción
abstracta, simplificada pero consistente, de cada aspecto relevante del diseño de
un sistema distribuido.
En los modelos de Sistemas Distribuidos tenemos 2 tipos:
 Los modelos Arquitectónicos
 Los modelos Fundamentales.
 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.
20
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 a un nivel que facilita la comunicación y coordinación
entre procesos. Ejemplo: Windows, Linux, Solaris etc.
21
La plataforma
 Contiene los servicios propios de cada computadora concreta.
 Depende del Hardware y del Sistema Operativo
Aplicación de
servicios
Middleware
Sistema
Operativo
Plataforma
Computador y
Hw. de red
Figura 1. Capas de servicio software y hardware
en los sistemas distribuidos
 Middleware:
Es una capa de software cuyo propósito es enmascarar la
heterogeneidad y proporcionar un modelo de programación
conveniente para los programadores de aplicaciones.
Aplicación de
servicios
Middleware
Sistema
Operativo
Computador y
Hw. de red
Figura 2. Middleware
Son procesos u objetos que implementan mecanismos de

comunicación y recursos compartidos para aplicaciones
distribuidas.
El middleware se ocupa de proporcionar bloques útiles para la
construcción de componentes de software que puedan trabajar
con otros en un sistema distribuido.
En particular mejora el nivel de las actividades de comunicación
de los procesos de aplicación soportando abstracciones como:
22
llamadas a procedimientos remotos, comunicación entre un grupo
de procesos, etc.
Ejem: Sun RPC (llamadas a procedimientos remotos), CORBA
(middleware orientado a objeto), Java RMI (invocación de objetos
remotos en Java), DCOM (Modelo común de objetos distribuidos
de Microsoft).
El middleware también puede proporcionar otros servicios, aparte
de la comunicación, para su uso en programas de aplicación.
Por ejemplo: gestión de nombres, seguridad, almacenamiento
persistente, etc.
El middleware
 Permite enmascarar la heterogeneidad.
 Puede dar un modelo y una interfaz de programación utilizable
 Puede soportar abstracciones como:
– Procedimientos de invocación remota (RPC).
– Comunicación entre grupos de procesos.
– Eventos, replicación, servicios multimedia, etc.
¿Qué forma tiene el Middleware?
– Bibliotecas adicionales
Procedimientos de invocación remota(RPC).
Objetos Remotos (RMI, CORBA)
– Herramientas de Programación.
Lenguajes de definición de Interfaces + compiladores para
ellos.
– Servicios Básicos de ayuda
Servicio de Nombres para buscar objetos
De notificación de eventos
De control de Transacciones, etc.
¿Qué limitaciones impone?
– Se incrementa la complejidad arquitectónica.
Hay mas niveles
23
– Hay que aprender más herramientas.
– Se pierde el control de bajo nivel sobre los modos de fallo.
– Se depende de varias personas.
2.1.2 ARQUITECTURA DE LOS MODELOS

La división de responsabilidades entre los componentes del sistema
(aplicaciones, servidores y otros procesos) y la ubicación de los
componentes en la red es el aspecto más importante en el diseño de un
sistema distribuido.
Sus implicancias fundamentales están en las prestaciones, fiabilidad y
seguridad del sistema resultante.
Principales modelos arquitectónicos.
 Modelo cliente servidor
 Múltiples servidores
 Procesos de igual a igual
2.1.3 MODELO CLIENTE – SERVIDOR
Clientes que invocan a servidores individuales. El servidor puede o no
estar en la misma máquina del cliente. Tanto servidores como clientes
pueden ser iterativos o concurrentes.
El más común de modelos (DNS, Web, ftp, telnet, etc.)
Un servidor puede ser cliente de otro servicio. (servidor web,
Crawler )
Figura 3. Clientes que invocan a servidores individuales.
24
 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
Servidor
Cliente
Servidor
Cliente
Servidor
Figura 4. Un servicio proporcionado por multiples servidores.
 Servidores Proxy y Caches

Cache: almacén de objetos de datos utilizados recientemente, y se
encuentra más próximo que los objetos en sí. Al recibir un objeto
nuevo en un computador se añade al almacén de la cache
reemplazando si fuera necesario algunos objetos existentes.
Figura 5. Un servidor proxy del tipo web
25
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
Figura 6. Como funciona un proxy
 Procesos Peer-to-Peer
En esta arquitectura todos los procesos desempeñan tareas
semejantes, interactuando cooperativamente como iguales para
realizar una actividad distribuida de cómputo sin distinción entre
clientes y servidores.
Los procesos pares mantienen la consistencia de los recursos y
sincroniza las acciones a nivel de aplicación.
Figura 7. Aplicación distribuida basa en

proceso de igual a igual
26
Ú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
Figura 8. Interfaz de un dispositivo movil
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.
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.).
27
Figura 9. Applet del tipo web.
Algunas Posibilidades:
Según la ubicación del código del proceso del cliente:
 Código estático
 Código con movilidad (recolocación del proceso)
Según la proporción de tareas que recae sobre el cliente y el servidor:
 Clientes al estilo habitual
 Clientes ligeros de aplicaciones complejas
 Computadoras de red
Figura 10. Distribucion de carga

Red Espontanea
Ventajas
 Facilidad de conexión a la red local
 Facilidad de integración con los servicios locales
Problemas
 Seguridad
 Conectividad
28
 Servicio de detección.
Figura 11. Intercomunicacion espontanea en un hotel

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).
Productividad: trabajos/unidad de tiempo.
Balance de cargas: applets, varios servidores o computadores para
alojar un único servicio.
29
 Calidad de Servicio
Algunas aplicaciones mantienen datos críticos en el tiempo, flujos
de datos que precisan ser procesados o transferidos de un proceso a
otro a una tasa prefijada.
QoS es la capacidad de los sistemas para satisfacer dichos límites.
El satisfacer tales exigencias depende de la disponibilidad de los
recursos en los instantes adecuados.
Cada recurso crítico debe reservarse para las aplicaciones que
requieren QoS. Los administradores de los recursos deben
proporcionar la garantía. Las solicitudes de reserva que no se
puedan cumplir se rechazan.
 Aspectos de Fiabilidad (que el sistema funcione correctamente)
Correctitud
 Tolerancia de fallos
 Seguridad:
 Confidencialidad
 Integridad
 Disponibilidad.
Tolerancia a Fallos: las aplicaciones estables deben continuar
funcionando correctamente en presencia de fallos de hw, sw y
redes.
 Se logra con redundancia
 Para hacer fiable un protocolo de comunicación se emplean
otras técnicas. Ejem. Retransmitir el mensaje.
Seguridad
Necesidad de ubicar datos y otros recursos sensibles sólo en
aquellos computadores equipados de un modo eficaz contra el
ataque.
30
2.2 MODELOS FUNDAMENTALES
Los modelos fundamentales están implicados en una descripción más
formal de las propiedades que son comunes en los modelos arquitectónicos.
Ayudan a localizar los problemas clave para los diseñadores de Sistemas
Distribuidos. Su propósito es especificar los problemas, dificultades y
amenazas que deben superarse para desarrollar sistemas distribuidos
fiables.
Principales modelos
 De Interacción
 De Fallo
 De seguridad
2.2.1. Modelo de Interacción
Trata sobre el rendimiento y sobre la dificultad de poner límites
temporales en un sistema distribuido.
La forma en que se produce el “paso de mensajes” entre los procesos
restringe el modo de operación
Figura 12. Modelo de iteraccion de un Sistema Distribuido
En la comunicación hay retrasos. El modelo estudia cómo afectan

estos retrasos la coordinación de los procesos.
Entonces encontramos problemas de 2 tipos
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.
31
 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.
32
Ordenamiento de Eventos
Aún cuando no hay relojes precisos la ejecución de un sistema
se puede describir en términos de los eventos y su ordenación.
Ejemplo:
1. X envía un mensaje de reunión
2. Y y Z responden
3. X envía
4. Y lee y responde
5. Z lee X, y Y envía otra respuesta.
Ordenamiento de Eventos
Figura 13. Ordenamiento de eventos
Si estuvieran sincronizados seria así
Figura 14. Tabla de entrada de mensajes
33
2.2.2 Modelo de Fallos
Intenta dar una especificación precisa de los fallos que se pueden
producir en procesos y en canales de comunicación.
Fallos por omisión
 De procesos
 De comunicaciones.
Fallos de procesos
Ruptura accidentada del procesamiento.
Es deseable si el resto de los procesos que interactúan con el proceso
interrumpido, o bien funcionan correctamente o se detienen.
El método de detección de ruptura descansa en timeouts.
Fail- Stop: es cuando el resto de los procesos puede detectar con
certeza que cierto proceso interrumpió su ejecución. Se puede detectar
en un sistema síncrono por los timeouts.
Fallos por omisión de comunicaciones.
 Fallos por omisión de envíos.
 Pérdida de mensajes entre los buffers.
 Fallos por omisión de recepción.
Proceso p Proceso q
Envia m Recibe
omisión
de envio.{
Fallos por
Canal de Comunicación
Fallos por Omisión

}
Fallos por
omisión de
recepción.
Buffer de del canal Buffer de

Mensajes entrantes. Mensajes Salientes.
Figura 15. Fallos por omision de canal
Enmascaramiento de fallos
 Ocultar el fallo.
 Convertirlo en un tipo razonable
Fiabilidad y comunicación uno a uno. El término comunicación fiable
se define en términos de validez e integridad.
34
 Validez: cualquier mensaje en el buffer de salida llega
eventualmente al buffer de mensajes entrantes.
 Integridad: el mensaje recibido es idéntico al enviado y no se
reparten mensajes por duplicado.
 Amenazas de Integridad
 Protocolos que retransmiten pero no usan números de
secuencia para evitar que el mismo mensaje llegue duplicado.
 Usuarios mal intencionados que insertan mensajes inválidos,
repiten mensajes antiguos o modifican mensajes auténticos.
2.2.3. Modelo de seguridad
La seguridad de un SD puede lograrse asegurando los procesos y los
canales empleados para sus interacciones y protegiendo los objetos
que se encapsulan contra el acceso no autorizado.
Figura 16. Modelo de Seguridad de sistemas distribuidos
Protección de Objetos
 Los objetos pueden contener datos privados y públicos o
compartidos.
 Se otorgan derechos de acceso que especifican a quien se permite
realizar ciertas operaciones sobre un objeto. Los usuarios son los
principales beneficiarios de estos derechos de acceso.
 A cada invocación y a cada resultado se le asocia la autoridad con
que se ordena. Tal autoridad se denomina principal.
35
 El servidor es responsable de verificar la identidad del principal
tras la invocación y comprobar que dispone de los diferentes
derechos para realizar operaciones sobre el objeto.
 El cliente puede comprobar la identidad del principal tras el
servidor para asegurar que el resultado proviene del servidor
requerido.
Derechos
de acceso
Objeto
Invocación
Cliente
Servidor
Resultado
Principal (cliente)
Red Principal
(servidor)
Figura 17. Objetos y principales
Asegurar procesos y sus interacciones

 Cierto tipo de aplicaciones son más propensas a los ataques.
 Para este tipo de aplicaciones probablemente habrá ataques a los
procesos de los que se componen tales aplicaciones y a los
mensajes que viajan entre los procesos.
 Cómo podemos analizar estas amenazas para derrotarlas?.
Modelo de amenazas de seguridad El enemigo: es capaz de
enviar cualquier mensaje a cualquier proceso y también de leer o
copiar cualquier mensaje entre un par de procesos. El ataque
puede venir de un computador legítimamente conectado o de una
máquina no autorizada.
Copia de m
El enemigo
m`
Proceso P m ^ Proceso Q
Canal de comunicación
Figura 18. El enemigo
36
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.
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.
37
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.
38
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 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?
39
COMUNICACION A NIVEL
DE REDES
Los sistemas distribuidos utlizan redes de area local, redes de area extendido e
interredes para comunicarse. Las prestaciones, fiabilidad, escalabilidad,
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.
 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
 Realizar el proceso de encapsulamiento de datos y direccionamiento de
puertos
40
CONCEPTOS GENERALES DE LA COMUNICACIÓN POR
COMPUTADORAS.
1. ELEMENTOS DELA COMUNICACIÓN
Para que exista comunicación deben existir los siguientes elementos:
 Origen del mensaje
 Canal de transmisión
 Destino del mensaje
La comunicación comienza con un mensaje o información que se debe
enviar desde una persona o dispositivo a otro. Las personas intercambian
ideas mediante diversos métodos de comunicación. Todos estos métodos
tienen tres elementos en común. El primero de estos elementos es el origen
del mensaje o emisor. Los orígenes de los mensajes son las personas o los
dispositivos electrónicos que deben enviar un mensaje a otras personas o
dispositivos. El segundo elemento de la comunicación es el destino o
receptor del mensaje. El destino recibe el mensaje y lo interpreta. Un tercer
elemento, llamado canal, está formado por los medios que proporcionan el
camino por el que el mensaje viaja desde el origen hasta el destino.
ELEMENTOS DE LA COMUNICACION
Figura 1. Elementos de la Comunicación
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
41
transmitieron de esta manera, significará que ningún otro dispositivo podrá
enviar o recibir mensajes en la misma red mientras esta transferencia de
datos está en progreso. Estos grandes streams de datos originarán retrasos
importantes. Además, si falló un enlace en la infraestructura de red
interconectada durante la transmisión, se perderá todo el mensaje y tendrá
que retransmitirse por completo.
Un mejor enfoque para enviar datos a través de la red es dividir los datos
en partes más pequeñas y más manejables. La división del stream de datos
en partes más pequeñas se denomina segmentación. La segmentación de
mensajes tiene dos beneficios principales.
Primero: al enviar partes individuales más pequeñas del origen al destino,
se pueden entrelazar diversas conversaciones en la red. El proceso que se
utiliza para entrelazar las piezas de conversaciones separadas en la red se
denomina multiplexación.
Segundo: la segmentación puede aumentar la confiabilidad de las
comunicaciones de red. No es necesario que las partes separadas de cada
mensaje sigan el mismo recorrido a través de la red desde el origen hasta el
destino. Si una ruta en particular se satura con el tráfico de datos o falla, las
partes individuales del mensaje aún pueden direccionarse hacia el destino
mediante los recorridos alternativos. Si parte del mensaje no logra llegar al
destino, sólo se deben retransmitir las partes faltantes.
SEGMENTACION DE PAQUETES
Figura 2. Segmentacion de Paquetes
42
2. ELEMENTOS DE UNA RED
Los dispositivos y los medios son los elementos físicos o hardware de la
red.
2.1 Dispositivos de una Red
Varios tipos de dispositivos en toda la red participan para asegurar que
las partes del mensaje lleguen a los destinos de manera confiable.
 Dispositivos Finales (host)
 Dispositivos Intermedios
2.1.1 Dispositivos Finales (host)
En el contexto de una red, los dispositivos finales se denominan
host. Un dispositivo host puede ser el origen o el destino de un
mensaje transmitido a través de la red. Para distinguir un host de
otro, cada host en la red se identifica por una dirección. Cuando
un host inicia una comunicación, utiliza la dirección del host de
destino para especificar dónde debe ser enviado el mensaje.
Ejemplos:
 Computadoras (estaciones de trabajo, computadoras portátiles,
servidores de archivos, servidores Web)
 Impresoras de red
 Teléfonos VoIP
 Cámaras de seguridad
 Dispositivos móviles de mano (como escáneres de barras
inalámbricos, asistentes digitales personales (PDA))
En las redes modernas, un host puede funcionar como un cliente,
como un servidor o como ambos. El software instalado en el host
determina qué rol representa en la red. Los servidores son hosts
que tienen software instalado que les permite proporcionar
información y servicios, como e-mail o páginas Web, a otros hosts
en la red, Los clientes son hosts que tienen software instalado que
les permite solicitar y mostrar la información obtenida del
servidor.
43
2.1.2 Dispositivos Intermedios
Las redes dependen de dispositivos intermediarios para proporcionar
conectividad y para trabajar detrás de escena y garantizar que los datos
fluyan a través de la red. Estos dispositivos conectan los hosts
individuales a la red y pueden conectar varias redes individuales para
formar una internetwork. Los siguientes son ejemplos de dispositivos de
red intermediarios:
 Dispositivos de acceso a la red (hubs, switches y puntos de
acceso inalámbricos),
 Dispositivos de internetworking (routers),
 Servidores de comunicación y módems.
 Dispositivos de seguridad (firewalls), etc.
La administración de datos mientras fluyen a través de la red
también es una función de los dispositivos intermediarios. Estos
dispositivos utilizan la dirección host de destino, conjuntamente
con información sobre las interconexiones de la red, para
determinar la ruta que deben tomar los mensajes a través de la
red. Los procesos que se ejecutan en los dispositivos de red
intermediarios realizan las siguientes funciones:
 Regenerar y retransmitr señales de datos
 Mantener información sobre qué rutas existen a través de la
red y de la internetwork.
 Notificar a otros dispositivos los errores y las fallas de
comunicación,
 direccionar datos por rutas alternativas cuando existen fallas
en un enlace.
 Clasificar y direccionar mensajes según las prioridades de QoS
(calidad de servicio).
 Permitir o denegar el flujo de datos en base a configuraciones
de seguridad.
44
2.2 Medios de una Red
La comunicación a través de una red es transportada por un medio. El
medio proporciona el canal por el cual viaja el mensaje desde el origen
hasta el destino.
Las redes modernas utilizan principalmente tres tipos de medios para
interconectar los dispositivos y proporcionar la ruta por la cual pueden
transmitirse los datos. Estos medios son:
 Hilos metálicos dentro de los cables,
 Fibras de vidrio o plásticas (cable de fibra óptica), y
 Transmisión inalámbrica.
La codificación de señal que se debe realizar para que el mensaje sea
transmitido es diferente para cada tipo de medio. En los hilos metálicos,
los datos se codifican dentro de impulsos eléctricos que coinciden con
patrones específicos. Las transmisiones por fibra óptica dependen de
pulsos de luz, dentro de intervalos de luz visible o infrarroja. En las
transmisiones inalámbricas, los patrones de ondas electromagnéticas
muestran los distintos valores de bits.
Los diferentes tipos de medios de red tienen diferentes características y
beneficios. No todos los medios de red tienen las mismas características
ni son adecuados para el mismo fin.
Figura 3. Elementos de una Red
45
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 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.
46
Figura 4. Modelos de Red
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.
Figura 5. Modelo TCP/IP
47
El modelo TCP/IP describe la funcionalidad de los protocolos que
forman la suite de protocolos TCP/IP. Esos protocolos, que se
implementan tanto en el host emisor como en el receptor, interactúan
para proporcionar la entrega de aplicaciones de extremo a extremo a
través de una red.
Un proceso completo de comunicación incluye estos pasos:
o Creación de datos a nivel de la capa de aplicación del dispositivo
final origen.
o Segmentación y encapsulación de datos cuando pasan por la stack
de protocolos en el dispositivo final de origen.
o Generación de los datos sobre el medio en la capa de acceso a la red
de la stack.
o Transporte de los datos a través de la internetwork, que consiste de
los medios y de cualquier dispositivo intermediario.
o Recepción de los datos en la capa de acceso a la red del dispositivo
final de destino.
o Desencapsulación y rearmado de los datos cuando pasan por la
stack en el dispositivo final.
o Traspaso de estos datos a la aplicación de destino en la capa de
aplicación del dispositivo final de destino
Figura 6. Transporte de un paquete
48
Encapsulamiento de Datos
Mientras los datos de la aplicación bajan al stack del protocolo y se
transmiten por los medios de la red, varios protocolos le agregan
información en cada nivel. Esto comúnmente se conoce como proceso
de encapsulación.
PROCESOS DE ENCAPSULAMIENTO DE DATOS
Figura 7. Encapsulamiento de Datos
La forma que adopta una sección de datos en cualquier capa se

denomina Unidad de datos del protocolo (PDU). Durante la
encapsulación, cada capa encapsula las PDU que recibe de la capa
superior de acuerdo con el protocolo que se utiliza. En cada etapa del
proceso, una PDU tiene un nombre distinto para reflejar su nuevo
aspecto. Aunque no existe una convención universal de nombres para
las PDU, en este curso se denominan de acuerdo con los protocolos de
la suite TCP/IP.
 Datos: el término general para las PDU que se utilizan en la capa de
aplicación.
 Segmento: PDU de la capa de transporte.
 Paquete: PDU de la capa de Internetwork.
 Trama: PDU de la capa de acceso a la red.
49
 Bits: una PDU que se utiliza cuando se transmiten físicamente datos
a través de un medio.
Figura 8. Direccionamiento de PDU
Cuando se envían mensajes en una red, el stack del protocolo de un

host funciona desde arriba hacia abajo. En el ejemplo del servidor Web
podemos utilizar el modelo TCP/IP para ilustrar el proceso de envío de
una página Web HTML a un cliente.
El protocolo de la capa Aplicación, HTTP, comienza el proceso
entregando los datos de la página Web con formato HTML a la capa
Transporte. Allí, los datos de aplicación se dividen en segmentos TCP.
A cada segmento TCP se le otorga una etiqueta, denominada
encabezado, que contiene información sobre qué procesos que se
ejecutan en la computadora de destino deben recibir el mensaje.
También contiene la información para habilitar el proceso de destino
para reensamblar nuevamente los datos a su formato original.
La capa Transporte encapsula los datos HTML de la página Web dentro
del segmento y los envía a la capa Internet, donde se implementa el
protocolo IP. Aquí, el segmento TCP en su totalidad es encapsulado
dentro de un paquete IP, que agrega otro rótulo denominado
encabezado IP. El encabezado IP contiene las direcciones IP de host de
50
origen y de destino, como también la información necesaria para
entregar el paquete a su correspondiente proceso de destino.
Luego el paquete IP se envía al protocolo Ethernet de la capa de acceso
a la red, donde se encapsula en un encabezado de trama y en un tráiler.
Cada encabezado de trama contiene una dirección física de origen y de
destino. La dirección física identifica de forma exclusiva los dispositivos
en la red local. El tráiler contiene información de verificación de errores.
Finalmente, los bits se codifican en el medio Ethernet mediante el
servidor NIC.
Figura 9. Operación de protocolo de envio y recepcion de mensajes
3.2 Modelo OSI

Inicialmente, el modelo OSI fue diseñado por la Organización
Internacional para la Estandarización (ISO, International Organization
for Standardization) para proporcionar un marco sobre el cual crear
una suite de protocolos de sistemas abiertos. La visión era que este
conjunto de protocolos se utilizara para desarrollar una red
internacional que no dependiera de sistemas propietarios.
Lamentablemente, la velocidad a la que fue adoptada la Internet basada
en TCP/IP y la proporción en la que se expandió ocasionaron que el
desarrollo y la aceptación de la suite de protocolos OSI quedaran atrás.
Aunque pocos de los protocolos desarrollados mediante las
51
especificaciones OSI son de uso masivo en la actualidad, el modelo OSI
de siete capas ha realizado aportes importantes para el desarrollo de
otros protocolos y productos para todos los tipos de nuevas redes.
Figura 10. Comunicación capa a capa
El modelo OSI describe los procesos de codificación, formateo,

segmentación y encapsulación de datos para transmitir por la red. Un
flujo de datos que se envía desde un origen hasta un destino se puede
dividir en partes y entrelazar con los mensajes que viajan desde otros
hosts hacia otros destinos. Miles de millones de estas partes de
información viajan por una red en cualquier momento. Es muy
importante que cada parte de los datos contenga suficiente información
de identificación para llegar al destino correcto.
Existen varios tipos de direcciones que deben incluirse para entregar
satisfactoriamente los datos desde una aplicación de origen que se
ejecuta en un host hasta la aplicación de destino correcta que se ejecuta
en otro.
Figura 11. Direccionamiento por capas

52
Durante el proceso de encapsulación, se agregan identificadores de
dirección a los datos mientras bajan al stack del protocolo en el host de
origen. Así como existen múltiples capas de protocolos que preparan
los datos para transmitirlos a sus destinos, existen múltiples capas de
direccionamiento para asegurar la entrega.
El primer identificador, la dirección física del host, aparece en el
encabezado de la PDU de Capa 2, llamado trama. La Capa 2 está
relacionada con la entrega de los mensajes en una red local única. La
dirección de la Capa 2 es exclusiva en la red local y representa la
dirección del dispositivo final en el medio físico. En una LAN que
utiliza Ethernet, esta dirección se denomina dirección de Control de
Acceso al medio (MAC). Cuando dos dispositivos se comunican en la
red Ethernet local, las tramas que se intercambian entre ellos contienen
las direcciones MAC de origen y de destino. Una vez que una trama se
recibe satisfactoriamente por el host de destino, la información de la
dirección de la Capa 2 se elimina mientras los datos se desencapsulan y
suben el stack de protocolos a la Capa 3.
Los protocolos de Capa 3 están diseñados principalmente para mover
datos desde una red local a otra red local dentro de una internetwork.
Mientras las direcciones de Capa 2 sólo se utilizan para comunicar entre
dispositivos de una red local única, las direcciones de Capa 3 deben
incluir identificadores que permitan a dispositivos de red
intermediarios ubicar hosts en diferentes redes. En la suite de
protocolos TCP/IP, cada dirección IP host contiene información sobre
la red en la que está ubicado el host.
En los límites de cada red local, un dispositivo de red intermediario,
por lo general un router, desencapsula la trama para leer la dirección
host de destino contenida en el encabezado del paquete, la PDU de
Capa 3. Los routers utilizan la porción del identificador de red de esta
dirección para determinar qué ruta utilizar para llegar al host de
destino. Una vez que se determina la ruta, el router encapsula el
53
paquete en una nueva trama y lo envía por su trayecto hacia el
dispositivo final de destino. Cuando la trama llega a su destino final, la
trama y los encabezados del paquete se eliminan y los datos se suben a
la Capa 4.
Figura 12. Direccionamiento en la capa 3
En la Capa 4, la información contenida en el encabezado de la PDU no

identifica un host de destino o una red de destino. Lo que sí identifica
es el proceso o servicio específico que se ejecuta en el dispositivo host
de destino que actuará en los datos que se entregan. Los hosts, sean
clientes o servidores en Internet, pueden ejecutar múltiples aplicaciones
de red simultáneamente. La gente que utiliza computadoras personales
generalmente tiene un cliente de correo electrónico que se ejecuta al
mismo tiempo que el explorador Web, un programa de mensajería
instantánea, algún streaming media y, tal vez, incluso algún juego.
Todos estos programas ejecutándose en forma separada son ejemplos
de procesos individuales.
Ver una página Web invoca al menos un proceso de red. Hacer clic en
un hipervínculo hace que un explorador Web se comunique con un
servidor Web. Al mismo tiempo, en segundo plano, es posible que
cliente de correo electrónico esté enviando o recibiendo un e-mail y un
colega o amigo enviando un mensaje instantáneo.
54
Piense en una computadora que tiene sólo una interfaz de red. Todos
los streams de datos creados por las aplicaciones que se están
ejecutando en la PC ingresan y salen a través de esa sola interfaz, sin
embargo los mensajes instantáneos no emergen en el medio del
documento del procesador de textos o del e-mail que se ve en un juego.
Esto es así porque los procesos individuales que se ejecutan en los hosts
de origen y de destino se comunican entre sí. Cada aplicación o servicio
es representado por un número de puerto en la Capa 4. Un diálogo
único entre dispositivos se identifica con un par de números de puerto
de origen y de destino de Capa 4 que son representativos de las dos
aplicaciones de comunicación. Cuando los datos se reciben en el host, se
examina el número de puerto para determinar qué aplicación o proceso
es el destino correcto de los datos
Figura 13. Direccionamiento en la capa 4
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 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,
55
 segmentación de datos y gestión de cada porción,
 reensamble de segmentos en flujos de datos de aplicación, e
 identificación de las diferentes aplicaciones.
4.1 Responsabilidades de la capa de Red

4.1.1 Seguimiento de Conversaciones individuales:
Cualquier host puede tener múltiples aplicaciones que se están
comunicando a través de la red. Cada una de estas aplicaciones se
comunicará con una o más aplicaciones en hosts remotos. Es
responsabilidad de la capa de Transporte mantener los diversos
streams de comunicación entre estas aplicaciones.
4.1.2 Segmentación de datos:
Debido a que cada aplicación genera un stream de datos para
enviar a una aplicación remota, estos datos deben prepararse para
ser enviados por los medios en partes manejables. Los protocolos
de la capa de Transporte describen los servicios que segmentan
estos datos de la capa de Aplicación. Esto incluye la encapsulación
necesaria en cada sección de datos. Cada sección de datos de
aplicación requiere que se agreguen encabezados en la capa de
Transporte para indicar la comunicación a la cual está asociada.
4.1.3 Reensamble de segmentos:
En el host de recepción, cada sección de datos puede ser
direccionada a la aplicación adecuada. Además, estas secciones de
datos individuales también deben reconstruirse para generar un
stream completo de datos que sea útil para la capa de Aplicación.
Los protocolos de la capa de Transporte describen cómo se utiliza
la información de encabezado de dicha capa para reensamblar las
secciones de datos en streams y enviarlas a la capa de Aplicación.
4.1.4 Identificación de las aplicaciones:
Para poder transferir los streams de datos a las aplicaciones
adecuadas, la capa de Transporte debe identificar la aplicación de
56
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.
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
57
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.
Figura 14. Habilitacion de los dispositivos para la comunicacion
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.
58
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 bytes de carga. Ver
la figura para obtener una comparación.
Las aplicaciones que utilizan TCP son: exploradores Web, e-mail,
y transferencia de archivos
Figura 15. Encabezado TCP y UDP
59
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 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.
60
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 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
61
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.
Figura 16. Direccionamiento de puertos
Si los datos de aplicación necesitan ser entregados a la red de manera

rápida o si el ancho de banda de la red no admite la sobrecarga de
mensajes de control que se intercambian entre los sistemas de origen y
destino, UDP será el protocolo de la capa de Transporte preferido por el
desarrollador. Esto es así porque UDP no rastrea ni reconoce la
recepción de datagramas en el destino, sólo envía los datagramas
recibidos a la capa de Aplicación a medida que llegan, y no reenvía
datagramas perdidos. Sin embargo, esto no significa necesariamente
que la comunicación no es confiable; puede haber mecanismos en los
protocolos y servicios de la capa de Aplicación que procesan
datagramas perdidos o demorados si la aplicación cuenta con esos
requerimientos.
El desarrollador de la aplicación toma una decisión en cuanto al
protocolo de la capa de Transporte en base a los requerimientos del
usuario. Sin embargo, el desarrollador tiene en cuenta que las otras
62
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).
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
63
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 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.
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)
64
o Internet es demasiado grande para que cualquier Router pueda
almacenar la información de encaminamiento para todos los
nodos. ¿Cómo resuelve el esquema de encaminamiento de
Internet este problema?
o ¿Cuál es el cometido de un conmutador Ethernet? ¿Qué tablas de
direcciones contiene?
o ¿Que tipos de enrutamiento existe y cual es el fin de cada uno?
o Describa el modo en que deberia configurar un cortafuegos para
proteger la red local de su institucio o empresa ¿Qué solicitudes
entrantes y salientes debería interceptar?
o ¿Explique el proceso de encapsulamiento?
o Explique el direccionamiento de puertos en las siguientes
aplicaciones de la fig. 17
Figura 17. Aplicaciones de internet
65
COMUNICACION ENTRE
PROCESOS EN SISTEMAS
DISTRIBUIDOS
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.
 Definir, describir que es la comunicación entre procesos en sistemas
distribuidos.
 Definir, describir la comunicación por paso de mensajes
 Definir y describir el llamado a un procediemiento remoto (RPC)
 Definir y describir la comunicación Cliente – Servidor.
 Definir y describir la comunicación en grupo.
Aplicaciones, servicios.
}
RMI y RPC
Capas
Este
capítulo
{ Protocolo petición respuesta
Empaquetado y representación externa de datos
Middleware
UDP y TCP
Figura 1. Capas Middleware
66
¿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.
La comunicación entre procesos en S.D. necesita compartir información:
Figura 2. Proceso de compartir informacion
La comunicación entre procesos en un ambiente distribuido no puede hacerse

por memoria compartida; la única posibilidad es por intercambio de mensajes.
1 COMUNICACION POR PASO DE MENSAJE

La comunicación por paso de mensajes entre dos proceso se puede basar en
dos operaciones envía y recibe, definidas en función del destino y del
mensaje. Para que un proceso se comunique con otro, el proceso envía un
mensaje (secuencia de bytes) a un destino y otro proceso en el destino
recibe el mensaje, esta actividad implica la comunicación de datos desde el
proceso emisor hasta el proceso receptor, puede implicar además la
sincronización de los dos procesos.
Características deseables de un buen sistema de paso de mensajes
1.1 Simplicidad
• Simple y fácil de usar (uso directo)
• Hacer sin preocuparse de aspectos de la red/sistema
67
1.2 Semántica uniforme en:
• Comunicaciones locales
• Comunicaciones remotas
1.3 Eficiencia
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
68
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)
Heterogeneidad de máquinas compatibilización de representación.
2 ESTRUCTURA TIPICA DE MENSAJES

El enviador determina el contenido del mensaje.
El receptor tiene en cuenta como interpretar los datos
Estructura típica de mensaje
Figura 3. Estructura tipica de un mensaje
3 RENDIMIENTO DE UN SISTEMA DISTRIBUIDO

El rendimiento de un sistema de computación distribuida depende en
gran medida de la comunicación rápida entre procesos.
Para que la comunicación entre procesos sea rapida depende de dos partes:
 Las primitivas de comunicación entre procesos
 El protocolo de transporte sobre el cual trabajan esas primitivas.
3.1 PRIMITIVAS DE COMUNICACIÓN
El paso de mensajes entre un par de procesos se puede basar en dos
operaciones primitivas, envía y recibe definidas en función del destino
y del mensaje. Para que un proceso se pueda comunicar con otro, el
proceso envía un mensaje (una secuencia de bytes) a un destino y otro
proceso en el destino recibe el mensaje.
69
3.1.1. Primitivas con bloqueo o sin bloqueo
Una primitiva tiene una semántica sin bloqueo cuando su
ejecución no produce un retardo en el proceso que la invoca; de
otra manera la primitiva es con bloqueo.
Existen básicamente cuatro tipos de comunicación para este tipo
de primitivas:
 Send con bloqueo (CPU inactivo durante la transmisión de los
mensajes)
 Send sin bloqueo, sin copia (no se puede sobrescribir hasta
que el mensaje haya sido leído)
 Send sin bloqueo, con copia (se desperdicia el tiempo del CPU
para la copia adicional)
 Send sin bloqueo, con interrupción (dificulta la programación).
Figura 4. Mensajes Bloqueantes Vs. No bloqueantes
3.1.2 Primitivas almacenadas con buffer y no almacenadas.

Cuando se efectúa un intercambio de mensajes se presentan dos
casos en relación a donde se va a almacenar la información. En el
primero de estos es el proceso servidor es el que destina una área
para recibir un mensaje al efectuar la operación receive (no
almacenado); mientras que en el segundo el proceso servidor
solicita la creación de un buzón para alojar los mensajes que van a
ser recibidos mientras los puede procesar (almacenamiento con
buffers).
70
En sistemas sin buffer, la ejecución de un send se detiene hasta
que en el otro extremo se ejecuta un receive (si se utilizó
bloqueo). En ese momento el mensaje es enviado y ambos
procesos pueden continuar su ejecución. Ambos procesos se
sincronizan o se encuentran cuando el mensaje es transferido. Los
sistemas con buffer son más difíciles de controlar debido a la
necesidad de crear, destruir y mantener los buffers.
Figura 5. Transferencia de mensajes
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 cliente es reconocida por el
71
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 ?
 Si hay varios mensajes esperando en el receptor, ¿puede éste cambiar
el orden?
72
4 NIVEL DE ABSTRACCIÓN EN COMUNICACIÓN CON PASO DE
MENSAJES:
Diferentes conjuntos de primitivas pueden ser usados en la comunicación
entre procesos remotos. Los tres más comunes están basados en:
• Paso de mensajes puro.
• Llamado a procedimientos remotos
• Transacciones.
El orden en la lista anterior indica que cada forma de comunicación puede
ser construida en base a la anterior. En otras palabras, a mayor número,
mayor nivel de abstracción.
4.1 PASO DE MENSAJES PURO
Un mensaje es una colección de datos de cierto tipo consistente
en un encabezado y un cuerpo de longitudes fijas o variables, la
cual puede ser manejada por un proceso y entregada a su destinatario.
La comunicación orientada a mensajes está íntimamente ligada al
modelo cliente-servidor. El proceso cliente envía un mensaje
(petición) a un proceso servidor y espera una respuesta o continúa
ejecutándose. Las primitivas de comunicación por paso de mensajes son
send y receive. En algunos sistemas, la primitiva receive puede ser
selectiva o condicional si se agrega un guardia al llamar a la primitiva.
Existen diversas formas o interpretaciones semánticas de las primitivas:
4.1.1 Direccionamiento:
Para que un cliente pueda enviar un mensaje a un servidor, debe
conocer la dirección de éste. Existen varios métodos por los
que un cliente puede conocer o determinar la dirección del
servidor, a continuación se mencionan tres de ellas:
4.1.1.1 Asignación numérica fija predeterminada
en este caso la dirección del servidor es acordada en forma
anterior o durante el desarrollo de las aplicaciones cliente-
servidor, y por ello se puede incluir en el programa
ejecutable (ejemplo en un archivo de encabezados
73
header.h). Aunque esta estrategia podría funcionar en un
sistema particularmente sencillo, es necesaria una forma
más sofisticada de direccionamiento. Aquí cabe señalar que
no se ha determinado que es lo que significa el número
asignado, es decir, no especifica si es la identificación de un
proceso o de un equipo.
Figura 6. Asignacion fija predeterminada
4.1.1.2 Asignación aleatoria de número de proceso

Este método consiste en dejar que cada proceso elija su
propio identificador de un espacio de direcciones
grande y disperso, como el espacio de enteros de 64 bits. La
probabilidad de que dos procesos elijan el mismo número
es muy pequeña. Este método puede utilizarse en sistemas
grandes. Sin embargo existe el problema de saber ¿a que
máquina enviar el mensaje?. Para ello el emisor podría
enviar un paquete especial de localización con la dirección
del proceso destino. Puesto que es un paquete de
transmisión, será recibido por todas las máquinas de la red.
Todos los núcleos verifican si la dirección es la suya y, en
caso de que lo sea, regresa el mensaje de aquí estoy con su
dirección en la red (número de máquina).
74
Figura 7. Asignacion Aleatoria de numero de proceso
4.1.1.3 Servidor de nombres

Aun asi el esquema anterior es transparente, la transmisión
provoca carga adicional en el sistema. Esta carga se puede
evitar mediante una máquina adicional para la asociación
a alto nivel (es decir en ASCII) de los nombres de
servicios con las direcciones de las máquinas. Al utilizar
este sistema, se hace referencia a los procesos del tipo de los
servidores mediante cadenas en ASCII, las cuales son las
que introducen en los programas y no los números en
binario de las máquinas o procesos. Cada vez que se
ejecute un cliente, en su primer intento por utilizar el
servidor, el cliente envía una solicitud de cuestionamiento
a un servidor especial de asociaciones, el cual se conoce
como servidor de nombres para pedirle el número de
máquina donde se localiza en ese momento el servidor.
Figura 7. Servidor de nombres
75
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 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.
76
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
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.
77
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
Figura 9. Comunicación Sincrona Vs. Comunicación Asincrona
 Envío no bloqueante (comunicación asíncrona): [1:8] El emisor

continúa al pasar el mensaje al núcleo.
 Envío bloqueante no fiable (comunicación asíncrona): [1:2:7:8] El
emisor espera a que el núcleo transmita por red el mensaje.
 Envío bloqueante fiable (comunicación asíncrona): [1:2:3:6:7:8]: El
emisor espera a que el núcleo receptor recoge el mensaje.
 Envío bloqueante explícito (comunicación síncrona): [1:2:3:4:5:6:7:8]:
Idem al anterior, pero es la aplicación receptora la que confirma la
recepción.
78
 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 recepción.
• Existen buffers para los mensajes.
• Envio => Colocar mensajes en buffer.
• Recepción => Sacar mensajes en buffer.
• Sincronia => bloqueo
• Asincronía => no hay bloqueo en el envió.
• Uso de threads (hilos).
Entonces tenemos dos formas de comunicación de procesos, enviando
paquetes a través de los protocolos UDP y TCP, ambas utilizan la
abstracción de sockets (conectores) para la comunicación, estas se encargan
de proporcionar los puntos extremos de la comunicación entre procesos.
7 COMUNICACIÓN EN CLIENTE – SERVIDOR

Esta forma de comunicación esta orientada a soportar los roles y el
intercambio de las interacciones típicas cliente-servidor. En el caso normal,
79
la comunicación petición - respuesta es síncrona, ya que el proceso cliente se
bloquea hasta que llega la respuesta del servidor. Esta comunicación
también puede ser fiable debido a que la respuesta del servidor es en efecto
un acuse de recibo para el cliente.
Dos roles diferentes en la interacción
 Cliente: Solicita servicio. Petición: Operación + Datos
 Servidor: Proporciona servicio. Respuesta: Resultado
Figura 10. Comunicación peticion respuesta cliente - servidor
Modelo con proxy o cache.

Tres roles diferentes en la interacción
 Cliente: Solicita servicio.
 Servidor: Proporciona servicio.
 Proxy: Intermediario (si tiene memoria se denomina caché)
Figura 11. Comunicación peticion respuesta con proxy
Modelo Multicapa
Servidor puede ser cliente de otro servidor, Típico en aplicaciones web:
 Presentación + Lógica de negocio + Acceso a datos
 En Microsoft: ASP + COM + ADO
 En Java: JSP + EJB + JDBC
80
Figura 12. Comunicación peticion respuesta Servidor - Servidor
Los modelos de comunicación basados en cliente-servidor con paso de

mensajes responden al esqueleto:
Figura 13. Esqueleto de la comunicación cliente – Servidor con paso de mensajes
8 COMUNICACIÓN EN GRUPO
El intercambio de mensajes entre iguales no es mejor modelo para la
comunicación entre un proceso y un grupo de procesos, como por ejemplo
se da en el caso de un servicio implementado por varios procesos en
diferentes computadores, quizás para proporcionar tolerancia a fallos o
mejorar la disponibilidad. Resulta mas apropiada una operacion
multidifusión, esta es una operación que envía un único mensaje desde un
proceso a cada uno de los miembros de un grupo de procesos, normalmente
de modo que la pertenencia al grupo resulte transparente para el emisor. La
comunicación en grupo Provee confiabilidad, disponibilidad de servicios
desde la perspectiva de replicación, la operación más apropiada para
81
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.
 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”.
82
 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 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.
83
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.
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/
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
84
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.
85
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.
 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 de protocolos TCP/IP,
86
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.
Figura 1. Sockets y Puertos
1.2 Operaciones sobre Sockets

El principal objetivo de la interfaz de sockets es facilitar al
programador el desarrollo de aplicaciones distribuidas. Casi todos
los programadores están familiarizados con el manejo de archivos por
medio de las operaciones básicas open-read-write-close. La interfaz de
sockets intenta que la programación en ambientes distribuidos se
realice con las mismas operaciones, sólo que en lugar de actuar sobre
un archivo actúan sobre un punto terminal de un canal de
87
comunicaciones (socket). De esta manera tenemos las siguientes
analogías:
Figura 2. Tabla de operaciones en archivos Vs Operaciones en Sockets
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:
 struct sockaddr mi_dir;
 Cada dominio usa una estructura específica.
88
 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).
Figura 3. Proceso de transmision de datos con Streams

89
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).
Figura 3. Proceso de transmision de datos con datagramas.
2 PROTOCOLO DE INTERFAZ DE APLICACION (API) DE JAVA PARA

LAS DIRECCIONES DE INTERNET
Como los paquetes IP que subyacen a TCP y UDP se envían en direcciones
internet, java proporciona una clase InetAddres, para representar las
direcciones internet. Los usuarios de esta clase se refieren a los
computadores por sus nombres de host en el servicio de nombres de
dominio.
2.1. Comunicación de datagramas UDP
Un datagrama enviado por UDP se transmite desde un proceso emisor
a un proceso receptor sin acuse de recibo ni reintentos. Si algo falla, el
mensaje puede no llegar a su destino. Se transmite un datagrama entre
proceso cuando uno lo envía y el otro lo recibe, cualquier proceso que
90
necesite enviar o recibir mensajes debe crear primero un conector
asociado a una dirección de internet y a un puerto local. Un servidor
enlazara su conector a un puerto de de servidor (uno que resulte
conocido a los clientes de forma que puedan enviarle mensajes). Un
cliente ligara su conector a cualquier puerto local libre. El método recibe
devolverá, además del mensaje, la dirección de internet y el puerto del
emisor, permitiendo al receptor enviar la correspondiente respuesta.
API java para datagramas UDP.
La API java proporciona una comunicación de datagramas por medio
de dos clases: Datagrama Packet y DatagramaSocket.
 Datagrama Packet:
Esta clase proporciona un constructor que crea una instancia
compuesta por una cadena de bytes que almacena el mensaje, la
longitud del mensaje y la dirección internet y el número de puerto
local del conector destino.
Cadena de bytes conteniendo el Longitud del Dirección de Numero de
mensaje mensaje. internet puerto
Figura 3. Paquete del datagrama
Las instancias de DatagramaPacket podrán ser transmitidas entre

procesos cuando uno la envía y el otro la recibe.
 DatagramaSocket:
Esta clase maneja conectores para enviar y recibir datagramas UDP.
Proporciona un constructor que toma un numero de puerto como
argumento, apropiado para los procesos que necesitan utilizar un
puerto concreto. También proporciona un constructor sin
argumentos que permite que el sistema elija un puerto de entre los
libres. Estos constructores pueden lanzar una excepción
SocketException si el puerto ya esta siendo usado o si se especifica
un puerto reservado.
 Código java de un cliente UDP enviando un mensaje a un
servidor y recogiendo su respuesta:
91
El código muestra un programa de un cliente que crea un
conector, envía un mensaje a un servidor en el puerto 6789, y
después espera una respuesta. Los argumentos para el método
main proporcionan un mensaje y el nombre del DNS de host
del servidor. El mensaje se convierte en una cadena de bytes y
el nombre DNS del host a la correspondiente dirección de
internet.
import java.net.*;
import java.io.*;
public class UDPClient{
public static void main(String args[]){
// args give message contents and server hostname
DatagramSocket aSocket = null;
try {
aSocket = new DatagramSocket();
byte [] m = args[0].getBytes();
InetAddress aHost = InetAddress.getByName(args[1]);
int serverPort = 6789;
DatagramPacket request = new DatagramPacket(m,
args[0].length(), aHost, serverPort);
aSocket.send(request);
byte[] buffer = new byte[1000];
DatagramPacket reply = new DatagramPacket(buffer,
buffer.length);
aSocket.receive(reply);
System.out.println("Reply: " + new
String(reply.getData()));
}catch (SocketException e){System.out.println("Socket: " +
e.getMessage());
}catch (IOException e){System.out.println("IO: " +
e.getMessage());}
}finally {if(aSocket != null) aSocket.close();}
92
}
}
 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());}
93
}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 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
94
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 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.
95
Puede lanzar una excepción UnknowException si el nombre de host no
es correcto, o una exception IOEexception si se da un error de entrada y
salida.
La clase socket proporciona los métodos getinputstream y
getoutputstream para accesder a los streams asociados con un conector.
 Un cliente TCP realiza una conexión a un servidor, envía una
petición y recibe una respuesta
El código muestra un programa cliente donde se le da como
argumento al método main un mensaje y nombre DNS del host
servidor. El cliente crea un conector ligado al nombre del host y al
puerto 7896. Obtiene DataInputStream y DataOuputStream delos
streams de los conectores de entrada y salida respectivamente, y
entonces escribe el mensaje en su stream de salida y espera a leer la
respuesta en el stream de entrada.
import java.net.*;
import java.io.*;
public class TCPClient {
public static void main (String args[]) {
// arguments supply message and hostname of destination
Socket s = null;
try{
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());
96
}catch (IOException
e){System.out.println("IO:"+e.getMessage());}
}finally {if(s!=null) try {s.close();}catch (IOExceptione) {System.out.println
("close:"+e.getMessage());}}
}
}
 Un Servidor TCP establece una conexión para cada cliente y les

reenvía peticiones.
El código muestra un programa servidor que en realiza la siguiente
acción, abre un conecctor de servidor en su puerto de servicio 7896
y escucha las peticiones de conexión, connect, cuando llega una
conexión crea un nuevo hilo para comunicarse con el cliente. El
nuevo hilo crea un DataInputStream y un DtaOuputStream para los
flujos de esntrada y salida de su conector y entonces a leer el
mensaje del cliente y lo escribe de vuelta.
import java.net.*;
import java.io.*;
public class TCPServer {
public static void main (String args[]) {
try{
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;
97
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());
} 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.
98
 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 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
99
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 í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.
100
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.
101
OBJETOS DISTRIBUIDOS E
INVOCACION REMOTA
Los modelos de programación para aplicaciones distribuidas son aquellas que
se componen de programas cooperantes corriendo en los procesos distintos,
tales programas necesitan ser capaces de invocar operaciones entre otros
procesos, que por lo general residen en otros computadores diferentes. Para
lograr esto algunos modelos de programación familiares han sido extendidos
para aplicarlos a los programas distribidos.
 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.
102
 El modelo de programación basado en eventos permite a los objetos recibir
notificaciones de los eventos que ocurren en otros objetos en los que se ha
mantenido el interés. Este modelo ha sido extendido para permitir escribir
programas distribuidos basados en eventos.
Notese que usamos el termino RMI para referirnos a una invocación de un
método remoto de forma genérica. No debemos confundir con ejemplos
particulares de invocación de un método remoto como Java RMI.
Idea Central: “¿Cómo hacer para que objetos remotos se comuniquen entre sí?”
COMUNICACION DE OBJETOS REMOTOS
Figura 1. Comunicación de Objetos remotos
1. MIDDLEWARE
Al software que proporciona un modelo de programación sobre bloques
básicos arquitectónicos, a saber procesos y paso de mensajes se le llama
middleware. La capa midlleware emplea protocolos basados en mensaje
entre procesos para proporcionar abstracciones de un nivel mayor, tales
como invocaciones remotas y eventos.
Aplicaciones, servicios.
}
RMI y RPC
Capas
{ Protocolo petición respuesta

Empaquetado y representación externa de datos
Middleware
UDP y TCP
Figura 2. Capas middleware
103
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.
Figura 3. Modulos e Interfaces
104
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, 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,..)
105
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 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
106
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 clientes y mientras que otros como objetos
servidores (Arquitectura Cliente-Servidor).
COMUNICACIÓN ENTRE OBJETOS DISTRIBUIDOS
Figura 4. Comunicación entre objetos distribuidos 107

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.
Figura 5. Referencia a objetos remotos
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.
Figura 6. Interfaces remotas
108
3.3.3. Acciones en un Sistema de Objetos Distribuidos.
Como en el caso local, las acciones de un objeto remoto, puede
afectar a otros objetos también remotos. En cada caso se emplea
RMI, para tener acceso a los objetos remotos.
Figura 7. Acciones de un objeto remoto
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
109
Figura 8. Invocaciones semanticas
3.4.1.1. Invocación Pudiera ser:

Un método se invoca solamente una vez, después de un
time out no se reintenta Es útil en aplicación donde se
puede tolerar esos tipos de fallos:
 Fallo por omisión de la invocación o de la respuesta
 Fallo del servidor donde reside el método remoto
3.4.1.2. Invocación Al menos una vez:

A menos que reciba una respuesta o una excepción,
reenvía el mensaje de invocación.
 Fallo por caída del servidor
 Fallo producto invocar más de una vez un método
(pude generar resultados erróneos.
Aceptable si la invocación a un método es idempotente
(si se activa más de una vez produce los mismos
resultados, ejemplo: saldo de una cuenta)
3.4.1.3. Invocación Máximo una vez:
El proceso envía sólo un mensaje de invocación al
método remoto, Recibe una respuesta o una excepción.
Es necesario considerar todos los fallos posibles para
enmascararlos.
110
3.4.2. Transparencia.
Semántica de invocación, Ubicación, Empaquetado, Paso
deMensaje, Recuperación ante fallos, Latencia es mayor al
invocar un objeto remoto, Ante una invocación fallida, construir
mecanismos para restaurar el estado del objeto remoto
4. IMPLEMENTACIÓN RMI
En una invocación de método remoto están involucrados varios objetos y
modulos separados. Como se muestra en la figura en la que un objeto A del
nivel de aplicación invoca a unmetodo en un objeto remoto B del nivel de
aplicación para el cual dispone de una referencia de objeto remoto.
Observamos los papeles de cada uno de los componentes mostrados en la
figura, tratando promero con los modulos de comunicación y referencias
remotas y después con el software RMI que se ejecuta en ellas.
Figura 9. Invocacion a metodos remotos (RMI)
4.1. Modulo de Comunicación:

Figura 9. Invocacion a metodos remotos (RMI)
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.
Figura 10. Modulo de comunicacion
111
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 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.
112
Cuando es una aplicación algunas veces nos referimos a ella como
Aplicación de Objetos Distribuidos.
Las aplicaciones de objetos distribuidos necesitan
 Localizar Objetos Remotos
Las aplicaciones pueden utilizar uno de los dos mecanismos para
obtener referencias a objetos remotos. Puede registrar sus objetos
remotos con la facilidad de nombrado de RMI rmiregistry. O puede
pasar y devolver referencias de objetos remotos como parte de su
operación normal.
 Comunicar con Objetos Remotos
Los detalles de la comunicación entre objetos remotos son
manejados por el RMI; para el programador, la comunicación
remota se parecerá a una llámada estándard a un método Java.
 Cargar Bytecodes para objetos que son enviados.
Como RMI permite al llamador pasar objetos Java a objetos
remotos, RMI proporciona el mecanismo necesario para cargar el
código del objeto, así como la transmisión de sus datos.
Figura 11. Aplicación RMI de java
La figura muestra una aplicación RMI distribuida que utiliza el

registro para obtener referencias a objetos remotos. El servidor
llama al registro para asociar un nombre con un objeto remoto. El
cliente busca el objeto remoto por su nombre en el registro del
servidor y luego llama a un método. Esta ilustración también
113
muestra que el sistema RMI utiliza una servidor Web existente para
cargar los bytecodes de la clase Java, desde el servidor al cliente y
desde el cliente al servidor, para los objetos que necesita.
5.1.1. Ventajas de la Carga Dinámica de Código
Una de las principales y únicas características de RMI es la
habilidad de descargar los bytecodes (o simplemente, código) de
una clase de un objeto si la clase no está definida en la máquina
virtual del recibidor. Los tipos y comportamientos de un objeto,
anteriormente sólo disponibles en una sóla máquina virtual,
ahora pueden ser transmitidos a otra máquina virtual,
posiblemente remota. RMI pasa los objetos por su tipo
verdadero, por eso el comportamiento de dichos objetos no
cambia cuando son enviados a otra máquina virtual. Esto
permite que los nuevos tipos sean introducidos en máquinas
virtuales remotas, y así extender el comportamiento de una
aplicación dinámicamente. El ejemplo del motor de cálculo de
este capítulo utiliza la capacidad de RMI para introducir un
nuevo comportamiento en un programa distribuido.
5.1.2. Interfaces, Objetos y Métodos Remotos
Una aplicación distribuida construida utilizando RMI de Java, al
igual que otras aplicaciones Java, está compuesta por interfaces y
clases. Los interfaces definen métodos, mientras que las clases
implementan los métodos definidos en los interfaces y, quizás,
también definen algunos métodos adicionales. En una aplicación
distribuida, se asume que algunas implementaciones residen en
diferentes máquinas virtuales. Los objetos que tienen métodos
que pueden llamarse por distintas máquinas virtuales son los
objetos remotos.
Un objeto se convierte en remoto implementando un interface
remoto, que tenga estas caracterísitcas.
 Un interface remoto desciende del interface java.rmi.Remote.
114
 Cada método del interface declara que lanza una
java.rmi.RemoteException además de cualquier excepción
específica de la aplicación.
El RMI trata a un objeto remoto de forma diferente a como lo
hace con los objetos no-remotos cuando el objeto es pasado
desde una máquina virtual a otra. En vez de hacer una copia de
la implementación del objeto en la máquina virtual que lo recibe,
RMI pasa un stub para un objeto remoto. El stub actúa como la
representación local o proxy del objeto remoto y básicamente,
para el llamador, es la referencia remota. El llamador invoca un
método en el stub local que es responsable de llevar a cabo la
llamada al objeto remoto.
Un stub para un objeto remoto implementa el mismo conjunto de
interfaces remotos que el objeto remoto. Esto permite que el stub
sea tipado a cualquiera de los interfaces que el objeto remoto
implementa. Sin embargo, esto también significa que sólo
aquellos métodos definidos en un interface remoto están
disponibles para ser llamados en la máquina virtual que lo
recibe.
5.1.3. Crear Aplicaciones Distribuidas utilizando RMI
Cuando se utiliza RMI para desarrollar una aplicación
distribuida, debemos seguir estos pasos generales.
 Diseñar e implementar los componentes de nuestra aplicación
distribuida.
 Compilar los Fuentes y generar stubs.
 Hacer las clases Accesibles a la Red.
 Arrancar la Aplicación.
 Construir un Motor de Cálculo Genérico
115
5.1.4. Diseñar e implementar los componentes de nuestra aplicación
distribuida.
Primero, decidimos la arquitectura de nuestra aplicación y
determinamos qué componentes son objetos lcoales y cuales
deberían ser accesibles remotamente. Este paso incluye.
 Definir los Interfaces Remotos. Un interface remoto
especifica los métodos que pueden ser llamados remotamente
por un cliente. Los clientes programan los interfaces remotos,
no la implementación de las clases de dichos interfaces. Parte
del diseño de dichos interfaces es la determinación de
cualquier objeto local que sea utilizado como parámetro y los
valores de retorno de esos métodos; si alguno de esos
interfaces o clases no existen aún también tenemos que
definirlos.
 Implementar los Objetos Remotos. Los objetos remotos
deben implementar uno o varios interfaces remotos. La clase
del objeto remoto podría incluir implementaciones de otros
interfaces (locales o remotos) y otros métodos (que sólo
estarán disponibles localmente). Si alguna clase local va a ser
utilizada como parámetro o cómo valor de retorno de alguno
de esos métodos, también debe ser implementada.
 Implementar los Clientes. Los clientes que utilizan objetos
remotos pueden ser implementados después de haber
definido los interfaces remotos, incluso después de que los
objetos remotos hayan sido desplegados.
5.1.5. Compilar las Fuentes y Generar stubs.
Este es un proceso de dos pasos. En el primer paso, se utiliza el
compilador javac para compilar los ficheros fuentes de Java, los
cuales contienen las implementaciones de los interfaces remotos,
las clases del servidor, y del cliente. En el segundo paso es
utilizar el compilador rmic para crear los stubs de los objetos
116
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 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
117
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
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.
Figura 12. Interfaz compute

118
Cada uno de los interfaces contiene un sólo método. El interface
del motor de cálculo Compute, permite que los trabajos sean
enviados al motor, mientras que el interface Task define cómo el
motor de cálculo ejecuta una tarea enviada.
El interface compute.Compute define la parte accesible
remotamente - el propio motor de cálculo.
Codigo interface remoto con su único método.
package compute;
import java.rmi.Remote;
import java.rmi.RemoteException;
public interface Compute extends Remote {
Object executeTask(Task t) throws RemoteException;
}
Al extender el interface java.rmi.Remote, este interface se marca
a sí mismo como uno de aquellos métodos que pueden ser
llamados desde cualquier máquina virtual. Cualquier objeto que
implemente este interface se convierte en un objeto remoto.
Como miembro de un interface remoto, el método executeTask
es un método remoto. Por lo tanto, el método debe ser definido
como capaz de lanzar una java.rmi.RemoteException. Esta
excepción es lanzada por el sistema RMI durante una llamada a
un método remoto para indicar que ha fallado la comunicación o
que ha ocurrido un error de protocolo.
La segunda interface necesitada por el motor de cálculo define el
tipo Task. Este tipo es utilizado como un argumento del método
executeTask del interface Compute. El interface compute.Task
define la interface entre el motor de cálculo y el trabajo que
necesita hacer, proporcionando la forma de iniciar el trabajo.
Código tipo task
package compute;
import java.io.Serializable;
public interface Task extends Serializable {
Object execute();
}
El interface Task define un sólo método, execute. Este método
devuelve un Object, y no tiene parámetros ni lanza excepciones.
119
Como este interface no extiende Remote, el método no necesita
listar java.rmi.RemoteException en su clausula throws.
5.2.2. Implementar una Interface Remoto
La clase que implementa el interface Compute, implementa un
objeto remoto. Esta clase también propociona el resto del código
que configura el programa servidor: un método main que crea
un ejemplar del objeto remoto, lo registra con la facilidad de
nombrado, y configura un controlador de seguridad, la
implementación de la clase para un interface remoto debería al
menos.
 Declarar los Interfaces remotos que están siendo
implementados.
 Definir el constructor del objeto remoto.
 Proprorcionar una implementación para cada método
remoto de cada interface remoto.
El servidor necesita crear e instalar los objetos remotos. Este
proceso de configuración puede ser encapsulado en un método
main en la propia clase de implementación del objeto remoto, o
puede ser incluido completamente en otra clase.
El proceso de configuración debería.
 Crear e instalar un controlador de seguridad.
 Crear uno o más ejemplares del objeto remoto.
 Registrar al menos uno de los objetos remotos con el registro
de objetos remotos de RMI (a algún otro servicio de
nombrado que utilice JNDI).
Código motor de cálculo. La clase engine.ComputeEngine
implementa el interface remoto Compute y también incluye el
método main para configurar el motor de cálculo.
package engine;
import java.rmi.*;
import java.rmi.server.*;
import compute.*;
120
public class ComputeEngine extends UnicastRemoteObject
implements Compute
{
public ComputeEngine() throws RemoteException {
super();
}
public Object executeTask(Task t) {
return t.execute();
}
public static void main(String[] args) {
if (System.getSecurityManager() == null) {
System.setSecurityManager(new RMISecurityManager());
}
String name = "//localhost/Compute";
try {
Compute engine = new ComputeEngine();
Naming.rebind(name, engine);
System.out.println("ComputeEngine bound");
} catch (Exception e) {
System.err.println("ComputeEngine exception: " +
e.getMessage()); e.printStackTrace();
}
}
}
 Declarando las Interfaces Remotos que están siendo
Implementados
La clase que implementa el motor de cálculo se declara
como.
public class ComputeEngine extends UnicastRemoteObject
implements Compute
Esta declaración indica que la clase implementa el interface
remoto Compute (y, por lo tanto, define un objeto remoto)
y extiende la clase java.rmi.server.UnicastRemoteObject.
 Definir el Constructor
La clase ComputeEngine tiene un único constructor que no
toma argumentos.
public ComputeEngine() throws RemoteException {
super();
}
121
Nota:
En el JDK 1.2, podríamos indicar el puerto específico que
un objeto remoto utiliza para aceptar peticiones.
 Proporcionar una Implementación para cada Método

Remoto
La clase para un objeto remoto proporciona
implementaciones para todos los métodos remotos
especificados en los interfaces remotos. El interface
Compute contiene un sólo método remoto, executeTask,
que se implementa de esta forma.
public Object executeTask(Task t) {
return t.execute();
}
 Pasar Objetos en RMI
Los argumentos y los tipos de retorno de los métodos
remotos pueden ser de casi cualquier tipo Java, incluyendo
objetos locales, objetos remotos y tipos primitivos. Más
precisamente, una entidad de cualquier tipo Java puede ser
pasada como un argumento o devuelta por un método
remoto siempre que la entidad sea un ejemplar de un tipo
que sea.
 Un tipo primitivo de Java,
 un objeto remoto, o
 un objeto serializable lo que significa que implementa el
interface java.io.Serializable
Estas son las reglas que gobiernan el paso y retorno de
valores.
 Los objetos remotos se pasan esencialmente por
referencia. Una referencia a un objeto remoto es
realmente un stub, que es un proxy del lado del cliente
122
que implementa el conjunto completo de interfaces
remotos que implementa el objeto remoto.
 Los objetos locales son pasados por copia utilizando el
macanismo de serialización de objetos de Java. Por
defecto, todos los campos se copian, excepto aquellos
que están marcados como static o transient. El
comportamiendo de la serialización por defecto puede
ser sobrecargado en una básica clase-por-clase.
 El método main() del Servidor
El método más complicado de la implementación de
ComputeEngine es el método main. Este método es
utilizado para arrancar el ComputeEngine, y, por lo tanto,
necesita hacer la inicialización necesaria para preparar el
servidor para aceptar llamadas de los clientes. Este método
no es un método remoto, lo que significa que no puede ser
llamado desde otra máquina virtual que no sea la suya.
Cómo el método main se declara static, no está asociado
con ningún objeto, sino con la clase ComputeEngine.
 Crear e Instalar un Controlador de Seguridad
Lo primero que hace el método main es crear e instalar
un controlador de seguridad. Éste protege los accesos a
los recursos del sistema por parte de código no firmado
que se ejecute dentro de la máquina virtual. El
controlador de seguridad determina si el código
descargado tiene acceso al sistema de ficheros local o
puede realizar cualquier otra operación privilegiada.
Aquí temos el código que crea e instala el controlador de
seguridad.
System.setSecurityManager(new
RMISecurityManager());}
123
 Poner el Objeto Remoto a Disposición de los Clientes
Luego, el método main crea un ejemplar de
ComputeEngine. Esto se hace con la sentencia.
Compute engine = new ComputeEngine();
Antes de que un llamador pueda invocar un método de
un objeto remoto, debe obtener una referencia al objeto
remoto. Este puede hacerse de la misma forma que en
que se obtiene cualquier otra referencia en un programa
Java, que es obteniéndolo como parte del valor de
retorno de un método o como parte de una estructura de
datos que contenga dicha referencia.
La clase ComputeEngine crea un nombre para el objeto
con la sentencia.
String name = "//localhost
/Compute";
Este nombre incluye el nombre del host localhost, en el
que se están ejecutando el registro y el objeto remoto, y
un nombre Compute, que identifica el objeto remoto en
el registro. Luego está el código necesario para añadir el
nombre al registro RMI que se está ejecutando en el
servidor. Esto se hace después (dentro del bloque try con
la sentencia.
Naming.rebind(name, engine);
Una vez que el servidor se ha registrado en el registro
RMI local, imprime un mensaje indicando que está listo
para empezar a manejar llamadas, y sale del método
main. Como el programa entrega una referencia de
ComputeEngine en el registro, éste es alcanzable por un
cliente remoto (¡el propio registro!). El sistema RMI tiene
cuidado de mantener vivo el proceso ComputeEngine. El
124
ComputeEngine está disponible para aceptar llamadas y
no será reclamado hasta que.
 su nombre sea eliminado del registro, y
 ningún cliente remoto mantenga una referencia al
objeto ComputeEngine.
La pieza final de código del método
ComputeEngine.main maneja cualquier excepción que
pudiera producirse.
5.2.3. Crear un Programa Cliente
El motor de cálculo es un bonito y sencillo programa - ejecuta las
tareas que le son enviadas. Los clientes del motor de cálculo son
más complejos. Un cliente necesita llamar al motor de cálculo,
pero también tiene que definir la tarea que éste va a realizar.
Nuestro ejemplo está compuesto por dos clases separadas. la
primera clase ComputePi, busca y llama a un objeto Compute. La
segunda clase Pi, implementa el interface Task y define el trabajo
que va a hacer el motor de cálcilo. El trabajo de la clase Pi es
calcular el valor del número pi, con algún número de posiciones
decimales.
Como recordaremos, el interface no-remoto Task se define de
esta forma.
package compute;
public interface Task extends java.io.Serializable {
Object execute(); }
El interface Task extiende java.io.Serializable por lo que
cualquier objeto que lo implemente puede ser serializado por el
sistema RMI y enviado a una máquina virtual remota como parte
de una llamada a un método remoto. Podríamos haber elegido
hacer que la implementación de nuestra clase implementara los
interfaces Task y Serializable, y hubiera tenido el mismo efecto.
Sin embargo, el único proposito del interface Task es permitir
125
que las implementaciones de este interface sean pasadas a
objetos Compute, por eso, una clase que implemente el interface
Task no tiene sentido que también implemente el interface
Serializable. Dado esto, hemos asociado explícitamente los dos
interfaces en el tipo system, asegurando que todos los objetos
Task sean serializables.
El código que llama a los métodos del objeto Compute debe
obtener una referencia a ese objeto, crear un objeto Task, y luego
pedir que se ejecute la tarea. Más adelante veremos la definición
de la tarea Pi. Un objeto Pi se construye con un sólo argumento,
la precisión deseada en el resultado. El resultado de la ejecución
de la tarea es un java.math.BigDecimal que representa el número
pi calculado con la precisión especificada.
La clase cliente ComputePi.
package client;
import java.rmi.*;
import java.math.*;
import compute.*;
public class ComputePi {
public static void main(String args[]) {
System.setSecurityManager(new RMISecurityManager());
}
try {
String name = "//" + args[0] + "/Compute";
Compute comp = (Compute) Naming.lookup(name);
Pi task = new Pi(Integer.parseInt(args[1]));
BigDecimal pi = (BigDecimal) (comp.executeTask(task));
System.out.println(pi);
} catch (Exception e) {
System.err.println("ComputePi exception: " +
e.getMessage());
126
e.printStackTrace();
}
}
}
Al igual que el servidor ComputeEngine, el cliente empieza
instalando un controlador de seguridad. Esto es necesario
porque RMI podría descargar código en el cliente. En este
ejemplo, el stub ComputeEngine es descargado al cliente.
Siempre que el RMI descargue código, debe presentarse un
controlador de seguridad. Al igual que el servidor, el cliente
utiliza el controlador de seguridad proporcionado por el sistema
RMI para este propósito.
Después de llamar al controlador de seguridad, el cliente
construye un nombre utilizado para buscar un objeto remoto
Compute. El valor del primer argumento de la línea de
comandos args[0], es el nombre del host remoto, en el que se
están ejecutando los objetos Compute. Usando el método
Naming.lookup, el cliente busca el objeto remoto por su nombre
en el registro del host remoto. Cuando se hace la búsqueda del
nombre, el código crea una URL que específica el host donde se
está ejecutando el servidor. El nombre pasado en la llamada a
Naming.lookup tiene la misma síntaxis URL que el nombre
pasado a la llamada Naming.rebind que explícamos en páginas
anteriores.
Luego, el cliente crea un objeto Pi pasando al constructor de Pi el
segundo argumento de la línea de comandos, args[1], que indica
el número de decimales utilizados en el cálculo. Finalmente, el
cliente llama al método executeTask del objeto remoto Compute.
El objeto pasado en la llamada a executeTask devuelve un objeto
del tipo java.math.BigDecimal, por eso el programa fuerza el
127
resultado a ese tipo y almacena en resultado en la variable result.
Finalmente el programa imprime el resultado.
Figura 13. Flujo de mensaje
Flujo de mensajes entre el cliente ComputePi, el rmiregistry, y el

ComputeEngine.
Finalmente, echemos un vistazo a la clase Pi. Esta clase
implementa el interface Task y cálcula el valor del número pi con
un número de decimales especificado. Desde el punto de vista de
este ejemplo, el algoritmo real no es importante (excepto, por
supuesto, para la fiabilidad del cálculo). Todo lo importante es
que el cálculo consume numéricamene muchos recursos (y por
eso es el tipo que cosa que querríamos hacer en un servidor
potente).
Aquí tenemos el código de la clase Pi, que implementa Task.
package client;
import compute.*;
import java.math.*;
public class Pi implements Task {
/** constantes utilizadas en el cálculo de pi*/
private static final BigDecimal ZERO =
BigDecimal.valueOf(0);
private static final BigDecimal ONE =
private static final BigDecimal FOUR =
/** 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;
}
128
/**
* 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.
*/
public static BigDecimal computePi(int digits) {
int scale = digits + 5;
BigDecimal arctan1_5 = arctan(5, scale);
BigDecimal arctan1_239 = arctan(239, scale);
BigDecimal pi =
arctan1_5.multiply(FOUR).subtract(arctan1_239).multiply(FOUR
);
return pi.setScale(digits,
BigDecimal.ROUND_HALF_UP);
}
/**
* Calcula el valor, en radianes, de la arcotangente de la
* inversa del entero suministrado para el número de decimales.
* El valor se calcula utilizando la poderosa serie de
* expansiones de arcotangente.
* arctan(x) = x - (x^3)/3 + (x^5)/5 - (x^7)/7 +
* (x^9)/9 ...
*/
public static BigDecimal arctan(int inverseX,
int scale)
{
BigDecimal result, numer, term;
BigDecimal invX = BigDecimal.valueOf(inverseX);
BigDecimal invX2 =
BigDecimal.valueOf(inverseX * inverseX);
numer = ONE.divide(invX, scale, roundingMode);
result = numer;
int i = 1;
do {
numer =
numer.divide(invX2, scale, roundingMode);
int denom = 2 * i + 1;
term =
129
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 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
130
stub remoto ComputeEngine será descargado desde el servidor hasta
el cliente durante la ejecución.
El ejemplo separa los interfaces, la implementación de los objetos
remotos y el código del cliente en tres paquetes diferentes.
 compute (Los interfaces Compute y Task)
 engine (Implementación de la clase, el interface y el stub de
ComputeEngine)
 client (la implementación del cliente ComputePi y de la tarea Pi).
5.3.1. Construir un Fichero JAR con las Clases de Interfaces

Primero necesitamos compilar los ficheros fuente de los
interfaces del paquete compute que construir un fichero JAR que
contenga los ficheros class. Supongamos que el usuario waldo ha
escrito estos interfaces particulares y ha situado los ficheros
fuente en c:\home\waldo\src\compute (en UNIX sería,
/home/waldo/src/compute). Con estos paths podemos utilizar
los siguientes comandos para compilar los intefaces y crear el
fichero JAR.
Detalles específicos de la Plataforma: Construir un Fichero JAR

Windows.
cd c:\home\waldo\src
javac compute\Compute.java
javac compute\Task.java
jar cvf compute.jar compute\*.class
UNIX.
cd /home/waldo/src
javac compute/Compute.java
javac compute/Task.java
jar cvf compute.jar compute/*.class
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%)
131
adding: compute/Task.class (in=200) (out=164)
(deflated 18%)
Ahora podemos distribuir el fichero compute.jar a los

desarrolladores de las aplicaciones del cliente y del servidor para
que puedan hacer uso de los interfaces.
La accesibilidad en la red de los ficheros de clases permite al
sistema RMI descargar código cuando sea necesario. En vez de
definir su propio protocolo para descargar código, RMI utiliza
un protocolo URL soportado por Java (por ejemplo, HTTP) para
descargar el código.
5.3.2. Construir las Clases del Servidor

El paquete engine sólo contiene la implementación de la clase del
lado del servidor, ComputeEngine, la implementación del objeto
remoto del interface Compute. Como ComputeEngine es una
implementación de un interface remoto, necesitamos generar un
stub para el objeto remoto para que los clientes puedan contactar
con él.
Digamos que, ana, la desarrolladora de la clase ComputeEngine,
ha situado ComputeEngine.java en el directorio
c:\home\ana\src\engine, y ha colocado el fichero class para que
lo usen los clientes en un subdirectorio de su directorio
public_html, c:\home\ana\public_html\classes (en UNIX
podría ser /home/ana/public_html/classes, accesible
mendiante algún servidor web como
http://host/~ana/classes/).
Asumamos que el fichero compute.jar esta localizado en el
directorio c:\home\ana\public_html\classes. Para compilar la
clase ComputeEngine, nuestro path de clases 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
132
Detalles Específicos de la Plataforma: Compilar el Motor de Cálculo y sus Stubs
Windows.
cd c:\home\ana\src
javac engine\ComputeEngine.java
rmic -d . engine.ComputeEngine
mkdir c:\home\ana\public_html\classes\engine
cp engine\ComputeEngine_*.class
c:\home\ana\public_html\classes\engine
Unix.
cd /home/ana/src
javac engine/ComputeEngine.java
rmic -d . engine.ComputeEngine
mkdir /home/ana/public_html/classes/engine
cp engine/ComputeEngine_*.class
Windows.
set CLASSPATH=c:\home\ana\src;c:\home\ana\public_html\classes\compute.jar
Unix:
setenv CLASSPATH /home/ana/src:/home/ana/public_html/classes/compute.jar
Ahora compilamos el fichero fuente ComputeEngine.java y
generamos un stub para la clase ComputeEngine y coloca el stub
accesible a la red. Para crear el stub (y opcionalmente los ficheros
esqueleto) ejecutamos el compilador rmic sobre los nombres
totalmente cualificados de las clases de implementación de los
objetos remotos que deberían encontrarse en el path de clases. El
comando rmic toma uno o más nombres de clase como entrada y
produce, como salida, ficheros de clases con la forma
ClassName_Stub.class (y opcionalmente ClassName_Skel.class).
El fichero esqueleto no será generado si llamamos a rmic con la
opción -v1.2. Esta opción sólo debería utilizarse si todos nuestros
clientes van a utilizar el JDK 1.2 o posterior.
La opción -d le dice al compilador rmic que situe los ficheros de
clases generados, ComputeEngine_Stub y 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
133
poner estas clases disponibles en la red. Por eso, el paso final es
desempaquetar el fichero compute.jar en el directorio
c:\home\ann\public_html\classes para hacer que los interfaces
Compute y Task estén disponibles para su descarga.
Detalles Específicos de la Plataforma: Desempaquetar el Fichero JAR
Windows.
cd c:\home\ana\public_html\classes
jar xvf compute.jar
Unix.
cd /home/ana/public_html/classes
jar xvf compute.jar
El comando jar muestra esta salida.
created: META-INF/
extracted: META-INF/MANIFEST.MF
extracted: compute/Compute.class
extracted: compute/Task.class
5.3.3. Construir las clases del Cliente
Asumamos que el usuario jones ha creado el código del cliente
en el directorio c:\home\jones\src\client y colocará la clase Pi
(para que sea descargada por el motor de cálculo) en el directorio
accesible a la red c:\home\jones\public_html\classes (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\compu
te.jar
cd c:\home\jones\src
javac client\ComputePi.java
javac -d c:\home\jones\public_html\classes client\Pi.java
134
UNIX.
setenv CLASSPATH
/home/jones/src:/home/jones/public_html/classes/compute.jar
cd /home/jones/src
javac client/ComputePi.java
javac -d /home/jones/public_html/classes client/Pi.java
Sólo necesitamos situar la clase Pi en el directorio

public_html\classes\client (el directorio client lo crea el javac si
no existe). Esto es así por esta clase es la única que necesita ser
desacargada por la máquina virtual del motor de cálculo.
5.4. Ejecutar el Ejemplo
Una Nota sobre la Seguridad
El modelo de seguridad del JDK 1.2 es más sofisticado que el modelo
utilizado en el JDK 1.1. Contiene ampliaciones para seguridad de
grano fino y requiere código que permita los permisos específicos para
realizar ciertas operaciones.
En el JDK 1.1, todo el código que haya en el path de clases se considera
firmado y puede realizar cualquier operación, el código descargado
está gobernado por las reglas del controlador de seguridad instalado.
Si ejecutamos este ejemplo en el JDK 1.2 necesitaremos especificar un
fichero de policía cuando ejecutemos el servidor y el cliente. Aquí
tenemos un fichero de policía general que permite al código
descargado desde cualquier codebase, hacer dos cosas.
 conectar o acceptar conexiones en puertos no privilegiados
(puertos por encima del 1024) de cualquier host, y
 conectar con el puerto 80 (el puerto HTTP).
grant {
permission java.net.SocketPermission "*:1024-65535",
"connect,accept";
permission java.net.SocketPermission "*:80", "connect";
};
Si hacemos nuestro código disponible mediante URLs HTTP,
deberíamos ejecutar el fichero de policía anterior cuando ejecutemos
este ejemplo. Sin embargo, si utilizarámos un fichero de URLs en su
lugar, podemos utilizar el fichero de policía siguiente. Observa que en
135
entornos windows, la barra invertida necesita ser representada con
dos barras invertidas en el fichero de policía.
grant {
permission java.net.SocketPermission "*:1024-65535",
"connect,accept";
permission java.io.FilePermission
"c:\\home\\ana\\public_html\\classes\\-", "read";
permission java.io.FilePermission
"c:\\home\\jones\\public_html\\classes\\-", "read";
};
Este ejemplo asume que el fichero de policía se llama java.policy y
contiene los permisos apropiados. Si ejecutamos este ejemplo en el
JDK 1.1, no necesitamos un fichero de policía ya que el
RMISecurityManager proporciona toda la protección que necesitamos.
Arrancar el Servidor
Antes de arrancar el motor de cálculo, necesitamos arrancar el registro
de RMI con el comando rmiregistry. Como explicamos en páginas
anteriores el registro RMI es una facilidad de nombrado que permite a
los clientes obtener una referencia a un objeto remoto.
Observa que antes de arrancar el rmiregistry, debemos asegurarnos de
que el shell o ventana en la que ejecutaremos rmiregistry no tiene la
variable de entorno CLASSPATH, o si la tiene ésta no incluye el path a
ninguna 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).
136
Para arrancar el registro en el servidor, se ejecuta el comando
rmiregistry. Este comando no produce ninguna salida y normalmente
se ejecuta en segundo plano.
Detalles Específicos de la Plataforma: Arrancar el Registro en el Puerto por
Defecto
Windows (utilizar javaw si no está disponible start).
unset CLASSPATH
start rmiregistry
UNIX.
unsetenv CLASSPATH
rmiregistry &
Por defecto el registro se ejecuta sobre el puerto 1099. Para arrancar el

registro sobre un puerto diferente, se especifica el número de puerto
en la línea de comandos. No olvidemos borrar el CLASSPATH.
Detalles Específicos de la Plataforma: Arrancar el Registro en el Puerto 2001
Windows.
start rmiregistry 2001
UNIX.
rmiregistry 2001
Una vez arrancado el registro, podemos arrancar el servidor. Primero,

necesitamos asegurarnos de que el fichero compute.jar y la
implementación del objeto remoto (que es lo que vamos a arrancar)
están en nuestro path de clases.
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

Windows.
137
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
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.jar
java -Djava.rmi.server.codebase=file:/c:\home\jones\public_html\classes/
client.ComputePi localhost 20
UNIX.
setenv CLASSAPTH /home/jones/src:/home/jones/public_html/classes/compute.jar
java -Djava.rmi.server.codebase=http://ford/~jones/classes/
client.ComputePi zaphod.east.sun.com 20
Después de arrancar el cliente, deberíamos ver la siguiente salida en

nuesta pantalla. 3.14159265358979323846
138
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 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
139
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.
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/
140
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?
141
SISTEMAS DE ARCHIVOS
DISTRIBUIDOS
Los sistemas de archivos distribuidos soportan la compraticion de información
en forma de archivos a través de internet. Un servicio de archivos bien 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.
 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 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
142
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.
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
Figura 1. Estructura tipica de un sitema de archivos
143
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.
144
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 en los sistemas
de archivos convencionales y deben proporcionar un nivel de
prestaciones comparable.
145
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.
Programa Programa Servicio de directorio

De De
aplicación aplicación
Servicio de archivos
plano
Módulo de cliente
Figura 2. Arquitectura del servicio de archivos
3.1. Servicio de Archivos Planos.

El servicio de archivos planos esta relacionado con la implemntacion de
operaciones en el contenido de los archivos. Se utilizan identificadores
únicos de archivos (UFID) para referirse a los archivos n todas las
solicitudes de operaciones del servicio de archivo plano. La división de
responsabilidades entre el servicio de archivos y el servicio de directorio,
esta basada esta basada en la utlizacion de la UFID. Cada UFID es una
secuencia larga de bits elegidas de forma que cada archivo tiene una
UFID que es único entre todos los archivos en un sistema distribuido.
146
Cuando el servicio de archivos planos recibe una solicitud para crear un
archivo, genera un nuevo UFID para el y lo devuelve al solicitante.
3.2. Servicio de directorio.
El servicio de directorio proporciona una transformación entre nombres
de texto para los servicios UFID. Los clientes pueden obtener UFID de un
archivo indicando su nombre de texto al servicio de directorio. El
servicio de directorio proporciona las funciones necesarias para generar
directorios. Para añadir nuevos nombres de archivo a los directorios y
para obtener UFID desde los directorios. Es un cliente del servicio de
archivos plano, sus archivos de directorio están almacenados en archivos
del servicio de archivos plano. Cuando se adopta un esquema jerarquico
de nominación de archivos, como el UNIX, los directorios mantienen
referencia a otros directorios.
3.3. Modulo cliente.
En cada computador cliente se ejecuta un modulo cliente, que integra y
extiende las operaciones del servicio de archivos plano y el servicio de
directorio bajo una interfaz de programación de aplicaciones sencilla,
que estará disponible para los programas a nivel de usuario en los
computadores cliente. Por ejemplo en maquinas UNIX, se debe
proporcionar un modulo cliente que emula un conjunto total de
operaciones UNIX sobre archivos, interpretando los nombres
compuestos por UNIX mediante reiteradas solicitudes al servicio de
directorio. El modulo cliente mantiene también información sobre las
ubicaciones en la red del proceso servidor de archivos planos y del
proceso servidor de directorio.
3.4. Control de Acceso
En el sistema de archivos UNIX, se comprueban los derechos de acceso
del usuario frente al modo de acceso (lectura y escritura) solicitado en la
operación de llamada y el archivo solo es abierto solo si el usuario tiene
los derechos de acceso necesarios. La identidad del usuario (UID)
utilizada en la comprobación de los derechos de acceso es el resultado
147
del login autenticado anterior del usuario y no puede ser alterado en las
implementaciones no distribuidas. Los derechos de acceso resultantes se
retienen hasta que el archivo se cierra y no se necesitan otras
comprobaciones en las operaciones posteriores solicitadas sobre el
mismo archivo.
En las implemntaciones distribuidas, la comprobación de los derechos de
acceso se ha de realizar en el servidor por que la interfaz del servidor
RPC es un punto desprotegido de acceso para los archivos. La identidad
del usuario ha de pasarse con cada solicitud y el servidor se hace
vulnerable a identidades antiguas.
3.5. Sistema de Archivos Jerarquico
Un servicio de archivos jerarquico, como uno de los que proporciona
UNIX, consiste en un número de directorios organizados en una
estructura de árbol. Cada directorio contiene los nombres de los archivos
y toros directorios que son accesibles que son accesibles desde él.
Cualquier archivo o directorio puede ser referenciado con un nombre de
ruta (path), un nombre compuesto de varias partes que representa una
ruta a través del árbol. La raíz tiene un nombre que le distingue y cada
archivo o directorio tiene un nombre en un directorio. El esquema de
nominación de los archivos de UNIX no es jerarquica estricta, los
archivos pueden tener varios nombres y pueden estar en varios
directorios. Esto se implementa mediante una operación de enlace (link)
que añade un nuevo nombre para un archivo en un directorio
especificado.
3.6. Agrupacion de Archivos.
Un grupo de archivos es una colección de archivos ubicada en un
servidor dado. Un servidor puede mantener varios grupos de archivos y
los grupos pueden ser recolocados entre servidores, pero un archivo no
puede cambiar el grupo al que pertenece. Una construcción similar
(llamada filesystem-volumen) se utiliza en UNIX y en la mayoría de los
sistemas operativos. Los grupos de archivos se introdujeron inicialmente
148
paratrasladar colecciones de archivos almacenados en cartuchos de disco
extraíbles en computadores. En un servicio de archivos distribuidos los
grupos de archivos permiten la asignación de archivos a servidores de
archivos almacenados en varios servidores.
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 originalmente para su utilización en redes de sistemas UNIX. El
módulo servidor NFS reside en el núcleo de cada computador que actúa
como un servidor NFS. Las solicitudes que se refieren a archivos en un
sistema de archivos remoto se traducen en el módulo cliente a operaciones
del protocolo NFS y después se trasladan al módulo servidor NFS en el
computador que mantiene el sistema de archivos relevante.
Los módulos cliente y servidor NFS se comunican utilizando llamadas a
procedimientos remotos.
Computador Cliente Computador servidor

Programa Programa
De De
aplicación aplicación
LLamadas al
Núcleo UNIX
sistema UNIX
Sistema de archivos virtual
Sistema de archivos virtual
Núcleo UNIX Local Remoto
Sistema de
Sistema de
Otro sistema de
Servidor archivos
archivos Cliente
NFS UNIX
UNIX NFS
archivos
Protocolo
NFS
Figura 3. Sistema de archivos en red de SUN
149
 Sistemas de Archivos Virtuales.- Otros sistemas de archivos
distribuidos pueden considerar que permiten las llamadas al sistema de
UNIX, y si lo hacen, podrían integrarse de la misma forma. La
integración se obtiene mediante un módulo de archivos virtual (VFS),
que ha sido añadido al núcleo de UNIX para distinguir entre archivos
remostos y locales y para traducir los identificadores de archivos,
independientes de UNIX y otros sistemas de archivos. En resumen, VFS
mantiene la pista de los sistemas de archivos que están actualmente
disponibles tanto local como remotamente, pasa cada solicitud al módulo
del sistema local apropiado (el sistema de archivos UNIX, el módulo
cliente NFS o el módulo de servicio de otro sistema de archivos).
Los identificadores de archivos utilizados en NFS se llama apuntadores

de archivos (file handles). Un apuntador de archivo es opaco para los
clientes y contiene toda la información que necesita el servidor para
distinguir un archivo individual.
 Integración del Cliente.- El cliente NFS juega el papel descrito para el

módulo cliente en nuestro modelo arcquitectónico, proporcionado una
interfaz idóneo para su uso por programas de aplicación convencionales.
Pero a diferencia del módulo cliente de nuestyro modelo, emula la
semántica de las primitivas del sistema de archivos estándar de UNIX de
forma precisa y está integrado con un nucleo UNIX. Está integrado con el
núcleo y no proporcionado como una librería para cargar en los procesos
cliente de modo que:
– Los programas de usuario pueden acceder a los archivos mediante

llamadas del sistema de UNIX sin recopilación o recarga.
– Un único módulo cliente sirve a todos los procesos del nivel del
usuario, con una caché compartida de los bloques utilizados
recientemente.
150
– La clave de encriptación utilizada para autentificar ID del usuario
pasadas al servidor puede retenerse en el núcleo, previniendo la
impersonaciónpor clientes a nivel de usuario.
El módulo cliente de NFS coopera con el sistema de archivos virtual en

cada máquina cliente. Funciona transferiendo bloques de archivos hacia
y desde el servidor y haciendo caching de los bloques en la memoria
local cuando es posible. Comparte el mismo buferde caché que el
utilizado por el sistema de entrada – salida local. Pero puesto que varios
clientes en diferentes máquinas pueden acceder simultaneamente al
mismo archivo 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.
151
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?
152
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.
 Definir, describir que es una amenaza y ataque en sistemas distribuidos.
 Definir, describir los tipos de ataques en los sistemas de distribuidos.
 Conocer e implementar las técnicas de seguridad los sistemas de
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 asi obtener copias de información confidencial que los clientes,
inconcientemente envían para su almacenamiento.
153
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.
 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.
154
 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

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
155
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 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.
156
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;
inner-round pipelining; outer-round pipelining; mixed inner- and outer-
round pipelining.
157
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.
158
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.
159
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.
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..
160
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 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
161
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.
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?
162

Sistemas Distribuidos UPLA PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Sistemas Distribuidos UPLA PDF

Cargado por

Copyright:

Formatos disponibles

Copyright©2005 UNIVERSIDAD PERUANA LOS ANDES

Programa de Educación a Distancia.

Prohibida la reproducción total o parcial sin autorización

La redacción de este texto estuvo a cargo de

Conceptos de los Sistemas Distribuidos

Seguridad en Sistemas Distribuidos

Modelos de Sistemas Distribuidos

Figura 1. Representación de un Sistema Distribuido

1. CARACTERISTICAS DE LOS SISTEMAS DISTRIBUIDOS

 Concurrencia.- En una red de computadores, la ejecución de programas

Figura 3. Red LAN, WAN

Ejemplos de Sistemas Distribuidos

Figura 4. Computacion Movil y Ubicua

Figura 5. Proceso Cliente – Proceso Servidor

Figura 6. Recursos Compartidos en la web

A pesar de que internet consta de muchos tipos de redes diferente, sus

Figura 7. Sistemas Distribuidos como MIddleware

2.1.1 CAPAS DE SOFTWARE

Son procesos u objetos que implementan mecanismos de

2.1.2 ARQUITECTURA DE LOS MODELOS

Figura 3. Clientes que invocan a servidores individuales.

Figura 4. Un servicio proporcionado por multiples servidores.

 Servidores Proxy y Caches

Figura 5. Un servidor proxy del tipo web

Figura 6. Como funciona un proxy

Figura 7. Aplicación distribuida basa en

2.1.4 VARIACIONES DEL MODELO CLIENTE SERVIDOR

Figura 8. Interfaz de un dispositivo movil

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

Figura 10. Distribucion de carga

Figura 11. Intercomunicacion espontanea en un hotel

Figura 12. Modelo de iteraccion de un Sistema Distribuido

En la comunicación hay retrasos. El modelo estudia cómo afectan

Figura 13. Ordenamiento de eventos

Si estuvieran sincronizados seria así

Figura 14. Tabla de entrada de mensajes

Fallos por Omisión

Buffer de del canal Buffer de

Figura 15. Fallos por omision de canal

Figura 16. Modelo de Seguridad de sistemas distribuidos

Asegurar procesos y sus interacciones

Figura 18. El enemigo

Figura 1. Elementos de la Comunicación

En teoría, una comunicación simple, como un video musical o un e-mail

Figura 2. Segmentacion de Paquetes

Figura 3. Elementos de una Red

3.1 Modelo TCP/IP

Figura 5. Modelo TCP/IP

Figura 6. Transporte de un paquete

Figura 7. Encapsulamiento de Datos

La forma que adopta una sección de datos en cualquier capa se

Figura 8. Direccionamiento de PDU

Cuando se envían mensajes en una red, el stack del protocolo de un

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

3.2 Modelo OSI

Figura 10. Comunicación capa a capa

El modelo OSI describe los procesos de codificación, formateo,

Figura 11. Direccionamiento por capas

Figura 12. Direccionamiento en la capa 3

En la Capa 4, la información contenida en el encabezado de la PDU no

Figura 13. Direccionamiento en la capa 4

Cada capa ofrece lo mejor para garantizar la comunicación entre

4.1 Responsabilidades de la capa de Red