COMUNICACIN EN LOS SISTEMAS

DISTRIBUIDOS

PROFESOR: Dr. David Luis la Red Martnez

ALUMNO: Maximiliano Blasco

LU: 41.476

AO: 2012

1. Introduccin
La computacin desde sus inicios ha sufrido muchos cambios, desde los ordenadores que
permitan realizar tareas en forma limitada y de uso un tanto exclusivo de organizaciones
muy selectas.
Los mayores cambios se atribuyen principalmente a dos causas, que se dieron desde la
dcada de los setenta.
1) El desarrollo de los microprocesadores, que permitieron reducir en tamao y costo
a los ordenadores y aumentar en gran medida las capacidades de los mismos y su
acceso a ms Personas.
2) El desarrollo de las redes de rea local (LAN) y de las comunicaciones que
permitieron conectar ordenadores con posibilidad de alta transferencia.
En este contexto es que aparece el concepto de SISTEMAS DISTRIBUIDOS que se ha
popularizado tanto en la actualidad y que tiene como mbito de estudio las redes como por
ejemplo: Internet, Redes de Telfonos Mviles, Redes de Empresas, etc.

2. Etapas
En los 40's, se introducen los programas bit a bit, por medio de interruptores
mecnicos y despus se introdujo el lenguaje de mquina que trabajaba por tarjetas
perforadas.
Con las primeras computadoras, desde finales de los aos 40 hasta la mitad de los
aos 50, el programador interactuaba de manera directa con el hardware de la
computadora, no exista realmente un Sistema Operativo; las primeras
computadoras utilizaban bulbos, la entrada de datos y los programas se realizaban a
travs del lenguaje mquina (bits) o a travs de interruptores.
Durante los aos 50's y 60's.- A principio de los 50's, la compaa General's Motors
implanto el primer sistema operativo para su IBM 170. Empiezan a surgir las
tarjetas perforadas las cuales permiten que los usuarios (que en ese tiempo eran
programadores, diseadores, capturistas, etc.), se encarguen de modificar sus
programas. Establecan o apartaban tiempo, metan o introducan sus programas,
corregan y depuraban sus programas en su tiempo. A esto se le llamaba trabajo en
serie. Todo esto se traduca en prdida de tiempo y tiempos de programas excesivos.
En los aos 60's y 70's se genera el circuito integrado, se organizan los trabajos y se
generan los procesos Batch (por lotes), lo cual consiste en determinar los trabajos
comunes y realizarlos todos juntos de una sola vez. En esta poca surgen las
unidades de cinta y el cargador de programas, el cual se considera como el primer
tipo de Sistema Operativo.

 En los 80's, inici el auge de la Internet en los Estados Unidos de Amrica. A

finales de los aos 80's comienza el gran auge y evolucin de los Sistemas
Operativos. Se descubre el concepto de multiprogramacin que consiste en tener
cargados en memoria a varios trabajos al mismo tiempo, tema principal de los
Sistemas Operativos actuales.
En los 90's y en adelante, entramos a la era de la computacin distribuida y del
multiprocesamiento a travs de mltiples redes de computadoras, aprovechando el
ciclo del procesador.

3. Tipos de sistemas
Desde una perspectiva histrica se puede hablar de diferentes modelos que determinan la
funcionalidad y la estructura de un sistema de cmputo, las caractersticas del sistema
operativo como gestor de los recursos, y su campo de aplicacin y uso:
Sistemas de lotes. Son los primeros sistemas operativos, que permitan procesar en
diferido y secuencialmente datos suministrados en paquetes de tarjetas perforadas.
Hoy en da, sobre sistemas multiprogramados con interfaces de usuario interactivas,
el proceso por lotes tiene sentido en aplicaciones de clculo intensivo, por ejemplo
en supercomputacin.
Sistemas centralizados de tiempo compartido. Fue el siguiente paso, a mediados de
los 60. El objetivo es incrementar la eficiencia en el uso de la CPU, un recurso
entonces caro y escaso, disminuyendo los tiempos de respuesta de los usuarios, que
operan interactivamente. Los recursos estn centralizados y se accede al sistema
desde terminales.
Sistemas de teleproceso. Se diferencian del modelo anterior en que los terminales
son remotos y acceden a un sistema central utilizando una infraestructura de red
(por ejemplo la telefnica) y un protocolo de comunicaciones normalmente de tipo
propietario. El sistema central monopoliza la gestin de los recursos. Ejemplos de
aplicaciones que resolva este modelo son los sistemas de reservas y de
transacciones bancarias.
Sistemas personales. Este tipo de sistemas proporciona un sistema dedicado para un
nico usuario, lo que fue posible gracias al abaratamiento del hardware por la
irrupcin del microprocesador a comienzos de los 80. Los primeros sistemas
operativos eran monoprogramados (MS-DOS), la mejora del hardware pronto
permiti soportar sistemas multitarea (Macintosh, OS/2, Windows 95/98), e incluso
sistemas operativos diseados para tiempo compartido, como UNIX y Windows
NT1. Por otra parte, la evolucin hardware ha llevado a los ordenadores personales
hacia versiones mviles (PC porttiles y otros dispositivos como PDAs y telfonos
mviles).
Sistemas en red. En la evolucin del teleproceso, los terminales fueron ganando
capacidad de cmputo y funcionalidad hasta convertirse en sistemas autnomos. El
concepto de computador central desaparece; ahora hay que hablar de un conjunto de
computadores que se conectan entre s utilizando una infraestructura de red. Una

mquina que proporciona el acceso a un determinado recurso es el servidor de ese

recurso. Los clientes, que pueden disponer de recursos locales, acceden a un recurso
remoto mediante solicitud al servidor correspondiente.
Sistemas distribuidos. Los recursos de diferentes mquinas en red se integran de
forma que desaparece la dualidad local/remoto. La diferencia fundamental con los
sistemas en red es que la ubicacin del recurso es transparente a las aplicaciones y
usuarios, por lo que, desde este punto de vista, no hay diferencia con un sistema de
tiempo compartido. El usuario accede a los recursos del sistema distribuido a travs
de una interfaz grfica de usuario desde un terminal, despreocupndose de su
localizacin. Las aplicaciones ejecutan una interfaz de llamadas al sistema como si
de un sistema centralizado se tratase. El modelo de sistema distribuido es el ms
general, por lo que, aunque no se ha alcanzado a nivel comercial la misma
integracin para todo tipo de recursos, la tendencia es clara a favor de este tipo de
sistemas. La otra motivacin es la relacin de costes a la que ha llevado la evolucin
tecnolgica en los ltimos aos. Hoy en da existe un hardware estndar de bajo
coste, los ordenadores personales, que son los componentes bsicos del sistema. Por
otra parte, la red de comunicacin, a no ser que se requieran grandes prestaciones,
tampoco constituye un gran problema econmico, pudindose utilizar
infraestructura cableada ya existente (Ethernet, la red telefnica, o incluso la red
elctrica) o inalmbrica.

4. Diferencia entre un Sistema Operativo Centralizado y uno

Distribuido
Sistemas Operativos Centralizados
Utiliza los recursos de una sola computadora, es decir, su memoria, CPU, disco y
perifricos. Podemos decir que se suele tratar de un computador caro y de gran potencia.
Podemos encontrar este tipo de sistemas operativos en un entorno de empresa. Donde todo
el procesamiento de la organizacin se lleva a cabo en una sola computadora, normalmente
un Mainframe, y los usuarios usan sencillos ordenadores personales. Un problema del
modelo se da cuando la carga de procesamiento aumenta, se debe cambiar o ampliar el
hardware del Mainframe, lo cual es ms costoso que aadir ms computadores personales
clientes o servidores que aumenten las capacidades.
Son muy conocidos los sistemas centralizados con los que contamos en la actualidad, basta
con empezar por los que tenemos instalados en nuestras propias computadoras como
Windows, Linux, Mac OS, Unix, etc.
Sistemas Operativos Distribuidos
Segn Tanenbaum, un sistema distribuido es una coleccin de computadoras
independientes que aparecen ante los usuarios del sistema como una nica computadora.

Un sistema distribuido se caracteriza por comportarse frente al usuario como una sola
mquina; el usuario desconoce qu procesador est ejecutando sus procesos y dnde
residen sus ficheros.
Los sistemas operativos de red estn formados por un software dbilmente acoplado en un
hardware dbilmente acoplado. De no ser por el sistema compartido de archivos a los
usuarios les parecera que el sistema consta de varias computadoras.
El siguiente paso en la evolucin es el software fuertemente acoplado en hardware
dbilmente acoplado, es la aparicin de los sistemas distribuidos. El objetivo es crear la
ilusin en las mentes de los usuarios que toda la red de computadoras es un sistema de
tiempo compartido, en vez de mquinas diversas.
Debe haber un mecanismo de comunicacin global entre los procesos, de forma que
cualquier proceso pueda comunicarse con cualquier otro. Tambin un sistema global de
proteccin. La administracin de procesos, la forma en que se crean, destruyen y detienen
los procesos y tambin el sistema de archivos debe tener la misma apariencia en todas
partes.
Los sistemas distribuidos se basan en la utilizacin de sistemas de transmisin fiables,
eficaces, rpidos que permitan integrar sistemas de distintos fabricantes.
Ejemplos de aplicaciones distribuidas

