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 En una LAN, el emisor puede transmitir un paquete especial de

localizacin con la direccin del proceso destino.

o Este paquete de transmisin ser recibido por todas las mquinas de la red.

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

o 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 a las

de recepcin como receive y ambas pueden ser con bloqueo o sin bloqueo.

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:

o Elige uno de ellos como el primero. o Lo enva a todos los miembros del grupo.

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

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.