Remote login.
Correo electrnico.
Navegacin Web.
Streaming.
Telefona IP.
Comparticin de ficheros (P2P).

5. Ventajas de los sistemas distribuidos con respecto a los

centralizados
Economa: es la razn nmero uno de la tendencia hacia los sistemas distribuidos
ya que estos sistemas tienen en potencia una porcin precio/desempeo mucho
mejor que la de un sistema centralizado.
Velocidad: un sistema distribuido puede tener mayor poder de cmputo que una
mainframe.
Distribucin inherente: otra razn para la construccin de un sistema distribuido es
que ciertas aplicaciones son distribuidas en forma inherente; es decir, algunas
aplicaciones utilizan mquinas que estn separadas a cierta distancia.

 Confiabilidad: al distribuir la carga de trabajo en varias mquinas la falla de un

circuito descompondra a lo sumo una mquina pero las dems seguiran operativos.
Crecimiento por incrementos: se basa en que no es necesario comprar una nueva
mainframe carsima cuando la empresa necesita ms poder de cmputo,
simplemente bastante con agregar ms procesadores.

6. Ventajas de los sistemas distribuidos con respecto a las PC

independientes
Datos Compartidos: un sistema distribuido permite que varios usuarios tengan
acceso a una base de datos comn.
Dispositivos Compartidos: de igual manera, se pueden compartir perifricos entre
diversos usuarios como puede ser una impresora.
Comunicacin: un sistema distribuido facilita la comunicacin entre computadoras
aisladas como por ejemplo con el e-mail.

7. Desventajas de los Sistemas Distribuidos

El Software: qu lenguajes de programacin utilizar, que aplicaciones son
adecuadas.
Las redes de comunicacin: Se pueden perder mensajes por lo que se requiere un
software especial para su manejo y el sistema puede verse sobrecargado. Al
saturarse la red sta debe reemplazarse o aadir una segunda red. De cualquier
forma, es un gran costo.
La seguridad: es con frecuencia un problema, el hecho de que los datos se puedan
compartir puede ser un arma de doble filo, pues algn intruso podra acceder a los
datos que no les correspondera ver.

8. Propiedades de los sistemas distribuidos

Un sistema distribuido que pretenda ofrecer una visin de sistema nico deber cumplir las
propiedades que se presentan a continuacin.
8.1 Transparencia
El objetivo esencial de un sistema distribuido es proporcionar al usuario y a las aplicaciones
una visin de los recursos del sistema como gestionados por una sola mquina virtual. La
distribucin fsica de los recursos es transparente.
Pueden describirse diferentes aspectos de la transparencia:

 Transparencia de Acceso: Permite el acceso a los objetos de informacin remotos

de la misma forma que a los objetos de informacin locales.
Transparencia de Localizacin: Permite el acceso a los objetos de informacin sin
conocimiento de su localizacin.
Transparencia de Concurrencia: Permite que varios procesos operen
concurrentemente utilizando objetos de informacin compartidos y de forma que no
exista interferencia entre ellos.
Transparencia de Replicacin: Permite utilizar mltiples instancias de los objetos
de informacin para incrementar la fiabilidad y las prestaciones sin que los usuarios
o los programas de aplicacin tengan por que conoces la existencia de las replicas.
Transparencia de Fallos: Permite a los usuarios y programas de aplicacin
completar sus tareas a pesar de la ocurrencia de fallos en el hardware o en el
software.
Transparencia de Migracin: Permite el movimiento de objetos de informacin
dentro de un sistema sin afectar a los usuarios o a los programas de aplicacin.
Transparencia de Prestaciones: Permite que el sistema sea reconfigurado para
mejorar las prestaciones mientras la carga vara.
Transparencia de Escalado: Permite la expansin del sistema y de las aplicaciones
sin cambiar la estructura del sistema o los algoritmos de la aplicacin.
Las dos ms importantes son las transparencias de acceso y de localizacin; su presencia o
ausencia afecta fuertemente a la utilizacin de los recursos distribuidos. A menudo se las
denomina a ambas transparencias de red. La transparencia de red provee un grado similar
de anonimato en los recursos al que se encuentra en los sistemas centralizados.
8.2 Escalabilidad
Una de las caractersticas de los sistemas distribuidos es su modularidad, lo que le permite
una gran flexibilidad y posibilita su escalabilidad, definida como la capacidad del sistema
para crecer sin aumentar su complejidad ni disminuir su rendimiento.
Uno de los objetivos del diseo de un sistema distribuido es extender la escalabilidad a la
integracin de servicios.
La escalabilidad presenta dos aspectos. El sistema distribuido debe (1) proporcionar
espacios de nombres suficientemente amplios, de forma que no supongan una limitacin
inherente, y (2) mantener un buen nivel de rendimiento en el acceso a los recursos cuando
el sistema crece.
Espacios de nombres. Los espacios de nombres, al igual que en los sistemas
centralizados, pueden identificar objetos de diferente naturaleza, como ficheros,
procesos, variables, o incluso direcciones de memoria.
Complejidad/rendimiento. El crecimiento de un sistema distribuido puede
introducir cuellos de botella y latencias que degradan su rendimiento. Adems del
incremento de los costes de comunicacin por el aumento de la distancia fsica
entre los componentes del sistema. Es necesario, por tanto, establecer compromisos
entre tamao del sistema, rendimiento y complejidad.

8.3 Fiabilidad y tolerancia a fallos

La fiabilidad de un sistema puede definirse como su capacidad para realizar correctamente
y en todo momento las funciones para las que se ha diseado. La fiabilidad se concreta en
dos aspectos:
Disponibilidad. Es la fraccin de tiempo que el sistema est operativo. La
disponibilidad se puede incrementar de dos formas: (a) utilizando componentes de
mayor calidad, y/o (b) con un diseo basado en la replicacin de componentes que
permita al sistema seguir operando aun cuando algunos de ellos fallen. Ambas
alternativas incrementan el coste del sistema; sin embargo, en el estado tecnolgico
actual, la replicacin resulta, en general, menos costosa. Los sistemas distribuidos
proporcionan inherentemente la replicacin de algunos recursos (por ejemplo,
unidades de proceso), mientras que otros normalmente compartidos (por ejemplo,
un servidor de ficheros) pueden replicarse para aumentar la disponibilidad. Por otra
parte, la ausencia de fallos en los componentes de un sistema, tanto hardware como
software, nunca puede garantizarse, de modo que, ms all de unos lmites, la
replicacin es necesaria para seguir incrementando la disponibilidad, ya que la
probabilidad de fallo disminuye como una funcin exponencial de la replicacin.
Tolerancia a fallos. An con una alta disponibilidad, un fallo en un momento
determinado puede tener consecuencias desastrosas. Pinsese en sistemas de tiempo
real crticos que controlan dispositivos vitales (por ejemplo en medicina, centrales
nucleares...). Es decir, aunque la replicacin aumenta la disponibilidad, no garantiza
por s sola la continuidad del servicio de forma transparente. La tolerancia a fallos
expresa la capacidad del sistema para seguir operando correctamente ante el fallo de
alguno de sus componentes, enmascarando el fallo al usuario o a la aplicacin. Por
lo tanto, la tolerancia a fallos implica (1) detectar el fallo, y (2) continuar el servicio
de forma transparente para la aplicacin (transparencia de fallos).
8.4 Consistencia
El problema de mayor complejidad es el de la gestin del estado global para evitar
situaciones de inconsistencia entre los componentes del sistema. Este es un aspecto
fundamental en el diseo del sistema distribuido, por lo que el problema radica en la
necesidad de mantener un estado global consistente en un sistema con varios componentes,
cada uno de los cuales posee su propio estado local. Los nodos del sistema se hallan
fsicamente distribuidos, por lo que la gestin del estado global depende fuertemente de los
mecanismos de comunicacin, a su vez soportados por una red sujeta a fallos. Como
veremos, la gestin de la consistencia puede basarse en una buena sincronizacin entre los
relojes de los nodos o en mecanismos de ordenacin de eventos (relojes lgicos). La
distribucin fsica hace, en general, inviable la utilizacin de un reloj global que aporte
referencias absolutas de tiempo, lo que permitira una ordenacin total de los eventos y, por
lo tanto, de las transiciones de estado en cada nodo.
As pues, el mantenimiento de una consistencia estricta requiere un fuerte soporte que
implica gran carga de comunicacin adicional entre los nodos del sistema, por lo que
muchas veces es preferible relajar la consistencia para mantener el rendimiento en un nivel
aceptable, de acuerdo a las necesidades de las aplicaciones.

9. Comunicacin en los sistemas distribuidos

La diferencia principal entre un sistema distribuido y un sistema con un procesador es la
comunicacin entre procesos. En un sistema con un procesador la mayor parte de la
comunicacin entre procesos supone la existencia de memoria compartida. Un proceso
escribe en un buffer compartido y otro proceso lee de l. En un sistema distribuido no
existe tal memoria compartida, por lo que toda la comunicacin se basa en la transferencia
de mensajes.
Para los sistemas distribuidos de rea amplia relativamente lentos, se utilizan los protocolos
de capas orientadas hacia la conexin como OSI y TCP/IP, dado que el problema principal
a resolver es el transporte confiable de los bits a travs de lneas fsicas pobres.
Para los sistemas basados en LAN, los protocolos con capas se utilizan muy poco. En vez
de ellos, se adopta por lo general un modelo mucho ms sencillo en donde el cliente enva
un mensaje al servidor y ste enva de regreso una respuesta al cliente.
Tambin se utiliza mucho la llamada a procedimientos remotos (RPC). Con ella un proceso
cliente que se ejecuta en una mquina llama a un procedimiento que se ejecuta en otra
mquina.

10. Sincronizacin en sistemas distribuidos

Es importante la forma en que los procesos cooperan y se sincronizan entre s. Por ejemplo,
la forma de implantar las regiones crticas o asignar recursos en un sistema distribuido.
En los sistemas con un CPU, los problemas relativos a regiones crticas, la exclusin mutua
y la sincronizacin se resuelven en general mediante mtodos tales como los semforos y
monitores. Pero estos no son adecuados para sistemas distribuidos, puesto que siempre se
basan en la existencia de memoria compartida, por lo que se necesitan otras tcnicas. La
mayora de sistemas operativos distribuidos tienen un paquete de hilos.
La sincronizacin de procesos en los sistemas distribuidos resulta ms compleja que en los
centralizados, debido a que la informacin y el procesamiento se mantienen en diferentes
nodos.
Un sistema distribuido debe mantener vistas parciales y consistentes de todos los procesos
cooperativos y de cmputo. Tales vistas pueden ser provistas por los mecanismos de
sincronizacin. La sincronizacin no tiene por qu ser exacta, y bastar con que sea
aproximadamente igual en todos los ordenadores. Hay que tener en cuenta, eso s, el modo
de actualizar la hora de un reloj en particular.

11. Procesos y procesadores

Se utilizan por lo comn dos modelos de organizacin de los procesadores:
Modelo de estacin de trabajo.
Modelo de la pila de procesadores.
En el primero, cada usuario tiene su propia estacin de trabajo y a veces puede ejecutar
procesos en las estaciones de trabajo inactivas.
En el segundo, todas las instalaciones de cmputo son un recurso compartido. Los
procesadores se asignan de manera dinmica a los usuarios conforme sea necesario y se
regresan a la pila al terminar el trabajo.
Dada una coleccin de procesadores, se necesita un algoritmo que asigne los procesos a los
procesadores, estos pueden ser deterministas o heursticos, centralizados o distribuidos,
ptimos o subptimos, locales o globales, iniciados por el emisor o por el receptor.

12. Sistemas distribuidos de archivos

Un componente fundamental es el sistema de archivos, es el corazn de cualquier sistema
distribuido. La tarea del sistema de archivos es almacenar los programas y los datos y
tenerlos disponibles cuando sea necesario.
El servicio de archivos es la especificacin de los servicios que el sistema de archivos
ofrece a los clientes.
El servidor de archivos es un proceso que se ejecuta en alguna mquina y ayuda a implantar
el servicio de archivos. Puede haber uno o varios servidores de archivos pero los clientes no
deben conocer cuntos hay ni su posicin o funcin. Todo lo que saben es llamar a los
procedimientos especificados en el servicio de archivos y el trabajo se hace en alguna parte.
Lo ideal es que se vea como un sistema de archivos normal de un procesador. Puede haber
varios servidores de archivos, por ejemplo uno UNIX y uno en MS-DOS.

13. Memoria compartida distribuida

Existen dos tipos de sistema con varios procesadores:
Multiprocesadores.
Multicomputadoras.
En un multiprocesador varias CPU comparten una memoria principal comn. En el caso de
una multicomputadora cada CPU tiene su memoria particular, nada se comparte.
No se puede utilizar muchos procesadores con una sola memoria compartida porque se
origina un cuello de botella.

En el caso de las multicomputadoras, como no permite la memoria compartida se tiene que

utilizar la transferencia de mensajes, haciendo que la entrada/salida sea la abstraccin
central. La transferencia de mensajes trae consigo varios aspectos delicados como el flujo
de control, la prdida de mensajes, el uso de buffer y el bloqueo. Aunque se han propuesto
varias soluciones, la programacin con transferencia de mensajes es todava difcil.
Tambin se propuso las llamadas a procesamientos remotos. Para utilizar un servicio
remoto, un proceso solo llama al procedimiento de la biblioteca adecuada, el cual
empaqueta el cdigo de la operacin y los parmetros del mensaje, envindolo por la red y
esperando la respuesta.
En un sistema operativo distribuido, la memoria pasa a ser fsicamente privada pero
lgicamente compartida. Es decir, un computador ejecuta los programas en su memoria
propia, pero en caso de necesitar ms memoria utilizar los recursos disponibles de otra
computadora que est capacitada y preparada dentro de la red para compartir su memoria.

14. Protocolos de comunicacin

14.1. La ISO (Organizacin Internacional de Estndares) desarroll un modelo de
referencia que:

Identifica en forma clara los distintos niveles.

Estandariza los nombres de los niveles.
Seala cul nivel debe realizar cul trabajo.

Este modelo se denomina modelo de referencia para interconexin de sistemas

abiertos (ISO OSI o modelo OSI).
El modelo OSI est diseado para permitir la comunicacin de los sistemas abiertos:

Son aquellos preparados para comunicarse con cualquier otro sistema abierto
mediante reglas estndar, establecen el formato, contenido y significado de los
mensajes recibidos y enviados.
Constituyen los protocolos, que son acuerdos en la forma en que debe desarrollarse la
comunicacin.

El modelo OSI distingue entre dos tipos generales de protocolos:

Orientados hacia las conexiones:

o Antes de intercambiar los datos, el emisor y el receptor:
Establecen en forma explcita una conexin.
Probablemente negocien el protocolo a utilizar.
Al finalizar, deben terminar la conexin.
El telfono es un sistema de comunicacin orientado hacia la
conexin.
Sin conexin:
o No es necesaria una configuracin de antemano.
o El emisor transmite el primer mensaje cuando est listo.
o El depsito de una carta en un buzn es una comunicacin sin conexin.

Cada capa proporciona una interfaz con la otra capa por encima de ella; la interfaz consiste
en un conjunto de operaciones para definir el servicio que la capa est preparada para
ofrecer a sus usuarios.
Cada protocolo de capa se puede cambiar independientemente de los dems esto es de
fundamental importancia ya que confiere gran flexibilidad.
La coleccin de protocolos utilizados en un sistema particular se llama una pila de
protocolos.
El modelo de la OSI es una solucin elegante y realmente aplicable en muchos casos,
pero tiene un problema: la existencia de los encabezados genera un costo adicional de
transmisin.

Cada envo de un mensaje genera:

o Proceso en media docena de capas.
o Preparacin y agregado de encabezados en el camino hacia abajo.
o Eliminacin y examen de encabezados en el camino hacia arriba.

Con enlaces del orden de decenas (o centenas) de miles de bits / segundo y cpu poderosas:

La carga de procesamiento de los protocolos no es significativa.

El factor limitante es la capacidad de las lneas.
Ej.: redes de rea extendida (WAN).

Con enlaces del orden de millones de bits / segundo y computadoras personales:

La carga de procesamiento de los protocolos s es frecuentemente significativa.

El factor limitante no es la capacidad de las lneas.
Ej.: redes de rea local (LAN).

Las redes pueden exhibir fallas que impliquen la prdida de paquetes. Si slo se pierden
algunos paquetes (hay comunicacin), estas fallas pueden corregirse usando feedback en
forma de ACK y timeouts.
Cuando el servidor revive luego de una cada, su cliente puede intentar una nueva
comunicacin, retransmitiendo el ltimo request no respondido.
Qu sucede si el servidor ejecut el requerimiento la vez anterior?. Hay dos posibilidades:
El servidor recuerda lo que realiz antes de la cada, recalcula la respuesta y la enva
al Cliente.
El servidor sufre amnesia total. Olvida todo su estado, por lo tanto, conocer que es
una retransmisin, no ayuda.
Ante el modelo de amnesia total, los protocolos de comunicacin no pueden tener la
propiedad de entregar los mensajes exactamente una vez.
Pueden tener la propiedad de:
Entregar el mensaje al-menos-una-vez.
Entregar el mensaje a-lo-ms-una-vez.
Entrega al-menos-una-vez
En ausencia de fallas, entregan los mensajes exactamente-una-vez.
Ante fallas, pueden entregar un mensaje ms de una vez.
Se usa cuando los requerimientos son dem potentes.
Esconden fallas de comunicacin y de servidores.
Entrega a-lo-ms-una-vez
Detectan el hecho de que ha fallado la red o el servidor y lo reportan.
Operan en un contexto de sesin una asociacin entre dos procesos durante la cual ambos
mantienen el estado del protocolo.

Cuando se pierde el estado del protocolo, se termina la sesin.

Las sesiones tienen identificadores nicos.
14.2. Modelo Cliente - Servidor (C - S)
Es un modelo para el desarrollo de sistemas de informacin y es la integracin de un
sistema de red, con recursos, medios y aplicaciones los cuales definidos modularmente en
los servidores, ejecutan y atienden las solicitudes de los clientes logrando un enlace
transparente entre todos sus elementos.
Sus componentes son: el Cliente, el Servidor y la Infraestructura de Comunicaciones.

El servidor contiene la parte que ser compartida por varios usuarios y el cliente solo la
particular de cada usuario.
Una computadora es servidor si ejecuta una aplicacin/proceso que sea servidor.
Las caractersticas ms importantes de la arquitectura cliente/servidor son:

El servidor presenta a todos sus clientes una interface nica y bien definida.
El cliente no necesita conocer la lgica del servidor, solo su interface externa.
El cliente no depende de la ubicacin fsica del servidor, ni del equipo fsico en el que
se encuentra, ni de su sistema operativo.
Los cambios en el servidor implican pocos o ningn cambio en el cliente.

A continuacin se describen las caractersticas de los sistemas desarrollados en arquitectura

Cliente/Servidor:

Se basa en un protocolo solicitud / respuesta:

Es sencillo y sin conexin.

No es complejo y orientado a la conexin como OSI o TCP / IP.
El cliente enva un mensaje de solicitud al servidor pidiendo cierto servicio.
El servidor:
o Ejecuta el requerimiento.
o Regresa los datos solicitados o un cdigo de error si no pudo ejecutarlo
correctamente.
No se tiene que establecer una conexin sino hasta que sta se utilice.
La pila del protocolo es ms corta y por lo tanto ms eficiente.
Si todas las mquinas fuesen idnticas solo se necesitaran tres niveles de
protocolos.

Direccionamiento
Para que un cliente pueda enviar un mensaje a un servidor, debe conocer la direccin de
ste.
Los principales mtodos para direccionar procesos son:
Integrar machine.number al cdigo del proceso cliente: en el que machine indica el
nmero de mquina dentro de la red y number, el nmero de proceso dentro de esa
mquina. Es un mtodo no transparente.

Dejar que los procesos elijan direcciones al azar y localizarlos mediante

transmisiones: El emisor transmite un paquete especial de localizacin con la
direccin del proceso destino, todos los ncleos de las mquinas en la red reciben este
mensaje y verifican si la direccin es la suya; en caso de que lo sea, regresa un mensaje
aqu estoy con su direccin en la red (nmero de maquina). El ncleo emisor utiliza
entonces esa direccin y la captura para uso posterior. Su desventaja es que genera una
carga adicional en el sistema.
Generar un servidor de nombres: Cada vez que se ejecute un cliente en su primer
intento por utilizar un servidor, el cliente enva una solicitud al servidor de nombres
(en ASCII) para pedirle el nmero de la mquina donde se localiza el servidor. Una vez
obtenida la direccin se puede enviar la solicitud de manera directa.
Tambin existe el mtodo de dejar que cada proceso elija su propio identificador:
En un espacio de direcciones grande y disperso, por ej.: enteros binarios de 64 bits. La
probabilidad de que dos procesos elijan el mismo nmero es muy pequea. Existe el
problema, para el ncleo emisor, de saber a qu mquina enviar el mensaje:
o
o
o
o

En una LAN, el emisor puede transmitir un paquete especial de

localizacin con la direccin del proceso destino.
Este paquete de transmisin ser recibido por todas las mquinas de la red.
Todos los ncleos verifican si la direccin es la suya; si lo es, regresa un
mensaje aqu estoy con su direccin en la red (nmero de mquina).
El ncleo emisor utiliza esa direccin y la captura para evitar a posteriori
una nueva bsqueda del servidor.

Es un esquema transparente, pero la transmisin provoca una carga adicional en el

sistema. Se puede evitar con una mquina adicional para la asociacin de los nombres
de servicios y las direcciones de las mquinas.

Primitivas de transferencia de mensajes en C - S

Generalmente se considera que las desventajas de las primitivas asncronas no compensan

las ventajas del mximo paralelismo que permiten lograr.
Una primitiva sncrona es aquella en que el emisor se bloquea hasta que el receptor ha
aceptado el mensaje y la confirmacin regresa al emisor.
Todo lo dems es asncrono con este criterio.
Generalmente a las primitivas de envo se las conoce como send y
de recepcin como receive y ambas pueden ser con bloqueo o sin bloqueo.

las

Una recepcin sin bloqueo le indica al ncleo la localizacin del buffer y regresa el control:

El problema es saber quin hizo la llamada cuando se llev a cabo la operacin.

Primitivas Almacenadas en Buffer Vs. No Almacenadas en C - S

Las primitivas consideradas hasta ahora son esencialmente primitivas no almacenadas.
Este esquema funciona bien cuando el servidor llama a receive antes de que el cliente llame
a send.

El problema se presenta cuando el send se lleva a cabo antes que el receive:

El ncleo del servidor:
o No sabe cul de sus procesos utiliza la direccin en el mensaje recin
llegado.
o No sabe dnde copiar el mensaje recibido.
Una solucin consiste en:
Descartar el mensaje.
Dejar que el cliente espere.
Confiar en que el servidor llame a receive antes de que el cliente vuelva a
transmitir; por ello el cliente podra tener que intentar varias veces.
Si dos o ms clientes utilizan un servidor con transferencia de mensajes sin
almacenamiento en buffers:

Luego de que el servidor acept un mensaje de uno de ellos:

o Deja de escuchar a su direccin hasta que termina su trabajo.
o Regresa al principio del ciclo para volver a llamar a receive.
Si realizar el trabajo insume cierto tiempo, los dems clientes podran hacer varios
intentos de envos sin xito.

Otra solucin consiste en hacer que el ncleo receptor mantenga pendientes los
mensajes por un instante.
La llamada a receive elimina un mensaje del buzn o se bloquea (si se utilizan primitivas
con bloqueo) si no hay un mensaje presente. Esta tcnica se denomina primitiva con
almacenamiento en buffers.
Los buzones tienen el problema de que son finitos y pueden ocuparse en su totalidad,
cuando llega un mensaje a un buzn lleno, el ncleo debe elegir entre mantener el mensaje
pendiente por un momento esperando que algn mensaje sea retirado del buzn a tiempo o
descartar el mensaje.
Esta es la misma situacin que se tiene cuando se trabaja sin almacenamiento en buffers,
con buffers se reduce la probabilidad de problemas, pero los problemas no se eliminan ni
cambia su naturaleza.
Otra solucin utilizada es no dejar que un proceso enve un mensaje si no existe espacio
para su almacenamiento en el destino.

Primitivas Confiables Vs. No Confiables en C - S

Hasta ac se ha supuesto que los mensajes enviados siempre sern recibidos, pero en la
realidad, los mensajes se pueden perder por diversas causas.

Cuando un cliente enva un mensaje se le puede suspender hasta que el mensaje ha sido
enviado, cuando contina, no hay garanta de que el mensaje ha sido entregado, pues el
mensaje podra haberse perdido.
Un enfoque de este problema consiste en volver a definir la semntica de send para
hacerlo no confiable:

El sistema no garantiza la entrega de los mensajes.

La implantacin de una comunicacin confiable se deja en manos de los usuarios.

Otro mtodo exige que el ncleo de la mquina receptora enve un reconocimiento al

ncleo de la mquina emisora:

Solo cuando reciba el reconocimiento, el ncleo emisor liberar al proceso usuario

(cliente).
La solicitud de un cliente a un servidor es reconocida por el ncleo del servidor.
La respuesta del servidor de regreso al cliente es reconocida por el ncleo del
cliente.
Una solicitud de respuesta consta de cuatro mensajes.

Otra solucin aprovecha el hecho de que la comunicacin cliente - servidor se estructura:

Como una solicitud del cliente al servidor.

Seguida de una respuesta del servidor al cliente.
El cliente se bloquea despus de enviar un mensaje.
El ncleo del servidor no enva de regreso un reconocimiento sino que la misma
respuesta funciona como tal.
El emisor permanece bloqueado hasta que regresa la respuesta.
Si la respuesta no llega en cierto tiempo, el ncleo emisor puede volver a enviar la
solicitud; as se protege contra la posibilidad de una prdida del mensaje.
La respuesta funciona como un reconocimiento a la solicitud.

Otra posibilidad es la siguiente:

Al llegar una solicitud al ncleo del servidor, se inicia un cronmetro.

Si el servidor enva la respuesta antes de que termine el cronmetro, sta funciona
como el reconocimiento.
Si expira el tiempo del cronmetro, se enva un reconocimiento separado.

Implantacin del Modelo C - S

Las principales opciones de diseo analizadas se resumen en:

14.3 RPC (Remote Procedure Call)

Las ventajas del modelo Cliente/Servidor son:
El paradigma esencial en torno al que se construye la comunicacin es la
entrada/salida.
Los procedimientos send/receive estn reservados para la realizacin de e/s.
Una opcin planeada por Birrel y Nelson fue:
Permitir a los programas que llamen a procedimientos localizados en otras
mquinas.
Cuando un proceso en la mquina A llama a un procedimiento en la mquina B:
El proceso que realiza la llamada se suspende.
La ejecucin del procedimiento se realiza en B.
La informacin se puede transportar de un lado a otro mediante los parmetros y
puede regresar en el resultado del procedimiento.
El programador no se preocupa de una transferencia de mensajes de la e/s.
A est mtodo se le denomina llamada a procedimiento remoto o RPC
El procedimiento que hace la llamada y el que la recibe de ejecutan en mquinas
diferentes.

Operacin Bsica de RPC

Una RPC, en una sola mquina, funciona de la siguiente manera:

Un parmetro por valor:

Se copia a la pila.
Para el procedimiento que recibe la llamada es slo una variable local ya
inicializada.
El procedimiento podra modificarla, sin que esto afecte el valor de la variable
original en el procedimiento que hizo la llamada.
Un parmetro por referencia:
Es un apuntador a una variable (es decir, la direccin del a variable), no el valor de
la variable.
Si el procedimiento que recibe la llamada utiliza este parmetro por referencia para
almacenar algo en el arreglo, modifica el arreglo en el procedimiento que hizo la
llamada.
La llamada por copiar/restaurar es otro mecanismo de parmetros:
Quien recibe la llamada copia la variable en la pila, como en la llamada por valor.
La copia de nuevo despus de la llamada, escribiendo sobre el valor original.
Para que una RPC parezca lo ms posible a una local:
La RPC debe ser transparente

El procedimiento no debe ser consciente de que el procedimiento llamado se ejecuta

en una mquina distinta, o viceversa.
Si read es un procedimiento remoto se coloca en la biblioteca una versin distinta de
read llamada stub del cliente.

Cuando el mensaje llega al servidor:

El ncleo lo transfiere a un stub del servidor.
Generalmente el stub del servidor ya habr llamado a receive y estar bloqueado
esperando que le lleguen mensajes.
El stub del servidor: desempaca los parmetros del mensaje, llama al procedimiento
del servidor de la manera convencional.
Para el servidor es como si tuviera una llamada directa del cliente; lleva a cabo el trabajo y
regresa el resultado a quien hizo la llamada, de forma usual.
El stub del servidor recupera el control luego de la llamada y:
Empaca el resultado en un mensaje.
Llama a send para regresarlo al cliente.
Llama a receive y espera el siguiente mensaje
Cuando el mensaje regresa a la mquina cliente:
El ncleo ve que est dirigido al proceso cliente.
El mensaje se copia al buffer en espera.
El proceso cliente elimina su bloqueo.
El stub del cliente examina el mensaje, desempaca el resultado, lo copia a quien
hizo la llamada y regresa de la manera usual
Cuando el proceso que hizo la llamada obtiene el control luego de la llamada a read:
Dispone los datos.
Ignora que el trabajo se realiz de manera remota.
Ha tenido acceso a servicios remotos mediante llamadas comunes a procedimientos
locales.

En resumen, se indican los siguientes pasos como una RPC:

Transferencia de Parmetros
Ordenamiento de parmetros es el empacamiento de un mensaje, el mensaje tambin
contiene el nombre o nmero de procedimiento, y la llamada que necesita.
Cuando el mensaje llega al servidor:
El resguardo (stub) lo examina para ver cual procedimiento necesita.
Lleva a cabo la llamada apropiada.
Los elementos del mensaje corresponden a:
Identificador del procedimiento.
Parmetros.
Un mensaje que corresponda a un procedimiento remoto con n parmetros tendr n+1
campos:
Uno para identificar al procedimiento.
Uno para cada uno de los n parmetros.
Para representar la informacin de los mensajes:
Disear un estndar de red o forma cannica para los enteros, caracteres, booleanos,
nmero de punto flotante, etc.

Pedir a todos los emisores que conviertan sus representaciones internas a esta forma
durante el ordenamiento.

Es importante saber la organizacin del mensaje, la identidad del cliente y de dnde

provienen los procedimientos de resguardo:
En muchos sistemas se generan automticamente.
Dada una especificacin del procedimiento servidor y las reglas de codificacin, el
formato del mensaje queda determinado de manera nica.
Es posible tener un compilador que:
Lea las especificaciones del servidor.
Genere un resguardo del cliente que empaque sus parmetros en el formato estndar
de los mensajes.
Genere un resguardo del servidor que los desempaque.
Llame al servidor.
Para la transferencia de apuntadores la solucin es copiar en el mensaje la estructura para la
cual se utiliza el apuntador y enviarlo al servidor, los cambios afectarn directamente al
buffer de mensajes en el resguardo del servidor.
Conexin Dinmica
Se refiere a cmo el cliente localiza el servidor. Un mtodo es integrar dentro del cdigo
del cliente la direccin (en la red) del servidor:
Un problema es que resulta demasiado rgido.
Si el servidor se desplaza, si se duplica o si cambia de interfaz, habra que localizar
y volver a compilar los numerosos programas.
La solucin es la conexin dinmica que permitir que concuerden los clientes y
servidores, para lograrlo se necesita la especificacin formal del servidor, que indica el
nombre del servidor, el nmero de versin y una lista de los procedimientos que
proporciona, ejemplo: parmetro in, out o in-out.
La direccin es relativa al servidor
La especificacin formal, como generador de resguardos:
Produce el resguardo del cliente y el servidor.
Ambos resguardos se colocan en las bibliotecas respectivas.
Cuando el servidor inicia su ejecucin: una llamada tipo initialize que se encuentra fuera
del ciclo principal exporta la interfaz del servidor:
El servidor enva un mensaje a un programa conector para darle a conocer su
existencia.
Esto es el registro del servidor (registering the server).
El servidor proporciona al conector su nombre, versin y nico identificador.
El identificador generalmente tiene una longitud de 32 bits y un asa (handle) que se
utiliza para localizarlo.
El asa (handle) depende del sistema y puede ser: una direccin Ethernet, IP, X.500 o
un identificador ralo de procesos, etc.

El asa tambin proporciona informacin relativa a la autentificacin.

El servidor puede cancelar su registro con el conector si ya no est preparado para prestar
algn servicio.
Un esquema muy flexible pero que puede ser cuello de botella cuando hay mucha carga se
describe a continuacin.
El cliente localiza al servidor de la siguiente manera: cuando el cliente llama a alguno de
los procedimientos remotos por primera vez:
El resguardo del cliente: ve que an no est conectado al servidor, enva un mensaje
al conector solicitando la importacin de cierta versin de cierta interfaz.
El conector verifica si uno o ms servidores ya han exportado una interfaz con ese
nombre y versin.
Si ninguno de los servidores en ejecucin en ese momento soporta esa interfaz la
llamada fracasara.
Si existe un servidor adecuado, el conector proporciona un asa e identificador nico
al resguardo del cliente, el cual utiliza el asa como la direccin a la cual enviar el
mensaje solicitado.

Semntica de RPC en Presencia de Fallos

Los errores que pueden ocurrir en las RPC son:
El cliente no puede localizar el servidor.
Se pierde el mensaje de solicitud del cliente al servidor.
Se pierde el mensaje de respuesta del servidor al cliente.
El servidor falla antes de recibir una solicitud.
El cliente falla despus de enviar una solicitud.
El Cliente No Puede Localizar al Servidor

El cdigo -1 indica un fallo

Tambin se utiliza una variable global (UNIX) errno, que indica un tipo de error,
por ejemplo: No se pudo localizar el servidor
Tambin se puede utilizar la excepcin que provoca el error:
Se codifican procedimientos especiales que son llamados ante errores especficos.
Pero se puede destruir la transparencia, ya que dificulta mantener la similitud entre
procedimientos locales y remotos.
Prdida de Mensajes de Solicitud
El kernel debe inicializar un cronmetro al enviar la solicitud: si el tiempo se termina antes
de que regrese una respuesta, el ncleo retransmite el mensaje, si el mensaje se perdi, el
servidor no podr indicar la diferencia entre la retransmisin y el original y todo funcionar
bien. Si el nmero de mensajes perdidos supera cierto lmite, el ncleo asume que el
servidor esta inactivo y regresa a la situacin no se pudo localizar al servidor.

Prdida de Mensajes de Respuesta

Se utiliza cronmetro:
Si no llega una respuesta en un perodo razonable, se debe volver a enviar la
solicitud.
El problema es que el ncleo del cliente no est seguro de la razn por la que no
hubo respuesta.

Fallos del servidor

Estos fallos no pueden resolverse con nmeros secuenciales. Las soluciones posibles son:
Semntica al menos una:
Esperar hasta que el servidor vuelva a arrancar, e intenta de nuevo la operacin.
Mantener el intento hasta recibir una respuesta para drsela al cliente.
Garantiza que la RPC se ha realizado al menos una vez, puede realizarse ms veces.
Semntica a los ms una:
No se reintenta y se informa el fallo.
Garantiza que la RPC se realiza a lo ms una vez, puede no realizarse ni una vez.
Semntica de no garantizar nada:
Cuando el servidor falla, el cliente no obtiene ayuda o alguna promesa.
La RPC se puede realizar en cualquier lugar, un nmero de veces de 0 hasta n.
Resulta fcil de implantar.
Semntica de exactamente una:
No existe la forma de garantizarse.
La recuperacin depende del momento en que ocurre el fallo.
El cliente no tiene forma de descubrir ese instante.
Fallos del Cliente
Se genera una solicitud de trabajo que al fallar el cliente ya nadie espera, se dice que tiene
un cmputo muerto. Los problemas que se generan son:
Desperdicio de ciclos de CPU.
Posible bloqueo de archivos.
Apropiacin de recursos valiosos.
Posible confusin cuando el cliente re arranca y efecta de nuevo la RPC, la
respuesta del hurfano regresa inmediatamente luego.
Las soluciones a los cmputos hurfanos son:
Exterminacin: Se crea un registro que indica lo que va a hacer el resguardo del
cliente antes de que emita el RPC, el registro se mantiene en disco, luego del re
arranque se verifica el contenido del registro y se elimina el hurfano.
Reencarnacin: Se divide el tiempo en pocas numeradas secuencialmente, cuando
un cliente arranca enva mensaje a todas las mquinas declarando el inicio de una
nueva poca, al recibirse estos mensajes se eliminan todos los cmputos remotos.

Reencarnacin sutil: Cuando llega un mensaje de cierta poca, cada maquina

verifica si tiene cmputos remotos, en caso afirmativo intenta localizar a su
poseedor, de lo contrario se elimina el cmputo.
Expiracin: A cada RPC se le asigna un tiempo t para realizar su trabajo, puede
pedir otro quantum si es insuficiente.

Aspectos de la Implantacin
El desempeo o performance es fundamental en los sistemas distribuidos.
El desempeo depende de manera crtica de la velocidad de comunicacin.
La velocidad depende en gran medida de la implantacin.
Protocolos RPC
En los protocolos orientados a conexin:
Se establece una conexin entre cliente y servidor.
Todo el trfico en ambas direcciones utiliza esa conexin.
Se maneja a un nivel inferior mediante software que soporta la conexin.
Otra opcin son los protocolos estndar IP, sus caractersticas son:
El protocolo ya fue diseado, lo que ahorra trabajo.
Se dispone de muchas implantaciones, lo que ahorra trabajo.
Los paquetes IP se pueden enviar y recibir por casi todos los sistemas UNIX.
Los paquetes IP y UDP se pueden transmitir en muchas de las redes existentes.

Reconocimientos
Surge cuando los paquetes grandes deben dividirse en paquetes pequeos, los paquetes
sern reconocidos grupal o individualmente. Una estrategia de reconocimiento es el
protocolo detenerse y esperar (Stop and Wait Protocol):

El cliente enva el paquete 0 con el primer 1k.

El cliente espera un reconocimiento del servidor.
El cliente enva el paquete 1 con el segundo 1k, etc.
La prdida de un paquete significa que no llegar su reconocimiento, habr que
retransmitirlo.

Protocolo de chorro (Blast Protocol)

El cliente enva todo los paquetes tan pronto como puede.
El servidor reconoce todo el mensaje al recibir los paquetes, no individualmente.
La prdida del paquete puede significar la retransmisin de todo el mensaje o del
paquete perdido.
Control de flujo:
Est relacionado con la capacidad infinita de recepcin de paquetes adyacentes por
parte de los chips de la interfaz de red.
Cuando un paquete llega a un receptor que no lo puede aceptar se presenta un error
de sobre-ejecucin (overrun error) y el paquete se pierde.
El protocolo detenerse y esperar no presenta errores de sobre-ejecucin, con el protocolo
chorro s pueden ocurrir estos errores. La solucin consiste en que el emisor retrase los
paquetes para darle tiempo al receptor para:
Generar la interrupcin correspondiente al paquete.
Volver a estar listo para recepcin.
Si la sobre ejecucin se debe a la capacidad finita del buffer en el chip de red, el emisor
puede:
Enviar n paquetes y luego hacer una pausa.
Solicitar una confirmacin o reconocimiento luego de cada n paquetes.

Ruta Crtica
Serie de instrucciones que se ejecutan en cada RPC como se muestra en la siguiente figura:

Tambin es importante saber qu parte de la ruta crtica ocupa la mayor parte del tiempo de
la RPC, que depende del tipo de RPC y de la cantidad de datos que se deben transportar:
En RPC con transporte mnimo la mayor parte del tiempo se ocupa en el cambio de
contexto al resguardo del servidor al llegar un paquete, la rutina de servicio de
interrupciones y el movimiento del paquete a la interfaz de la red para su
transmisin.

El RPC con transporte de 1k o ms la mayor parte del tiempo se ocupa en el

tiempo de transmisin, y el tiempo que tarda el desplazamiento del paquete hacia
adentro y afuera de la interfaz.
Copiado
El copiado es otro aspecto que tambin suele dominar el tiempo de ejecucin. El chip de la
red puede utilizar el DMA para:
Transferir el mensaje del espacio de direcciones del resguardo del cliente a la red.
Depositarlo en la memoria del ncleo del servidor en tiempo real.
El ncleo: Inspecciona el paquete, asocia la pgina que lo contiene en el espacio de
direcciones del servidor o copia el paquete al resguardo del servidor.
La dispersin-asociacin (scatter-gather) es una caracterstica de hardware que disminuye
el copiado:

El chip de la red organiza un paquete concatenando 2 o ms buffers de memoria

situados en distinto mbito del cliente: ncleo, resguardo del cliente, etc.

En el servidor ocurre algo similar, pero con ms limitaciones.

Para evitar el copiado a resguardo con un S.O. con memoria virtual el ncleo modifica el
mapa de la memoria para asociar el buffer con el paquete en el espacio de direcciones del
servidor y enviar simultneamente el buffer del resguardo del servidor al ncleo. Los
requisitos son los siguientes:
El buffer del paquete en el ncleo ocupa toda una pgina a partir de una frontera de
la pgina.
El buffer receptor del resguardo del servidor tambin es de toda una pgina e inicia
en una frontera de pgina
Manejo del cronmetro
El establecimiento de un cronmetro requiere construir una estructura de datos que:
Especifique el momento en el que el cronmetro debe detenerse.
La accin a realizar cuando eso suceda.
La estructura de datos del cronmetro:
Se inserta en una lista de cronmetros pendientes cuando se inicializa el
cronmetro.
Se retira de la lista cuando llega un reconocimiento antes de que termine el tiempo
acordado.
Si el valor de lapso de expiracin es muy pequeo har que:
Los cronmetros expiren con mucha frecuencia.
Se realicen muchas retransmisiones innecesarias.
Un valor de lapso muy grande har que se demore un paquete perdido.
Una alternativa al almacenamiento de cronmetros es una tabla o lista ligada ordenada,
estos algoritmos se denominan lista de barrido (sweep algorithms):
Utilizar la tabla de procesos y cargar en ella un campo para su tiempo de expiracin,
si existe.
Rastrear peridicamente la tabla de procesos para comparar el valor de cada
cronmetro con el tiempo actual.

reas de Problemas
Lo ideal es que la RPC sea transparente.
El programador no debe poder decir si los procedimientos de biblioteca son locales o
remotos:
El programador debe poder escribir procedimientos sin importar si sern ejecutados
en forma local o remota.
La introduccin de RPC en un sistema que se ejecutaba antes en una nica CPU no
debe ir acompaada de una serie de reglas que prohban construcciones antes
vlidas, o exijan construcciones que antes eran opcionales.
La mayora de los S.O. distribuidos no cumplen totalmente esos criterios de transparencia.

Uno de los problemas es el de las variables globales; no se puede implantar el permiso para
el acceso irrestricto de los procedimientos locales a las variables globales remotas y
viceversa, la prohibicin del acceso irrestricto mencionado viola el principio de
transparencia.
Un problema adicional consiste en que no siempre es posible deducir los tipos de los
parmetros:
Ni siquiera a partir de una especificacin formal del propio cdigo, en especial
considerando C.
La exclusin de C cuando se utilice RPC violara la transparencia.

14.4 Comunicacin en Grupo

Una hiptesis subyacente e intrnseca de RPC es que la comunicacin slo es entre dos
partes: el cliente y el servidor.
A veces existen circunstancias en las que la comunicacin es entre varios procesos y no
slo dos:
Ej.: un grupo de servidores de archivo que cooperan para ofrecer un nico servicio
de archivos tolerante a fallos:
o Sera recomendable que un cliente enve el mensaje a todos los servidores
para garantizar la ejecucin de la solicitud aunque alguno falle.
RPC no puede controlar la comunicacin de un servidor con muchos receptores, a
menos que realice RPC con cada uno en forma individual.

Un grupo es una coleccin de procesos que actan juntos en cierto sistema o alguna forma
determinada por el usuario.
La propiedad fundamental de todos los grupos es que cuando un mensaje se enva al propio
grupo, todos los miembros del grupo lo reciben.

Se trata de una comunicacin uno - muchos (un emisor, muchos receptores), que se
distingue de la comunicacin puntual o punto a punto (un emisor, un receptor).
Los grupos son dinmicos:
Se pueden crear y destruir.
Un proceso se puede unir a un grupo o dejar a otro.
Un proceso puede ser miembro de varios grupos a la vez.
La implantacin de la comunicacin en grupo depende en gran medida del hardware:
En ciertas redes es posible crear una direccin especial de red a la que pueden
escuchar varias mquinas:
o Cuando se enva un mensaje a una de esas direcciones se lo entrega
automticamente a todas las mquinas que escuchan a esa direccin.
o Esta tcnica se denomina multitransmisin.
o Cada grupo debe tener una direccin de multitransmisin distinta.
Las redes que no soportan multitransmisin operan con transmisin simple:
Significa que los paquetes que tienen cierta direccin se entregan a todas las
mquinas.
Se puede utilizar para implantar los grupos, pero es menos eficiente que la
multitransmisin.
Cada mquina debe verificar, mediante su software, si el paquete va dirigido a ella:
o En caso negativo se descarta, pero para analizarlo se gener una interrupcin
y se dedic ciclos de CPU.
Otra solucin es implantar la comunicacin en grupo mediante la transmisin por parte del
emisor de paquetes individuales a cada uno de los miembros del grupo:
En vez de un paquete se precisan n paquetes.
Es menos eficiente que las soluciones anteriores.
Es una solucin valida particularmente con grupos pequeos.
El envo de un mensaje de un emisor a un nico receptor se llama unitransmisin.
En la comunicacin en grupo tambin se presentan posibilidades tales como:
Almacenamiento en buffers vs. el no almacenamiento.
Bloqueo vs. no bloqueo.
Grupos Cerrados Vs. Grupos Abiertos
En los grupos cerrados:
Solo los miembros del grupo pueden enviar hacia el grupo.
Los extraos no pueden enviar mensajes al grupo como un todo, pero pueden enviar
mensajes a miembros del grupo en lo individual.
En los grupos abiertos:
Cualquier proceso del sistema puede enviar a cualquier grupo.
Cuando la idea de grupo pretende soportar servidores duplicados:

Es importante que los procesos que no sean miembros (clientes) puedan enviar
hacia el grupo.
Podra ser necesario que los miembros del grupo utilizaran la comunicacin en
grupo.

En algunos grupos todos los procesos son iguales:

No existe distincin de jerarquas.
Son los grupos de compaeros.
En otros grupos existe cierto tipo de jerarqua:
Son los grupos jerrquicos. Ej.: un proceso es el coordinador y todos los dems son
los trabajadores.
Una solicitud de un trabajo que se genere en un cliente externo o en uno de los
procesos trabajadores:
o Se enva al coordinador.
o El coordinador decide cul de los trabajadores es el ms adecuado para
llevarla a cabo y se la enva.
Cada tipo de grupo tiene sus ventajas y desventajas:
Respecto del grupo de compaeros:
o Es simtrico y no tiene un punto de fallo.
o Si uno de los procesos falla, el grupo se reduce pero puede continuar.
o Para tomar decisiones grupales se producen retrasos debidos a la
comunicacin entre los miembros del grupo.
Respecto del grupo jerrquico:
o La prdida del coordinador lleva al grupo a un alto total, lo que es una
desventaja.
o En condiciones normales, el coordinador funciona correctamente y toma
decisiones sin molestar a los dems procesos.

La comunicacin en grupo requiere cierto mtodo para:

Creacin y eliminacin de grupos.
Unin y separacin de procesos a grupos.
Una posibilidad es tener un servidor de grupos al cual enviar todas las solicitudes: es un
mtodo directo, eficiente y fcil de implementar. La desventaja es el punto de fallo que
representa la administracin centralizada de los grupos.
Otra posibilidad es la administracin distribuida de las membresas a grupos: en un grupo
abierto, un proceso extrao puede enviar un mensaje a los integrantes del grupo para
anunciar su presencia.
En un grupo cerrado se precisa algo similar, ya que se debe contemplar la admisin de
nuevos miembros al grupo cerrado.
Al salir de un grupo, el proceso debe comunicarlo a los dems del grupo que deja.

Un aspecto problemtico se presenta cuando un miembro falla, saliendo por lo tanto del
grupo:
No hay un anuncio apropiado de este hecho.
Los dems miembros del grupo lo deben descubrir de forma experimental; luego se
lo puede eliminar del grupo.
Otro aspecto importante es que la entrada y salida al grupo debe sincronizarse con el envo
de mensajes:
Un proceso que se uni a un grupo debe recibir todos los mensajes que se enven al
mismo.
Un proceso que ha salido de un grupo:
o No debe recibir ms mensajes del grupo.
o El grupo no debe recibir ms mensajes del proceso.
o Los otros miembros no deben recibir ms mensajes del proceso saliente.
Una forma de garantizar que una entrada o salida se integra al flujo de mensajes en
el lugar correcto es convertir esta operacin en un mensaje a todo el grupo.
Un aspecto crtico resulta cuando fallan tantas mquinas que el grupo ya no puede
funcionar:
Se necesita cierto protocolo para reconstruir el grupo.
Alguno de los procesos deber tomar la iniciativa.
El protocolo deber resolver la situacin que se presenta cuando dos o ms procesos
intentan al mismo tiempo reconstruir el grupo.

Direccionamiento al Grupo
Los grupos deben poder direccionarse, al igual que los procesos.
Una forma es darle a cada grupo una direccin nica, similar a una direccin de proceso.
Si la red soporta multitransmisin:
La direccin del grupo se puede asociar con una direccin de multitransmisin.
Cada mensaje enviado a la direccin del grupo se podr multitransmitir.
Si la red no soporta multitransmisin:
Se tendr que utilizar transmisin simple.
Cada ncleo lo recibir y extraer la direccin del grupo.
Si ninguno de los procesos en la mquina es un miembro del grupo, se descarta la
transmisin.
En caso contrario se transfiere a todos los miembros del grupo.
Si la red no soporta multitransmisin ni transmisin simple:
Se tendr que utilizar unitransmisin.
El ncleo de la mquina emisora deber contar con una lista de las mquinas que
tienen procesos pertenecientes al grupo.
Deber enviar a cada mquina un mensaje puntual.

Un segundo mtodo de direccionamiento de grupo consiste en pedirle al emisor una lista

explcita de todos los destinos.
Un tercer mtodo es el de direccionamiento de predicados.
Atomicidad
La mayora de los sistemas de comunicacin en grupo estn diseados para que
los mensajes enviados al grupo lleguen correctamente a todos los miembros o a ninguno de
ellos:
Esta propiedad de todo o nada en la entrega se llama atomicidad o transmisin
atmica.
Facilita la programacin de los sistemas distribuidos.
Es de gran importancia para garantizar la consistencia de las bases de datos y de los
archivos distribuidos y duplicados.
La nica forma de garantizar que cada destino recibe todos sus mensajes es pedirle que
enve de regreso un reconocimiento despus de recibir el mensaje:
Esto funciona si las mquinas no fallan.
Si fallan:
o Algunos miembros del grupo habrn recibido el mensaje y otros no; esto es
inaceptable.
o Los miembros que no recibieron el mensaje ni siquiera saben que les falta
algo, por lo que no pedirn una retransmisin; adems, si pudieran detectar
el faltante pero fallara el emisor, no podrn recibir el mensaje.
Una solucin puede llegar del algoritmo de Joseph y Birman, este algoritmo asegura que
todos los procesos sobrevivientes obtendrn el mensaje, independientemente del nmero de
mquinas que fallen o el nmero de paquetes perdidos.
Ordenamiento de Mensajes
El ordenamiento de los mensajes es un aspecto fundamental en la comunicacin en grupo.
El problema es que cuando dos procesos contienden por el acceso a una LAN, el orden de
envo de los mensajes no es determinista.
Un sistema debe tener una semntica bien definida con respecto al orden de entrega de los
mensajes.
La mejor garanta es la entrega inmediata de todos los mensajes, en el orden en que fueron
enviados:
Todos los mensajes destinados a un grupo deben entregarse antes de comenzar a
entregar la siguiente serie de mensajes.
Todos los receptores reciben todos los mensajes en el mismo orden.
Es esquema se denomina ordenamiento con respecto al tiempo global.
Una variante al esquema anterior es el ordenamiento consistente:
Si dos mensajes a y b se envan muy cercanos en el tiempo, el sistema:

Elige uno de ellos como el primero.

Lo enva a todos los miembros del grupo.
Luego enva el otro mensaje.
Se garantiza que los mensajes lleguen a todos los miembros del grupo en el mismo
orden:
o Dicho orden podra no ser aquel con el que fueron enviados.
o
o
o

14. 5 Redes ATM

El modelo de referencia OSI fue discutido y consensuado por empresas pblicas y privadas
de telecomunicaciones en los aos setenta y fue implementado en parte en los ochenta.
Los aos noventa han alumbrado nuevos desarrollos tecnolgicos en los niveles inferiores
de la pila de protocolos OSI. Uno de ellos es ATM.
En los ltimos veinticinco aos, los computadores han experimentado avances en
prestaciones de muchos rdenes de magnitud. Las redes no.
Arpanet, la red precursora de Internet entr en funcionamiento en 1969 con lneas punto a
punto de 56 Kbytes/s. Hoy todava los usuarios finales de Internet se comunican a estas
velocidades. Los nuevos desarrollos de los noventa proponen estndares que
repentinamente saltan a velocidades de 155 Mbytes/s para el usuario final y a 1 Gbyte/s
para el tronco principal de Internet.
Qu es el modo de transferencia asncrono?
A finales de los aos ochenta las compaas de telecomunicaciones de todo el mundo
comenzaron a darse cuenta de que las telecomunicaciones eran algo ms que transmitir la
voz humana en una banda de cuatro Khz. Entonces ya haca tiempo que existan las redes
de datos, como X.25, pero eran an inmaduras y operaban a un mximo de 56 Kb/s o 64
Kb/s. Sistemas como la red Internet no pasaban de ser curiosidades acadmicas.
Cuando estas compaas decidieron construir redes para el siglo 21, se encontraron con un
dilema. Por una parte, la voz requiere un ancho de banda muy bajo, pero constante. Por la
otra, los datos de los computadores no aparecen en las lneas de comunicacin de una forma
predecible y con una tasa constante. Al contrario, son de naturaleza explosiva.
Repentinamente surge una corriente a la que es preciso asignar un canal del mayor ancho
de banda posible. Cuando la comunicacin acaba, el ancho de banda que se precisa es nulo.
En conclusin, ni la red telefnica de conmutacin de circuitos es apropiada para transmitir
datos ni las redes de datos de conmutacin de paquetes son apropiadas para trasmitir la voz.
El compromiso ms razonable para atender ambos tipos de trfico es el modelo hbrido
ATM.
ATM requiere que sea establecido un circuito virtual antes de establecer la comunicacin
entre el emisor y el receptor o los receptores de la comunicacin. Durante el
establecimiento de la conexin, la informacin del encaminamiento se almacena en los
nodos de conmutacin ATM que definen la misma. Los paquetes de los protocolos de
nivel superior son enviados a la tarjeta o adaptador ATM de la mquina donde corre el

proceso de usuario, que los trocea en unidades pequeas de tamao fijo denominadas
celdas. Las celdas de una conexin siguen la secuencia de nodos que se estableci al
crearla. Cuando sta termina, la informacin relativa a la conexin es eliminada de los
nodos de conmutacin.
Ventajas
La principal es que ahora una nica red es capaz de transportar voz, datos, radio, televisin
por cable, vdeo, etc., reemplazando a la red de antenas y repetidores de radio y televisin,
la maraa de cables de la red telefnica, el nuevo cableado de la televisin por cable, el
cableado de las redes de datos, etc.
Adems, permite la aparicin de nuevos servicios como las videoconferencias, que son
accesibles desde todos los hogares con un nico cable. En todos los casos, los nodos
intermedios de la conexin ven slo celdas, el contenido poco importa excepto al extremo
final.
El hecho de que las celdas sean de tamao fijo hace que la conmutacin sea mucho ms
rpida, sin necesidad de que sean almacenadas en disco duro como los paquetes de la red
Internet.
El segundo factor que incrementa la velocidad es que los conmutadores ATM no realizan
control de flujo ni comprobacin de errores en las celdas.
ATM opera estableciendo circuitos virtuales, pero un circuito slo es establecido si estn
disponibles los recursos suficientes para garantizar la calidad del servicio solicitado. ATM
tiene su propia pila de protocolo.

El nivel fsico
Una tarjeta adaptadora ATM se encarga de poner en el cable, sea de cobre o fibra ptica,
una corriente continua de celdas. Cuando no hay nada que transmitir, se envan celdas
vacas.

A este modo de transmisin se le llama modo nativo ATM y logra velocidades de

transmisin superiores al Gigabit/s con fibra ptica.
Alternativamente, las celdas ATM pueden ser enviadas como datos convencionales en los
marcos de la red de servicios integrados de banda ancha, B-ISDN. Con este mtodo,
definido en el estndar CCITT I.150, se alcanza una velocidad de transmisin de 155
Mbits/s o 622 Mbits/s.
El nivel ATM
Este es el nivel que define el formato de las clulas y el protocolo orientado a conexin que
las transmite.
Cuando se discutan las propuestas, los comits europeos y norteamericanos estaban
enfrentados. Los americanos disponan de lneas de mayor calidad, con supresores de eco,
lo que les permita celdas ms grandes, de 64 bytes. Los europeos no disponan de este tipo
de lneas, de modo que celdas de 32 eran las ms adecuadas.
Se lleg a un compromiso de celdas de 48 bytes. Una celda de 48 bytes es demasiado
grande para transmisin de voz y demasiado pequea para transmisin de datos. Y peor
an, a la celda se le aadi un cabecero de 5 bytes.
En cada conmutador existe una tabla de encaminamiento que se establece cuando se crea la
conexin. Cuando una celda llega a un conmutador, se examinan los campos VCI y VPI y
la celda sale por el puerto correspondiente. Por lo tanto, los campos VCI y VPI de una
celda se modifican cada vez que esta atraviesa un conmutador.
El campo CLP significa prioridad en la prdida de celdas y puede utilizarse para distinguir
entre unas celdas ms importantes que otras en funcin de su contenido.
En caso de congestin en un conmutador, este puede descartar las celdas menos
importantes.
El campo tipo de datos distingue entre celdas de datos y celdas de control y distingue entre
varios tipos de celdas de control.
El campo CRC es una comprobacin sobre la cabecera completa (no los datos).
Los nodos de una red ATM son de tres tipos:
1. Hosts, que envan y reciben mensajes.
2. Conmutadores de rutas virtuales, que mantienen las tablas de conmutacin de rutas
virtuales.
3. Conmutadores de canales y rutas virtuales, que mantienen tablas de conmutacin de
canales y de rutas.
ATM proporciona un servicio de baja latencia. El retardo que introduce un conmutador es
de alrededor de 25 microsegundos. Una ruta transcontinental de 10 conmutadores introduce

un retraso de 250 microsegundos, un cuarto de milisegundo, en cada celda que atraviesa los
diez conmutadores.
Esto significa que la comunicacin cliente servidor tendra las mismas prestaciones que si
se hiciese en un red de rea local en un contexto de rea ancha ATM.
El nivel de adaptacin ATM
Una celda ATM tiene 53 bytes o 53x8=424 bits. A una velocidad de transmisin de 155
Mbps, 424 bits se transmiten en 424/(155x106)=2.74 microsegundos. Pocas UCP pueden
soportar interrupciones de sus adaptadores de red a una tasa de 2.74 s, lo que impone en el
adaptador un mecanismo para ensamblar las celdas entrantes en que se reparte el mensaje
de usuario.
Este mecanismo es el que trocea el mensaje en las celdas que salen al cable. Estos
procedimientos de ensamblado y desensamblado constituyen el nivel de adaptacin ATM.
Estn implementados en el adaptador de red y provocan una interrupcin por paquete y no
por celda.
Una propuesta del nivel de adaptacin es SEAL, que significa Nivel de Adaptacin Simple
y Eficiente. Por su nombre, fcilmente puede adivinarse lo que pensaron sus creadores de
las propuestas anteriores. SEAL utiliza un bit del campo de tipo de datos de la celda. Este
bit es normalmente cero, pero es uno en la ltima celda de un paquete.

El modelo de referencia ATM

Est formado de las siguientes capas:

Capa fsica: Similar a la capa fsica del OSI, sta maneja la transmisin dependiente del
medio.
Capa ATM: Combinada con la capa de adaptacin ATM, es similar a la capa de enlace de

datos del OSI. Es la responsable para establecer conexiones y pasar celdas a travs de la red
ATM.
Capa de adaptacin ATM (AAL): Realiza la funcin de preparar la informacin segn sus
requerimientos antes de que sta pase a la capa ATM, en donde se construyen las celdas.
Finalmente las capas ms altas que residen en la parte superior de AAL aceptan datos de
usuarios, los arreglan en paquetes, y los entregan al AAL.

Conexiones ATM
Soporta dos tipos de conexiones:
Punto a punto:
Conecta dos puntos finales ATM y pueden ser unidireccional y
bidireccional.
Punto a multipunto:
Conecta un punto final simple (conocido como root) a un conjunto de puntos
finales. (Conocidos como leaves).
Estas conexiones solamente son unidireccionales.
Establecimiento y sealizacin ATM
Cuando un dispositivo ATM quiere establecer una conexin con otro, ste enva un paquete
de peticin de sealizacin a su switch ATM. El paquete contiene la direccin del endpoint
deseado, as como tambin algunos parmetros de QoS.
Los protocolos de enlace ATM varan de acuerdo al tipo de enlace que se est manejando,
los cuales pueden ser seales UNI o NNI. UNI es usado entre un sistema final ATM y un
switch ATM a travs del ATM UNI. NNI es utilizado a travs de enlaces NNI.
Proceso de establecimiento de conexin
Se utiliza el mtodo conocido como one-pass. Como funciona?:
Primero el sistema final fuente enva una peticin de sealizacin de
conexin.
Esta peticin es propagada por la red.
Las conexiones son establecidas por la red.
La peticin alcanza el sistema final destino el cual responda si acepta o
rechaza la peticin.
Mensajes de conexin
Una gran cantidad de tipos de mensajes de manejo de conexin son utilizados en el proceso
de establecimiento de conexin.
SETUP. Enviado por el sistema final fuente.
Call Proceeding. Enviado por el switch hacia la red en respuesta al mensaje SETUP.

(Ingress switch)
Connect message. Enviado por el sistema final destino si la conexin es aceptada.
Release message. Si la conexin es rechazada.
Bibliografa
[1] Dr. David Luis la Red Martnez - Sistemas Operativos UNNE - Facultad De Ciencias
Exactas Y
Naturales
Y
Agrimensura
http://exa.unne.edu.ar/depar/areas/informatica/SistemasOperativos/SO8.htm#Inicio
[2] Cabello, Daz y Martnez. Sistemas Operativos, Teora y Prctica. Madrid: Daz de

Santos.
[3] Flynn, Ida y Mclver, Ann. Sistemas Operativos (3a ed.). Mxico: Thomson.
[4] Rojo, Oscar. (2003). Introduccin a los sistemas distribuidos. http://www.augcyl.org/
[5] Tanenbaum, Andrew. Sistemas Operativos Distribuidos. Mexico: Prentice Hall.
[6] Morera Pascual, Juan y Perez-Campanero, Juan. (2002). Conceptos de Sistemas

Operativos.