Tutorial Sistemas Distribuidos

Sistemas Distribuidos. Introduccin Y Generalidades.
Un sistema distribuido es una coleccin de computadoras independientes que aparecen ante los usuarios del sistema como una nica computadora (Tenenbaum Sistemas Operativos Distribuidos). Sistemas cuyos componentes hardware y software, que estn en computadoras conectadas en red, se comunican y coordinan sus acciones mediante el paso de mensajes, para el logro de un objetivo. Se establece la comunicacin mediante un protocolo prefijado por un esquema cliente-servidor. En la definicin de Tenenbaum hay dos aspectos importantes. El primero se refiere al hardware las mquinas son autnomas. El segundo se refiere al software, los usuarios piensan que el sistema es como una nica computadora. OBJETIVO. El objetivo principal es reducir el costo de inversin en cuanto a la implementacin de sistemas costosos, y su tarea principal es la resolucin de un problema en diferentes proporciones, la tarea la dividen en varias partes y cada mquina se encarga de resolver la tarea que le corresponde para luego unirlas todas despus de terminadas y regresadas a su lugar de origen esto es ms que nada cumplir la peticin del cliente. CARACTERISTICAS. Concurrencia.- Esta caracterstica de los sistemas distribuidos permite que los recursos disponibles en la red puedan ser utilizados simultneamente por los usuarios y/o agentes que interactan en la red. Carencia de reloj global.- Las coordinaciones para la transferencia de mensajes entre los diferentes componentes para la realizacin de una tarea, no tienen una temporizacin general, est ms bien distribuida a los componentes. Fallos independientes de los componentes.- Cada componente del sistema puede fallar independientemente, con lo cual los dems pueden continuar ejecutando sus acciones. Esto permite el logro de las tareas con mayor efectividad, pues el sistema en su conjunto continua trabajando. Cada elemento de cmputo tiene su propia memoria y su propio Sistema Operativo. Control de recursos locales y remotos.
TUTORIAL DE SISTEMAS DISTRIBUIDOS.

Sistemas Abiertos (Facilidades de cambio y crecimiento). Plataforma no standard (Unix, NT, Intel, RISC, Etc.). Medios de comunicacin (Redes, Protocolos, Dispositivos, Etc.). Capacidad de Procesamiento en paralelo. Dispersin y parcialidad. Los sistemas distribuidos constan de CPU (Unidad Central De Proceso) autnomos que funcionan juntos para que todo el sistema parezca como una sola computadora. Tienen varios puntos favorables potenciales como, buena proporcin precio/desempeo, se pueden ajustar bien a las aplicaciones distribuidas, pueden ser muy confiables y pueden aumentar su tamao de manera gradual al aumentar la carga de trabajo. VENTAJAS DE LOS SISTEMAS DISTRIBUIDOS. Procesadores ms poderosos y a menos costos. o Desarrollo de estaciones con ms capacidad. o Las estaciones satisfacen las necesidades de los usuarios. o Usos de nuevas interfaces. Avances en las tecnologas de comunicacin. o Disponibilidad de elementos de comunicacin. o Desarrollo de nuevas tcnicas. Comparticin de recursos. o Dispositivos (Hardware). o Programas (Software). Eficiencia y flexibilidad. o Respuesta rpida. o Ejecucin concurrente de proceso (en varias computadoras). o Empleo de tcnicas de procesamiento distribuido. Disponibilidad y confiabilidad. o Sistema poco propenso a fallas. o Mayores servicios que elevan la funcionalidad. Crecimiento modular. o Es inherente al crecimiento. o Inclusin rpida de nuevos recursos. o Los recursos actuales no afectan.
Sistemas Distribuidos Unidad I Y II. .

Con respecto a Sistemas Centralizados: Una de las ventajas de los sistemas distribuidos es la economa, pues es mucho ms barato, aadir servidores y clientes cuando se requiere aumentar la potencia de procesamiento. El trabajo en conjunto. Por ejemplo: en una fbrica de ensamblado, los robots tienen sus CPUs diferentes y realizan acciones en conjunto, dirigidos por un sistema distribuido. Tienen una mayor confiabilidad. Al estar distribuida la carga de trabajo en muchas mquinas la falla de una de ellas no afecta a las dems, el sistema sobrevive como un todo. Capacidad de crecimiento incremental. Se puede aadir procesadores al sistema incrementando su potencia en forma gradual segn sus necesidades. Con respecto a PCs Independientes: Se pueden compartir recursos, como programas y perifricos, muy costosos. Ejemplo: Impresora Lser, dispositivos de almacenamiento masivo, etc. Al compartir recursos, satisfacen las necesidades de muchos usuarios a la vez. Ejemplo: Sistemas de reservas de aerolneas. Se logra una mejor comunicacin entre las personas. Ejemplo: el correo electrnico. Tienen mayor flexibilidad, la carga de trabajo se puede distribuir entre diferentes ordenadores. DESVENTAJAS DE LOS SISTEMAS DISTRIBUIDOS El principal problema es el software, es el diseo, implantacin y uso del software distribuido, pues presenta numerosos inconvenientes. Los principales interrogantes son los siguientes: o Qu tipo de S. O., lenguaje de programacin y aplicaciones son adecuados para estos sistemas? o Cunto deben saber los usuarios de la distribucin? o Qu tanto debe hacer el sistema y qu tanto deben hacer los usuarios?

La respuesta a estos interrogantes no es uniforme entre los especialistas, pues existe una gran diversidad de criterios y de interpretaciones al respecto. Otro problema tiene que ver con las redes de comunicacin. Por ejemplo: Perdida de mensajes, saturacin en el trfico, etc. Un problema que puede surgir al compartir datos es la seguridad de los mismos. En general se considera que las ventajas superan a las desventajas, si estas ltimas se administran seriamente. Requerimiento de mayores controles de procesamiento. Velocidad de propagacin de informacin (Muy lenta a veces). Servicio de replicacin de datos y servicios con posibilidades de fallas. Mayores controles de acceso y proceso (Commit). Administracin ms compleja. Costos. DESAFOS Heterogeneidad de los componentes.- La interconexin, sobre todo cuando se usa Internet, se da sobre una gran variedad de elementos hardware y software, por lo cual necesitan de ciertos estndares que permitan esta comunicacin. Los Middleware, son elementos software que permiten una abstraccin de la programacin y el enmascaramiento de la heterogeneidad subyacente sobre las redes. Tambin el middleware proporciona un modelo computacional uniforme. Extensibilidad.- Determina si el sistema puede extenderse y re implementado en diversos aspectos (aadir y quitar componentes). La integracin de componentes escritos por diferentes programadores es un autentico reto. Seguridad.- Reviste gran importancia por el valor intrnseco para los usuarios. Tiene tres componentes: o Confidencialidad.- Proteccin contra individuos no autorizados. o Integridad.- Proteccin contra la alteracin o corrupcin.

o Disponibilidad.- Proteccin contra la procedimientos de acceso a los recursos. interferencia con los
Escalabilidad.- El sistema es escalable si conserva su efectividad al ocurrir un incremento considerable en el nmero de recursos y en el nmero de usuarios. Tratamiento de Fallos.- La posibilidad que tiene el sistema para seguir funcionando ante fallos de algn componente en forma independiente, pero para esto se tiene que tener alguna alternativa de solucin. Tcnicas para tratar fallos: o Deteccin de fallos. Algunos comprobaciones por ejemplo. fallos son detectables, con
o Enmascaramiento de fallos. Algunos fallos detectados pueden ocultarse o atenuarse. o Tolerancia de fallos. Sobre todo en Internet se dan muchos fallos y no es muy conveniente ocultarlos, es mejor tolerarlos y continuar. Ejemplo: Tiempo de vida de una bsqueda. o Recuperacin frente a fallos. Tras un fallo se deber tener la capacidad de volver a un estado anterior. o Redundancia. Se puede usar para tolerar ciertos fallos (DNS, BD, etc.) Concurrencia. Compartir recursos por parte de los clientes a la vez. Transparencia. Es la ocultacin al usuario y al programador de aplicaciones de la separacin de los componentes en un sistema distribuido. Se identifican 8 formas de transparencia: o De Acceso. Se accede a recursos locales y remotos de forma idntica. o De ubicacin. Permite acceder a los recursos sin conocer su ubicacin. o De concurrencia. Usar un recurso compartido sin interferencia. o De replicacin. Permite utilizar varios ejemplares de cada recurso. o Frente a fallos. Permite ocultar los fallos.

o De movilidad. Permite la reubicacin de recursos y clientes sin afectar al sistema. o De prestaciones. Permite reconfigurar el sistema para mejorar las prestaciones segn su carga. o Al escalado. Permite al sistema y a las aplicaciones expandirse en tamao sin cambiar la estructura del sistema o los algoritmos de aplicacin. APLICACIONES Sistemas Comerciales.- Inicialmente fueron construidos con hardware dedicado y entornos centralizados, son, por sus caractersticas de distribucin geogrfica y necesidad de acceso a sistemas distintos, ideales para implementarse en sistemas distribuidos. Requieren ciertas caractersticas de fiabilidad, seguridad y proteccin. Algunos ejemplos son: o Sistemas de reservas de lneas areas. o Aplicaciones bancarias. o Cajas y gestin de grandes almacenes. Redes WAN.- Debido al gran crecimiento de este tipo de redes (Internet), ha tomado gran importancia el intercambio de informacin a travs de la red. Y para esto tenemos los siguientes ejemplos: o Los servicios comunes que brinda Internet: Correo electrnico, servicio de noticias, transferencia de archivos, la World Wide Web, etc. Aplicaciones Multimedia.- Son las ltimas incorporaciones a los sistemas distribuidos. Estas aplicaciones imponen ciertas necesidades de hardware para poder tener una velocidad y regularidad de transferencia de una gran cantidad de datos. Los ejemplos de estos sistemas son: o Videoconferencia. o Televigilancia. o Juegos multiusuario. o Enseanza asistida por ordenador.

reas de la informtica aplicada a los Sistemas Distribuidos.- En este punto se tienen en cuenta toda la variedad de aplicaciones de los sistemas distribuidos, pues su diseo involucra a muchas reas, por ejemplo: o Comunicaciones. o Sistemas operativos distribuidos. o Base de datos distribuidas. o Servidores distribuidos de ficheros. o Lenguajes de programacin distribuidos. o Sistemas de tolerancia de fallos. CONCLUSIONES Los sistemas distribuidos abarcan una cantidad de aspectos considerables, por lo cual su desarrollo implica mucha complejidad. Existen ciertos aspectos que requieren extremo cuidado al desarrollarse e implantarse como el manejo de fallos, el control de la concurrencia, etc. Existen muchos temas de investigacin relacionados con los sistemas distribuidos, por ejemplo los planteados en el apartado de Desafos. Se nota tambin que muchas tecnologas estn en constante desarrollo y maduracin, lo cual implica un minucioso estudio previo de muchos factores antes de apostar por alguna tecnologa en especial.
ARQUITECTURAS DE NIVELES DE INTERMEDIOS (MIDDLEWARE) DE COMUNICACIONES TCP/IP. Antes de ver lo que es el middleware haremos referencia hacia el protocolo TCP/IP con la siguiente informacin: PROTOCOLO TCP/IP. HISTORIA El Protocolo de Internet (IP) y el Protocolo de Transmisin (TCP), fueron desarrollados inicialmente en 1973 por el informtico estadounidense Vinton Cerf como parte de un proyecto dirigido por el ingeniero norteamericano Robert Kahn y patrocinado por la Agencia de Programas Avanzados de Investigacin (ARPA, siglas en ingls) del Departamento Estadounidense de Defensa. Internet comenz

siendo una red informtica de ARPA (llamada ARPAnet) que conectaba redes de ordenadores de varias universidades y laboratorios en investigacin en Estados Unidos. World Wibe Web se desarroll en 1989 por el informtico britnico Timothy Berners-Lee para el Consejo Europeo de Investigacin Nuclear (CERN, siglas en francs). QU ES Y SU ARQUITECTURA TCP/IP es el protocolo comn utilizado por todos los ordenadores conectados a Internet, de manera que stos puedan comunicarse entre s. Hay que tener en cuenta que en Internet se encuentran conectados ordenadores de clases muy diferentes y con hardware y software incompatibles en muchos casos, adems de todos los medios y formas posibles de conexin. Aqu se encuentra una de las grandes ventajas del TCP/IP, pues este protocolo se encargar de que la comunicacin entre todos sea posible. TCP/IP es compatible con cualquier sistema operativo y con cualquier tipo de hardware. TCP/IP no es un nico protocolo, sino que es en realidad lo que se conoce con este nombre es un conjunto de protocolos que cubren los distintos niveles del modelo OSI. Los dos protocolos ms importantes son el TCP (Transmission Control Protocol) y el IP (Internet Protocol), que son los que dan nombre al conjunto. La arquitectura del TCP/IP consta de cinco niveles o capas en las que se agrupan los protocolos, y que se relacionan con los niveles OSI de la siguiente manera: Aplicacin: Se corresponde con los niveles OSI de aplicacin, presentacin y sesin. Aqu se incluyen protocolos destinados a proporcionar servicios, tales como correo electrnico (SMTP), transferencia de ficheros (FTP), conexin remota (TELNET) y otros ms recientes como el protocolo HTTP (Hypertext Transfer Protocol). Transporte: Coincide con el nivel de transporte del modelo OSI. Los protocolos de este nivel, tales como TCP y UDP, se encargan de manejar los datos y proporcionar la fiabilidad necesaria en el transporte de los mismos. Internet: Es el nivel de red del modelo OSI. Incluye al protocolo IP, que se encarga de enviar los paquetes de informacin a sus destinos correspondientes. Es utilizado con esta finalidad por los protocolos del nivel de transporte. Fsico: Anlogo al nivel fsico del OSI. Red: Es la interfaz de la red real. TCP/IP no especifica ningn protocolo concreto, as es que corre por las interfaces conocidas, como por ejemplo: 802.2, CSMA/CD, X.25, etc.
NIVEL DE APLICACIN NIVEL DE TRANSPORTE NIVEL DE INTERNET NIVEL DE RED NIVEL FSICO Arquitectura TCP/IP El TCP/IP necesita funcionar sobre algn tipo de red o de medio fsico que proporcione sus propios protocolos para el nivel de enlace de Internet. Por este motivo hay que tener en cuenta que los protocolos utilizados en este nivel pueden ser muy diversos y no forman parte del conjunto TCP/IP. Sin embargo, esto no debe ser problemtico puesto que una de las funciones y ventajas principales del TCP/IP es proporcionar una abstraccin del medio de forma que sea posible el intercambio de informacin entre medios diferentes y tecnologas que inicialmente son incompatibles. Para transmitir informacin a travs de TCP/IP, sta debe ser dividida en unidades de menor tamao. Esto proporciona grandes ventajas en el manejo de los datos que se transfieren y, por otro lado, esto es algo comn en cualquier protocolo de comunicaciones. En TCP/IP cada una de estas unidades de informacin recibe el nombre de "datagrama" (datagram), y son conjuntos de datos que se envan como mensajes independientes. PROTOCOLOS TCP/IP FTP, SMTP, TELNET TCP IP, ICMP, 802.2, X.25 ETHERNET, IEEE 802.2, X.25 FTP (File Transfer Protocol). Se utiliza para transferencia de archivos. SMTP (Simple Mail Transfer Protocol). Es una aplicacin para el correo electrnico. TELNET: Permite la conexin a una aplicacin remota desde un proceso o terminal. SNMP, X-WINDOWS, RPC, NFS UDP

RPC (Remote Procedure Call). Permite llamadas a procedimientos situados remotamente. Se utilizan las llamadas a RPC como si fuesen procedimientos locales. SNMP (Simple Network Management Protocol). Se trata de una aplicacin para el control de la red. NFS (Network File System). Permite la utilizacin de archivos distribuidos por los programas de la red. X-Windows. Es un protocolo para el manejo de ventanas e interfaces de usuario.
CARACTERSTICAS DE TCP/IP Ya que dentro de un sistema TCP/IP los datos transmitidos se dividen en pequeos paquetes, stos resaltan una serie de caractersticas. La tarea de IP es llevar los datos a granel (los paquetes) de un sitio a otro. Las computadoras que encuentran las vas para llevar los datos de una red a otra (denominadas enrutadores) utilizan IP para trasladar los datos. En resumen IP mueve los paquetes de datos a granel, mientras TCP se encarga del flujo y asegura que los datos estn correctos. Las lneas de comunicacin se pueden compartir entre varios usuarios. Cualquier tipo de paquete puede transmitirse al mismo tiempo, y se ordenar y combinar cuando llegue a su destino. Compare esto con la manera en que se transmite una conversacin telefnica. Una vez que establece una conexin, se reservan algunos circuitos para usted, que no puede emplear en otra llamada, aun si deja esperando a su interlocutor por veinte minutos. Los datos no tienen que enviarse directamente entre dos computadoras. Cada paquete pasa de computadora en computadora hasta llegar a su destino. ste, claro est, es el secreto de cmo se pueden enviar datos y mensajes entre dos computadoras aunque no estn conectadas directamente entre s. Lo que realmente sorprende es que slo se necesitan algunos segundos para enviar un archivo de buen tamao de una mquina a otra, aunque estn separadas por miles de kilmetros y pese a que los datos tienen que pasar por mltiples computadoras. Una de las razones de la rapidez es que, cuando algo anda mal, slo es necesario volver a transmitir un paquete, no todo el mensaje. Los paquetes no necesitan seguir la misma trayectoria. La red puede llevar cada paquete de un lugar a otro y usar la conexin ms idnea que est disponible en ese instante. No todos los paquetes de los mensajes tienen que viajar, necesariamente, por la misma ruta, ni necesariamente tienen que llegar todos al mismo tiempo.

La flexibilidad del sistema lo hace muy confiable. Si un enlace se pierde, el sistema usa otro. Cuando usted enva un mensaje, el TCP divide los datos en paquetes, ordena stos en secuencia, agrega cierta informacin para control de errores y despus los lanza hacia fuera, y los distribuye. En el otro extremo, el TCP recibe los paquetes, verifica si hay errores y los vuelve a combinar para convertirlos en los datos originales. De haber error en algn punto, el programa TCP destino enva un mensaje solicitando que se vuelvan a enviar determinados paquetes.
CMO FUNCIONA - IP: IP a diferencia del protocolo X.25, que est orientado a conexin, es sin conexin. Est basado en la idea de los datagramas interred, los cuales son transportados transparentemente, pero no siempre con seguridad, desde el hostal fuente hasta el hostal destinatario, quizs recorriendo varias redes mientras viaja. El protocolo IP trabaja de la siguiente manera; la capa de transporte toma los mensajes y los divide en datagramas, de hasta 64K octetos cada uno. Cada datagrama se transmite a travs de la red interred, posiblemente fragmentndose en unidades ms pequeas, durante su recorrido normal. Al final, cuando todas las piezas llegan a la mquina destinataria, la capa de transporte los reensambla para as reconstruir el mensaje original. Un datagrama IP consta de una parte de cabecera y una parte de texto. La cabecera tiene una parte fija de 20 octetos y una parte opcional de longitud variable. El campo Versin indica a qu versin del protocolo pertenece cada uno de los datagramas. Mediante la inclusin de la versin en cada datagrama, no se excluye la posibilidad de modificar los protocolos mientras la red se encuentre en operacin. El campo Opciones se utiliza para fines de seguridad, encaminamiento fuente, informe de errores, depuracin, sellado de tiempo, as como otro tipo de informacin. Esto, bsicamente, proporciona un escape para permitir que las versiones subsiguientes de los protocolos incluyan informacin que actualmente no est presente en el diseo original. Tambin, para permitir que los experimentadores trabajen con nuevas ideas y para evitar, la asignacin de bits de cabecera a informacin que muy rara vez se necesita. Debido a que la longitud de la cabecera no es constante, un campo de la cabecera, IHL, permite que se indique la longitud que tiene la cabecera en palabras de 32 bits. El valor mnimo es de 5. Tamao 4 bit. El campo Tipo de servicio le permite al hostal indicarle a la subred el tipo de servicio que desea. Es posible tener varias combinaciones con respecto a la

seguridad y la velocidad. Para voz digitalizada, por ejemplo, es ms importante la entrega rpida que corregir errores de transmisin. En tanto que, para la transferencia de archivos, resulta ms importante tener la transmisin fiable que entrega rpida. Tambin, es posible tener algunas otras combinaciones, desde un trfico rutinario, hasta una anulacin instantnea. Tamao 8 bit. La Longitud total incluye todo lo que se encuentra en el datagrama -tanto la cabecera como los datos. La mxima longitud es de 65 536 octetos (bytes). Tamao 16 bit. El campo Identificacin se necesita para permitir que el hostal destinatario determine a qu datagrama pertenece el fragmento recin llegado. Todos los fragmentos de un datagrama contienen el mismo valor de identificacin. Tamao 16 bits. Enseguida viene un bit que no se utiliza, y despus dos campos de 1 bit. Las letras DF quieren decir no fragmentar. Esta es una orden para que las pasarelas no fragmenten el datagrama, porque el extremo destinatario es incapaz de poner las partes juntas nuevamente. Por ejemplo, supngase que se tiene un datagrama que se carga en un micro pequeo para su ejecucin; podra marcarse con DF porque la ROM de micro espera el programa completo en un datagrama. Si el datagrama no puede pasarse a travs de una red, se deber encaminar sobre otra red, o bien, desecharse. Las letras MF significan ms fragmentos. Todos los fragmentos, con excepcin del ltimo, debern tener ese bit puesto. Se utiliza como una verificacin doble contra el campo de Longitud total, con objeto de tener seguridad de que no faltan fragmentos y que el datagrama entero se reensamble por completo. El desplazamiento de fragmento indica el lugar del datagrama actual al cual pertenece este fragmento. En un datagrama, todos los fragmentos, con excepcin del ltimo, debern ser un mltiplo de 8 octetos, que es la unidad elemental de fragmentacin. Dado que se proporcionan 13 bits, hay un mximo de 8192 fragmentos por datagrama, dando as una longitud mxima de datagrama de 65 536 octetos, que coinciden con el campo Longitud total. Tamao 16 bits. El campo Tiempo de vida es un contador que se utiliza para limitar el tiempo de vida de los paquetes. Cuando se llega a cero, el paquete se destruye. La unidad de tiempo es el segundo, permitindose un tiempo de vida mximo de 255 segundos. Tamao 8 bits. Cuando la capa de red ha terminado de ensamblar un datagrama completo, necesitar saber qu hacer con l. El campo Protocolo indica, a qu proceso de transporte pertenece el datagrama. El TCP es efectivamente una posibilidad, pero en realidad hay muchas ms.

Protocolo: El nmero utilizado en este campo sirve para indicar a qu protocolo pertenece el datagrama que se encuentra a continuacin de la cabecera IP, de manera que pueda ser tratado correctamente cuando llegue a su destino. Tamao: 8 bit. El cdigo de redundancia de la cabecera es necesario para verificar que los datos contenidos en la cabecera IP son correctos. Por razones de eficiencia este campo no puede utilizarse para comprobar los datos incluidos a continuacin, sino que estos datos de usuario se comprobarn posteriormente a partir del cdigo de redundancia de la cabecera siguiente, y que corresponde al nivel de transporte. Este campo debe calcularse de nuevo cuando cambia alguna opcin de la cabecera, como puede ser el tiempo de vida. Tamao: 16 bit La Direccin de origen contiene la direccin del host que enva el paquete. Tamao: 32 bit. La Direccin de destino: Esta direccin es la del host que recibir la informacin. Los routers o gateways intermedios deben conocerla para dirigir correctamente el paquete. Tamao: 32 bit. LA DIRECCIN DE INTERNET El protocolo IP identifica a cada ordenador que se encuentre conectado a la red mediante su correspondiente direccin. Esta direccin es un nmero de 32 bit que debe ser nico para cada host, y normalmente suele representarse como cuatro cifras de 8 bit separadas por puntos. La direccin de Internet (IP Address) se utiliza para identificar tanto al ordenador en concreto como la red a la que pertenece, de manera que sea posible distinguir a los ordenadores que se encuentran conectados a una misma red. Con este propsito, y teniendo en cuenta que en Internet se encuentran conectadas redes de tamaos muy diversos, se establecieron tres clases diferentes de direcciones, las cuales se representan mediante tres rangos de valores: Clase A: Son las que en su primer byte tienen un valor comprendido entre 1 y 126, incluyendo ambos valores. Estas direcciones utilizan nicamente este primer byte para identificar la red, quedando los otros tres bytes disponibles para cada uno de los hosts que pertenezcan a esta misma red. Esto significa que podrn existir ms de diecisis millones de ordenadores en cada una de las redes de esta clase. Este tipo de direcciones es usado por redes muy extensas, pero hay que tener en cuenta que slo puede haber 126 redes de este tamao. ARPAnet es una de ellas, existiendo adems algunas grandes redes comerciales, aunque son pocas las organizaciones que obtienen una direccin de "clase A". Lo normal para las grandes organizaciones es que utilicen una o varias redes de "clase B".

Clase B: Estas direcciones utilizan en su primer byte un valor comprendido entre 128 y 191, incluyendo ambos. En este caso el identificador de la red se obtiene de los dos primeros bytes de la direccin, teniendo que ser un valor entre 128.1 y 191.254 (no es posible utilizar los valores 0 y 255 por tener un significado especial). Los dos ltimos bytes de la direccin constituyen el identificador del host permitiendo, por consiguiente, un nmero mximo de 64516 ordenadores en la misma red. Este tipo de direcciones tendra que ser suficiente para la gran mayora de las organizaciones grandes. En caso de que el nmero de ordenadores que se necesita conectar fuese mayor, sera posible obtener ms de una direccin de "clase B", evitando de esta forma el uso de una de "clase A". Clase C: En este caso el valor del primer byte tendr que estar comprendido entre 192 y 223, incluyendo ambos valores. Este tercer tipo de direcciones utiliza los tres primeros bytes para el nmero de la red, con un rango desde 192.1.1 hasta 223.254.254. De esta manera queda libre un byte para el host, lo que permite que se conecten un mximo de 254 ordenadores en cada red. Estas direcciones permiten un menor nmero de host que las anteriores, aunque son las ms numerosas pudiendo existir un gran nmero redes de este tipo (ms de dos millones). Tabla de direcciones IP de Internet. Clase Primer byte Identificacin de red 1 byte 2 byte 3 byte Identificacin de hosts 3 byte 2 byte 1 byte Nmero de redes 126 16.256 2.064.512 Nmero de hosts 16.387.064 64.516 254
A B C
1 .. 126 128 .. 191 192 .. 223
En la clasificacin de direcciones anterior se puede notar que ciertos nmeros no se usan. Algunos de ellos se encuentran reservados para un posible uso futuro, como es el caso de las direcciones cuyo primer byte sea superior a 223 (clases D y E, que an no estn definidas), mientras que el valor 127 en el primer byte se utiliza en algunos sistemas para propsitos especiales. Tambin es importante notar que los valores 0 y 255 en cualquier byte de la direccin no pueden usarse normalmente por tener otros propsitos especficos. El nmero 0 est reservado para las mquinas que no conocen su direccin, pudiendo utilizarse tanto en la identificacin de red para mquinas que an no conocen el nmero de red a la que se encuentran conectadas, en la

identificacin de host para mquinas que an no conocen su nmero de host dentro de la red, o en ambos casos. El nmero 255 tiene tambin un significado especial, puesto que se reserva para el broadcast. El broadcast es necesario cuando se pretende hacer que un mensaje sea visible para todos los sistemas conectados a la misma red. Esto puede ser til si se necesita enviar el mismo datagrama a un nmero determinado de sistemas, resultando ms eficiente que enviar la misma informacin solicitada de manera individual a cada uno. Otra situacin para el uso de broadcast es cuando se quiere convertir el nombre por dominio de un ordenador a su correspondiente nmero IP y no se conoce la direccin del servidor de nombres de dominio ms cercano. Lo usual es que cuando se quiere hacer uso del broadcast se utilice una direccin compuesta por el identificador normal de la red y por el nmero 255 (todo unos en binario) en cada byte que identifique al host. Sin embargo, por conveniencia tambin se permite el uso del nmero 255.255.255.255 con la misma finalidad, de forma que resulte ms simple referirse a todos los sistemas de la red. El broadcast es una caracterstica que se encuentra implementada de formas diferentes dependiendo del medio utilizado, y por lo tanto, no siempre se encuentra disponible. En ARPAnet y en las lneas punto a punto no es posible enviar broadcast, pero s que es posible hacerlo en las redes Ethernet, donde se supone que todos los ordenadores prestarn atencin a este tipo de mensajes. En el caso de algunas organizaciones extensas puede surgir la necesidad de dividir la red en otras redes ms pequeas (subnets). Como ejemplo podemos suponer una red de clase B que, naturalmente, tiene asignado como identificador de red un nmero de dos bytes. En este caso sera posible utilizar el tercer byte para indicar en qu red Ethernet se encuentra un host en concreto. Esta divisin no tendr ningn significado para cualquier otro ordenador que est conectado a una red perteneciente a otra organizacin, puesto que el tercer byte no ser comprobado ni tratado de forma especial. Sin embargo, en el interior de esta red existir una divisin y ser necesario disponer de un software de red especialmente diseado para ello. De esta forma queda oculta la organizacin interior de la red, siendo mucho ms cmodo el acceso que si se tratara de varias direcciones de clase C independientes. -TCP: Una entidad de transporte TCP acepta mensajes de longitud arbitrariamente grande procedentes de los procesos de usuario, los separa en pedazos que no excedan de 64K octetos y, transmite cada pedazo como si fuera un datagrama separado. La capa de red, no garantiza que los datagramas se entreguen apropiadamente, por lo que TCP deber utilizar temporizadores y retransmitir los datagramas si es necesario. Los datagramas que consiguen llegar, pueden

hacerlo en desorden; y depender de TCP el hecho de reensamblarlos en mensajes, con la secuencia correcta. Cada octeto de datos transmitido por TCP tiene su propio nmero de secuencia privado. El espacio de nmeros de secuencia tiene una extensin de 32 bits, para asegurar que los duplicados antiguos hayan desaparecidos, desde hace tiempo, en el momento en que los nmeros de secuencia den la vuelta. TCP, sin embargo, s se ocupa en forma explcita del problema de los duplicados retardados cuando intenta establecer una conexin, utilizando el protocolo de idavuelta-ida para este propsito. La primera cosa que llama la atencin es que la cabecera mnima de TCP sea de 20 octetos. A diferencia de la clase 4 del modelo OSI, con la cual se puede comparar a grandes rasgos, TCP slo tiene un formato de cabecera de TPDU (llamadas mensajes). Enseguida se analizar minuciosamente campo por campo, esta gran cabecera. Los campos Puerto fuente y Puerto destino identifican los puntos terminales de la conexin(las direcciones TSAP de acuerdo con la terminologa del modelo OSI). Cada hostal deber decidir por s mismo cmo asignar sus puertos. Los campos Numero de secuencia y Asentimiento en superposicin efectan sus funciones usuales. Estos tienen una longitud de 32 bits, debido a que cada octeto de datos est numerado en TCP. La Longitud de la cabecera TCP indica el nmero de palabra de 32 bits que estn contenidas en la cabecera de TCP. Esta informacin es necesaria porque el campo Opciones tiene una longitud variable, y por lo tanto la cabecera tambin. Despus aparecen seis banderas de 1 bit. Si el Puntero acelerado se est utilizando, entonces URG se coloca a 1. El puntero acelerado se emplea para indicar un desplazamiento en octetos a partir del nmero de secuencia actual en el que se encuentran datos acelerados. Esta facilidad se brinda en lugar de los mensajes de interrupcin. El bit SYN se utiliza para el establecimiento de conexiones. La solicitud de conexin tiene SYN=1 y ACK=0, para indicar que el campo de asentimiento en superposicin no se est utilizando. La respuesta a la solicitud de conexin si lleva un asentimiento, por lo que tiene SYN=1 y ACK=1. En esencia, el bit SYN se utiliza para denotar las TPDU CONNECTION REQUEST Y CONNECTION CONFIRM, con el bit ACK utilizado para distinguir entre estas dos posibilidades. El bit FIN se utiliza para liberar la conexin; especifica que el emisor ya no tiene ms datos. Despus de cerrar una conexin, un proceso puede seguir recibiendo datos indefinidamente. El bit RST se utiliza para reiniciar una conexin que se ha vuelto confusa debido a SYN duplicados y retardados, o a cada de los hostales. El bit EOM indica el Fin del Mensaje. El control de flujo en TCP se trata mediante el uso de una ventana deslizante de tamao variable. Es necesario tener un campo de 16 bits, porque la

ventana indica el nmero de octetos que se pueden transmitir ms all del octeto asentido por el campo ventana y no cuntas TPDU. El cdigo de redundancia tambin se brinda como un factor de seguridad extrema. El algoritmo de cdigo de redundancia consiste en sumar simplemente todos los datos, considerados como palabras de 16 bits, y despus tomar el complemento a 1 de la suma. El campo de Opciones se utiliza para diferentes cosas, por ejemplo para comunicar tamao de tampones durante el procedimiento de establecimiento. EN QUE SE UTILIZA TCP/IP Muchas grandes redes han sido implementadas con estos protocolos, incluyendo DARPA Internet "Defense Advanced Research Projects Agency Internet", en espaol, Red de la Agencia de Investigacin de Proyectos Avanzados de Defensa. De igual forma, una gran variedad de universidades, agencias gubernamentales y empresas de ordenadores, estn conectadas mediante los protocolos TCP/IP. Cualquier mquina de la red puede comunicarse con otra distinta y esta conectividad permite enlazar redes fsicamente independientes en una red virtual llamada Internet. Las mquinas en Internet son denominadas "hosts" o nodos. TCP/IP proporciona la base para muchos servicios tiles, incluyendo correo electrnico, transferencia de ficheros y login remoto. El correo electrnico est diseado para transmitir ficheros de texto pequeos. Las utilidades de transferencia sirven para transferir ficheros muy grandes que contengan programas o datos. Tambin pueden proporcionar chequeos de seguridad controlando las transferencias. El login remoto permite a los usuarios de un ordenador acceder a una mquina remota y llevar a cabo una sesin interactiva. SIMILITUDES Y DIFERENCIAS ENTRE LA CLASE 4 DEL MODELO OSI Y TCP El protocolo de transporte de clase 4 del modelo OSI (al que con frecuencia se le llama TP4), y TCP tienen numerosas similitudes, pero tambin algunas diferencias. A continuacin se dan a conocer los puntos en que los dos protocolos son iguales. Los dos protocolos estn diseados para proporcionar un servicio de transporte seguro, orientado a conexin y de extremo a extremo, sobre una red insegura, que puede perder, daar, almacenar y duplicar paquetes. Los dos deben enfrentarse a los peores problemas como sera el caso de una subred que pudiera almacenar una secuencia vlida de paquetes y ms tarde volviera a entregarlos.

Los dos protocolos tambin son semejantes por el hecho de que los dos tienen una fase de establecimiento de conexin, una fase de transferencia de datos y despus una fase de liberacin de la conexin. Los conceptos generales del establecimiento, uso y liberacin de conexiones tambin son similares, aunque difieren en algunos detalles. En particular, tanto TP4 como TCP utilizan la comunicacin ida-vuelta-ida para eliminar las dificultades potenciales ocasionadas por paquetes antiguos que aparecieran sbitamente y pudiesen causar problemas. Sin embargo, los dos protocolos tambin presentan diferencias muy notables, las cuales se pueden observar en la lista que se muestra en la figura siguiente. Primero, TP4 utiliza nueve tipos diferentes de TPDU, en tanto que TCP slo tiene uno. Esta diferencia trae como resultado que TCP sea ms sencillo, pero al mismo tiempo tambin necesita una cabecera ms grande, porque todos los campos deben estar presentes en todas las TPDU. El mnimo tamao de la cabecera TCP es de 20 octetos; el mnimo tamao de la cabecera TP4 es de 5 octetos. Los dos protocolos permiten campos opcionales, que pueden incrementar el tamao de las cabeceras por encima del mnimo permitido. CARACTERSTICA Numero de tipos de TPDU Fallo de Conexin Formato de direcciones Calidad de servicio Datos del usuario en CR Flujo Datos importantes Superposicin Control de flujo explcito Nmero de subsecuencia Liberacin OSI TP4 9 2 conexiones No est definido Extremo abierto Permitido Mensajes Acelerados No Algunas veces Permitidos Abrupta TCP 1 1 conexin 32 bits Opciones especficas No permitido Octetos Acelerados S Siempre No Permitido Ordenada
Diferencias entre el protocolo tp4 del modelo OSI y TCP Una segunda diferencia es con respecto a lo que sucede cuando los dos procesos, en forma simultnea, intentan establecer conexiones entre los mismos dos TSAP (es decir, una colisin de conexiones). Con TP4 se establecen dos conexiones duplex independientes; en tanto que con TCP, una conexin se identifica mediante un par de TSAP, por lo que solamente se establece una conexin.

Una tercera diferencia es con respecto al formato de direcciones que se utiliza. TP4 no especifica el formato exacto de una direccin TSAP; mientras que TCP utiliza nmeros de 32 bits. El concepto de calidad de servicio tambin se trata en forma diferente en los dos protocolos, constituyendo la cuarta diferencia. TP4 tiene un mecanismo de extremo abierto, bastante elaborado, para una negociacin a tres bandas sobre la calidad de servicio. Esta negociacin incluye al proceso que hace la llamada, al proceso que es llamado y al mismo servicio de transporte. Se pueden especificar muchos parmetros, y pueden proporcionarse los valores: deseado y mnimo aceptable. A diferencia de esto, TCP no tiene ningn campo de calidad de servicio, sino que el servicio subyacente IP tiene un campo de 8 bits, el cual permite que se haga una relacin a partir de un nmero limitado de combinaciones de velocidad y seguridad. Una quinte diferencia es que TP4 permite que los datos del usuario sean transportados en la TPDU CR, pero TCP no permite que los datos del usuario aparezcan en la TPDU inicial. El dato inicial (como por ejemplo, una contrasea), podra ser necesario para decidir si se debe, o no, establecer una conexin. Con TCP no es posible hacer que el establecimiento dependa de los datos del usuario. Las cuatro diferencias anteriores se relacionan con la fase de establecimiento de la conexin. Las cinco siguientes se relacionan con la fase de transferencia de datos. Una diferencia bsica es el modelo del transporte de datos. El modelo TP4 es el de una serie de mensajes ordenados (correspondientes a las TSDU en la terminologa OSI). El modelo TCP es el de un flujo continuo de octetos, sin que haya ningn lmite explcito entre mensajes. En la prctica, sin embargo, el modelo TCP no es realmente un flujo puro de octetos, porque el procedimiento de biblioteca denominado push puede llamarse para sacar todos los datos que estn almacenados, pero que todava no se hayan transmitido. Cuando el usuario remoto lleva a cabo una operacin de lectura, los datos anteriores y posteriores al push no se combinarn, por lo que, en cierta forma un push podra penarse como si definiesen una frontera entre mensajes. La sptima diferencia se ocupa de cmo son tratados los datos importantes que necesitan de un procesamiento especial (como los caracteres BREAK). TP4 tiene dos flujos de mensajes independientes, los datos normales y los acelerados multiplexados de manera conjunta. En cualquier instante nicamente un mensaje acelerado puede estar activo. TCP utiliza el campo Acelerado para indicar que cierta cantidad de octetos, dentro de la TPDU actualmente en uso, es especial y debera procesarse fuera de orden. La octava diferencia es la ausencia del concepto de superposicin en TP4 y su presencia en TCP. Esta diferencia no es tan significativa como al principio podra parecer, dado que es posible que una entidad de transporte ponga dos TPDU, por ejemplo, DT y AK en un nico paquete de red.

La novena diferencia se relaciona con la forma como se trata el control de flujo. TP4 puede utilizar un esquema de crdito, pero tambin se puede basar en el esquema de ventana de la capa de red para regular el flujo. TCP siempre utiliza un mecanismo de control de flujo explcito con el tamao de la ventana especificado en cada TPDU. La dcima diferencia se relaciona con este esquema de ventana. En ambos protocolos el receptor tiene la capacidad de reducir la ventana en forma voluntaria. Esta posibilidad genera potencialmente problemas, si el otorgamiento de una ventana grande y su contraccin subsiguiente llegan en un orden incorrecto. En TCP no hay ninguna solucin para este problema; en tanto en TP4 ste se resuelve por medio del nmero de subsecuencia que est incluido en la contraccin, permitiendo de esta manera que el emisor determine si la ventana pequea sigui, o precedi, a la ms grande. Finalmente, la onceava y ltima diferencia existente entre los dos protocolos, consiste en la manera como se liberan las conexiones. TP4 utiliza una desconexin abrupta en la que una serie de TPDU de datos pueden ser seguidos directamente por una TPDU DR. Si las TPDU de datos se llegaran a perder, el protocolo no los podra recuperar y la informacin, al final se perdera. TCP utiliza una comunicacin de ida-vuelta-ida para evitar la prdida de datos en el momento de la desconexin. El modelo OSI trata este problema en la capa de sesin. Es importante hacer notar que la Oficina Nacional de Normalizacin de Estados Unidos estaba tan disgustada con esta propiedad de TP4, que introdujo TPDU adicionales en el protocolo de transporte para permitir la desconexin sin que hubiera una prdida de datos. Como consecuencia de esto, las versiones de Estados Unidos y la internacional de TP4 son diferentes. Es importante sealar que el protocolo IP explicado anteriormente, o mejor dicho la versin de ste es la ms utilizada actualmente, pero hace muy poco tiempo sali una nueva versin llamada la nmero 6. Las diferencias no son muchas, pero mejoran muchos aspectos de la antigua, sta no es muy utilizada, pero creemos que es necesario explicar como funciona, para poder hacer una comparacin con la antigua. A continuacin la trataremos. LA NUEVA VERSIN DE IP (IPng) La nueva versin del protocolo IP recibe el nombre de IPv6, aunque es tambin conocido comnmente como IPng (Internet Protocol Next Generation). El nmero de versin de este protocolo es el 6 (que es utilizada en forma mnima) frente a la antigua versin utilizada en forma mayoritaria. Los cambios que se introducen en esta nueva versin son muchos y de gran importancia, aunque la transicin desde la versin antigua no debera ser problemtica gracias a las caractersticas de compatibilidad que se han incluido en el protocolo. IPng se ha diseado para solucionar todos los problemas que surgen con la versin anterior,

y adems ofrecer soporte a las nuevas redes de alto rendimiento (como ATM, Gigabit Ethernet, etc.). Una de las caractersticas ms llamativas es el nuevo sistema de direcciones, en el cual se pasa de los 32 a los 128 bit, eliminando todas las restricciones del sistema actual. Otro de los aspectos mejorados es la seguridad, que en la versin anterior constitua uno de los mayores problemas. Adems, el nuevo formato de la cabecera se ha organizado de una manera ms efectiva, permitiendo que las opciones se siten en extensiones separadas de la cabecera principal. Formato de la cabecera. El tamao de la cabecera que el protocolo IPv6 aade a los datos es de 320 bit, el doble que en la versin antigua. Sin embargo, esta nueva cabecera se ha simplificado con respecto a la anterior. Algunos campos se han retirado de la misma, mientras que otros se han convertido en opcionales por medio de las extensiones. De esta manera los routers no tienen que procesar parte de la informacin de la cabecera, lo que permite aumentar de rendimiento en la transmisin. El formato completo de la cabecera sin las extensiones es el siguiente: Versin: Nmero de versin del protocolo IP, que en este caso contendr el valor 6. Tamao: 4 bit. Prioridad: Contiene el valor de la prioridad o importancia del paquete que se est enviando con respecto a otros paquetes provenientes de la misma fuente. Tamao: 4 bit. Etiqueta de flujo: Campo que se utiliza para indicar que el paquete requiere un tratamiento especial por parte de los routers que lo soporten. Tamao: 24 bit. Longitud: Es la longitud en bytes de los datos que se encuentran a continuacin de la cabecera. Tamao: 16 bit. Siguiente cabecera: Se utiliza para indicar el protocolo al que corresponde la cabecera que se sita a continuacin de la actual. El valor de este campo es el mismo que el de protocolo en la versin 4 de IP. Tamao: 8 bit. Lmite de existencia: Tiene el mismo propsito que el campo de la versin 4, y es un valor que disminuye en una unidad cada vez que el paquete pasa por un nodo. Tamao:8 bit. Direccin de origen: El nmero de direccin del host que enva el paquete. Su longitud es cuatro veces mayor que en la versin 4. Tamao: 128 bit.

Direccin de destino: Nmero de direccin de destino, aunque puede no coincidir con la direccin del host final en algunos casos. Su longitud es cuatro veces mayor que en la versin 4 del protocolo IP. Tamao: 128 bit. Organizacin de la cabecera IPv6. Prioridad Etiqueta de flujo Siguiente Cabecera Lmite de existencia
Versin Longitud
Direccin de origen Direccin de destino
Las extensiones que permite aadir esta versin del protocolo se sitan inmediatamente despus de la cabecera normal, y antes de la cabecera que incluye el protocolo de nivel de transporte. Los datos situados en cabeceras opcionales se procesan slo cuando el mensaje llega a su destino final, lo que supone una mejora en el rendimiento. Otra ventaja adicional es que el tamao de la cabecera no est limitado a un valor fijo de bytes como ocurra en la versin 4. Por razones de eficiencia, las extensiones de la cabecera siempre tienen un tamao mltiplo de 8 bytes. Actualmente se encuentran definidas extensiones para routing extendido, fragmentacin y ensamblaje, seguridad, confidencialidad de datos, etc. Direcciones en la versin 6. El sistema de direcciones es uno de los cambios ms importantes que afectan a la versin 6 del protocolo IP, donde se han pasado de los 32 a los 128 bit (cuatro veces mayor). Estas nuevas direcciones identifican a un interfaz o conjunto de interfaces y no a un nodo, aunque como cada interfaz pertenece a un nodo, es posible referirse a stos a travs de su interfaz. El nmero de direcciones diferentes que pueden utilizarse con 128 bits es enorme. Tericamente seran 2128 direcciones posibles, siempre que no apliquemos algn formato u organizacin a estas direcciones. Este nmero es extremadamente alto, pudiendo llegar a soportar ms de 665.000 trillones de direcciones distintas por cada metro cuadrado de la superficie del planeta Tierra. Segn diversas fuentes consultadas, estos nmeros una vez organizados de forma prctica y jerrquica quedaran reducidos en el peor de los casos a 1.564 direcciones por cada metro cuadrado, y siendo optimistas se podran alcanzar entre los tres y cuatro trillones.

Existen tres tipos bsicos de direcciones IPng segn se utilicen para identificar a un interfaz en concreto o a un grupo de interfaces. Los bits de mayor peso de los que componen la direccin IPng son los que permiten distinguir el tipo de direccin, emplendose un nmero variable de bits para cada caso. Estos tres tipos de direcciones son: Direcciones unicast: Son las direcciones dirigidas a un nico interfaz de la red. Las direcciones unicast que se encuentran definidas actualmente estn divididas en varios grupos. Dentro de este tipo de direcciones se encuentra tambin un formato especial que facilita la compatibilidad con las direcciones de la versin 4 del protocolo IP. Direcciones anycast: Identifican a un conjunto de interfaces de la red. El paquete se enviar a un interfaz cualquiera de las que forman parte del conjunto. Estas direcciones son en realidad direcciones unicast que se encuentran asignadas a varios interfaces, los cuales necesitan ser configurados de manera especial. El formato es el mismo que el de las direcciones unicast. Direcciones multicast: Este tipo de direcciones identifica a un conjunto de interfaces de la red, de manera que el paquete es enviado a cada una de ellos individualmente. Las direcciones de broadcast no estn implementadas en esta versin del protocolo, debido a que esta misma funcin puede realizarse ahora mediante el uso de las direcciones multicast. Definicin Middleware: Capa de software intermedio entre el cliente y el servidor. Es la capa de software que nos permiten gestionar los mecanismos de comunicaciones. Ejemplo si se hace la peticin de una pgina web desde un browser en el cliente, el middleware determina la ubicacin y enva una peticin para dicha pgina. El servidor Web, interpreta la peticin y enva la pgina al software intermedio, quien la dirige al navegador de la mquina cliente que la solicit. El Middleware es un software de conectividad que ofrece un conjunto de servicios que hacen posible el funcionamiento de aplicaciones distribuidas sobre plataformas heterogneas. Funciona como una capa de abstraccin de software distribuida, que se sita entre las capas de aplicaciones y las capas inferiores (sistema operativo y red). El Middleware nos abstrae de la complejidad y heterogeneidad de las redes de comunicaciones subyacentes, as como de los sistemas operativos y lenguajes de programacin, proporcionando una API para la fcil programacin y manejo de aplicaciones distribuidas. Dependiendo del problema a resolver y de las funciones necesarias, sern tiles diferentes tipo de servicios de middleware.

Por lo general el middleware del lado cliente est implementado por el Sistema Operativo subyacente, el cual posee las libreras que implementan todas las funcionalidades para la comunicacin a travs de la red. Orgenes: Los Middleware han aparecido de manera relativamente reciente en el mundo de la informtica, hoy en da tecnologas mviles (celulares) estn aplicando esta tecnologa para el soporte de llamadas VOIP. En el pasado ganaron popularidad en la dcada de los 80, ya que eran la solucin de cmo integrar las nuevas aplicaciones con los sistemas heredados (legacy systems), en todo caso, el termino ha sido usado desde 1968. Tambin facilitaba la computacin distribuida, mediante conexin de mltiples aplicaciones para crear una mucho mayor, sobre una red. Tipos de middleware: Existen dos tipos: Software intermedio general. Servicios generales que requieren todos los clientes y servidores, por ejemplo: software para las comunicaciones usando el TCP/IP, software parte del sistema operativo que, por ejemplo, almacena los archivos distribuidos, software de autenticacin, el software intermedio de mensajes de clientes a servidores y viceversa. Software intermedio de servicios. Software asociado a un servicio en particular, por ejemplo: software que permite a dos BD conectarse a una red cliente/servidor (ODBC: Conectividad abierta de BD), software de objetos distribuidos, por ejemplo la tecnologa CORBA permite que objetos distribuidos creados en distintos lenguajes coexistan en una misma red (intercambien mensajes), software intermedio para software de grupo, software intermedio asociado a productos de seguridad especficas (Conexiones Seguras: Sockets), etc. Se pueden clasificar los diferentes middleware en funcin de su escalabilidad y su tolerancia a fallos, aunque tomando en cuenta que esta investigacin no fue corroborada, pueden haber otros tipos de clasificaciones: Remote Procedure Call (RPCs) El cliente realiza una llamada a procedimientos que estn corriendo en mquinas remotas. Pueden ser sncronos o asncronos. Publish/subscribe Este tipo de monitores middleware activan y entregan informacin relevante para los subscriptores.

Message Oriented Middleware (MOM) Los mensajes enviados al cliente se recogen y se almacenan hasta que son solicitados, mientras el cliente contina con otros procesos. Object Request Broker (ORB) Este tipo de middleware permite que los clientes enven objetos y soliciten servicios en un sistema orientado a objetos. SQL-oriented Data Access middleware entre las aplicaciones y los servidores de base de datos. Otras fuentes incluyen divisiones adicionales: Monitores de Transacciones Distribuidas Provee herramientas y un ambiente de desarrollo y despliegue de aplicaciones distribuidas. Servidor de aplicaciones Software instalado en una computadora para facilitar el servicio (ejecucin) de otras aplicaciones. Enterprise Service Bus Una capa abstracta en el tope de un sistema de mensajera de empresa. Caractersticas: Independiza el servicio de su implantacin, del sistema operativo y de los protocolos de comunicaciones. Permite la convivencia de distintos servicios en un mismo sistema. Permite la transparencia en el sistema. Modelo tradicional: Monitor de teleproceso o CICS, Tuxedo, Encina. Modelo OO: CORBA. TECNOLOGIAS PARA EL DESARROLLO DE SISTEMAS DISTRIBUIDOS. Debido al auge que se ha venido dando ltimamente en el uso de las redes, se ha incrementado el crecimiento de los entornos distribuidos y heterogneos. El desarrollo de aplicaciones distribuidas enfrenta diferencias de arquitectura, tales como: el hardware, el sistema operativo, el ambiente de desarrollo, el lenguaje de programacin e incluso el paradigma de programacin, por todo esto ha sido necesario utilizar diferentes tecnologas y mecanismos de desarrollo. La programacin distribuida hace uso de distintas tecnologas e incluso puede mezclarlas para generar nuevas. Aqu presento tres tecnologas para la programacin distribuida, las denominadas Tecnologas de Desarrollo de

Sistemas Distribuidos basados en Objetos. En este tema se presentaran tres de las tecnologas utilizadas para el desarrollo de aplicaciones distribuidas, las cuales han generado un nuevo paradigma en el desarrollo de aplicaciones distribuidas, denominado, aplicaciones basadas en Plataformas de Componentes Distribuidos. Primeramente se hablar de CORBA (Common Object Request Broker Architecture), que es una tecnologa de integracin que define un marco estndar para interoperabilidad entre objetos con independencia del lenguaje y de forma transparente al programador. Posteriormente se describir COM/DCOM/ActiveX, que son mecanismos de comunicacin entre procesos diseados principalmente para los sistemas Windows. Y por ltimo se hablar de los JavaBeans, que son un modelo de componentes que favorece la reutilizacin y que son visualizados en un entorno Java. CORBA. CORBA (Common Object Request Broker Architecture), es una arquitectura de objetos distribuidos, que con el patrocinio del grupo OMG (Object Managament Group) compuesto por compaas como American Airlines, Canon, Data General, HP, Philips Telecomunicaciones, Sun, 3Com, Microsoft y Unisys entre otros; se ha convertido en un estndar y gracias a ello permite a aplicaciones de software implementadas incluso en diferentes lenguajes comunicarse entre s, a travs de sistemas de cmputo, que a su vez pueden estar conformados por hardware, sistemas operativos distintos y que forman parte de alguna red. Adems, la ejecucin de objetos remotos se puede lograr sin la necesidad de un servidor Web. CORBA al ser un estndar cuenta con un conjunto de especificaciones, sobre las cuales los vendedores de implementaciones de CORBA, conocidas como Object Request Broker (ORB) se apegan, para facilitar la comunicacin con la implementacin de otro vendedor. CORBA cuenta con tres elementos principales en los cuales se basa: El lenguaje de definicin de interfaces IDL (Interface Definition Language), el ORB (Object Request Broker) y el protocolo GIOP (General Inter-ORB Protocol). En cuanto al modelado de los objetos, CORBA hace uso del modelo cliente/servidor para el manejo de los mensajes y as establecer la comunicacin entre ellos, cuando un objeto en una aplicacin cliente requiere ejecutar los mtodos de un objeto remoto en una aplicacin servidor, hace uso del ORB que es especfico para el lenguaje y la plataforma de cada aplicacin, el cual traduce la llamada del cliente a un formato neutro, totalmente independiente, que puede transportarse sobre cualquier medio para el cual exista un protocolo de comunicacin. Un esquema conceptual de la arquitectura de CORBA se muestra en la figura siguiente:
Como se observa en la figura anterior, se tienen tres elementos importantes: El Cliente Stub, un Servidor Skeleton y el ORB. El Cliente Stub es una entidad de programa que invoca una operacin sobre la implementacin de un objeto remoto a travs de un Stub cuyo propsito es lograr que la peticin de un cliente llegue hasta el ORB Core. Logrando el acoplamiento entre el lenguaje de programacin en que se escribe el cliente y el ORB Core. El stub crea y expide las solicitudes del cliente. Un Servidor Skeleton es la implementacin de un objeto CORBA en algn lenguaje de programacin, y define las operaciones que soporta una interface IDL CORBA. Puede escribirse en una gran variedad de lenguajes como C, C++, Java, Ada o Smalltalk. Y a travs del skeleton entrega las solicitudes procedentes del ORB a la implementacin del objeto CORBA. La funcin del ORB consiste en conectar las dos partes: cliente y servidor. Presumiblemente estas partes se ejecutan sobre plataformas distintas y funcionan con diferentes sistemas operativos. Esto significa que pueden existir diferencias en tipos de datos, el orden de los parmetros en una llamada, el orden de los bytes en una palabra segn el tipo de procesador, etc. Es misin del ORB efectuar los procesos conocidos como marshaling y unmarshaling. En caso de que el mtodo invocado devuelva un valor de retorno, la funcin de los ORB del cliente y servidor

se invierte. ste realiza el marshaling de dicho valor y lo enva al ORB del cliente, que ser el que realice el unmarshaling y finalmente facilite el valor en formato nativo. Existe una gran variedad de implementaciones CORBA. En las siguientes pginas web: http://www.puder.org/corba/matrix/ http://adams.patriot.net/~tvalesky/freecorba.html Se encuentran implementaciones basadas en CORBA y se describen sus caractersticas, algunas son propietarias y otras ms son libres. COM/DCOM/Activex COM (Component Object Model) es un estndar que permite la creacin de objetos que ejecuten tareas que resuelven problemas especficos pero comunes a varias aplicaciones que puedan desear hacer uso de ellos. Estos pueden ser invocados por diferentes programas que los requieran, tanto OLE como ActiveX estn basados en esta tecnologa. La idea es tener un mundo de objetos independientes de un lenguaje de programacin. Por ello COM proporciona un estndar para las comunicaciones entre componentes, de tal forma, que una aplicacin puede utilizar caractersticas de cualquier otro objeto de la aplicacin, o del sistema operativo, y permite actualizar el software de un componente sin afectar a la operacin de la solucin global. COM soporta comunicacin entre objetos de equipos de cmputo distintos, en una LAN, WAN, o incluso en Internet. DCOM extiende el estndar COM de objetos remotos, para su utilizacin en redes. Inicialmente se desarroll para Windows NT 4.0, y posteriormente para Solaris 2.x y Macintosh, as como para diferentes versiones UNIX. Se encarga de manejar los detalles muy bajos de protocolos de red, por lo que el desarrollador se puede centrar en la realidad de los negocios, proporcionando as mejores soluciones a los clientes. La arquitectura define cmo los componentes y sus clientes interactan entre s. Esta interaccin es definida de tal manera que el cliente y el componente pueden conectarse sin la necesidad de un sistema intermedio. El cliente llama a los mtodos del componente sin tener que preocuparse de niveles ms complejos. DCOM olvida completamente la localizacin de los componentes, no importando que estn en el mismo proceso que el cliente o en una mquina en

cualquier lugar del mundo. En cualquier caso, la forma en la que el cliente se conecta a un componente y llama a los mtodos de ste, es idntica. No es slo que no necesite cambios en el cdigo fuente, sino que adems no necesita que el programa sea recompilado. Una simple reconfiguracin cambia la forma en la que los componentes se conectan entre s. La independencia de localizacin en DCOM simplifica enormemente las tareas de los componentes de aplicaciones distribuidas para alcanzar un nivel de funcionamiento ptimo. Supongamos, por ejemplo, que cierto componente debe ser localizado en una mquina especfica en un lugar determinado. Si la aplicacin tiene numerosos componentes pequeos, se puede reducir la carga de la red situndolos en la misma LAN, en la misma mquina, o incluso en el mismo proceso. Si la aplicacin est compuesta por un pequeo nmero de grandes componentes, la carga de red es menor y no es un problema, por tanto se pueden poner en las mquinas ms rpidas disponibles independientemente de donde estn situadas. Es completamente independiente del lenguaje. Casi cualquier lenguaje puede ser utilizado para crear componentes COM, y estos componentes puede ser utilizado por muchos ms lenguajes y herramientas. Java, Microsoft Visual C++, Microsoft Visual Basic, Delphi, PowerBuilder, y Micro Focus COBOL interactan perfectamente con DCOM. Puede utilizar cualquier protocolo de transporte, como TCP/IP, UDP, IPX/SPX y NetBIOS, y proporciona un marco de seguridad a todos estos protocolos. Los desarrolladores pueden utilizar las caractersticas proporcionadas por DCOM y asegurar que sus aplicaciones son completamente independientes del protocolo. DCOM est pensado para que el sistema pueda funcionar bajo cualquier tipo de red, ya sea LAN, WAN o Internet, de forma que se solucionen los mltiples problemas que aaden estos entornos. La denominada tecnologa ActiveX desarrollada por Microsoft hizo su aparicin en Internet con el navegador Internet Explorer 3.0. Su objetivo es similar al de los plug-ins, insertar objetos de diferente tipo en una pgina Web, aunque va mucho ms all al aadir mayores posibilidades de interaccin y comunicacin con programas externos, funciona de una manera similar al mecanismo de Microsoft OLE que usa el sistema operativo Windows, lo realmente novedoso es la aplicacin de esta tecnologa al WWW. Guarda parecido con los objetos para plugins y con los applets Java, aunque presenta algunas mejoras con respecto a ambos. Como ocurra con los plug-ins, los controles y documentos de ActiveX pueden ser insertados en una pgina Web, sin embargo no requieren de un pequeo programa para cada tipo de objeto ActiveX, esta nueva tecnologa ha sido denominada como auto-contenida porque cada objeto tiene suficiente informacin para ejecutarse l mismo sin ayuda de ninguna aplicacin.

Tal y como ocurre con los applets podemos crear nuestros propios controles o usar los creados por otros programadores. Si se opta por programarlos existen herramientas que lo facilitan, entre ellas destacan las creadas para este fin por Microsoft y que distribuye a travs de su Web. ActiveX est compuesto por dos tipos de objetos: Controles Activos (Active controls) Documentos Activos (Active documents) Estos ltimos permiten insertar documentos con formato PDF, DOC, etc. La tecnologa ActiveX constituye una interesante aportacin para aumentar la interactividad y capacidad de representacin de los documentos Web. La filosofa de su aplicacin es sencilla: Dentro de una pgina se insertan componentes (pequeas aplicaciones) capaces de interactuar con el usuario, realizar clculos o representar datos. Se insertan dentro de un documento con las etiquetas <OBJECT> y <PARAM>, estas corresponden a las operaciones de insercin del componente y paso de sus parmetros de ejecucin. Como se puede notar, no hay grandes diferencias con los plug-ins de Netscape. Cabe mencionar que los controles ActiveX que no estn firmados pueden generar un alto riesgo de seguridad, ya que pueden contener cdigo malicioso que puede tomar el control de la computadora de manera remota o daar archivos en el disco duro. JavaBeans Los JavaBeans traen la tecnologa de componentes a la Plataforma Java. Un componente software es una parte bsica para la construccin de una aplicacin, con las siguientes caractersticas que lo diferencian del resto del cdigo de un proyecto: Independencia de la plataforma, independencia del lenguaje, encapsulacin, basados en un modelo estndar permitiendo a los componentes interactuar entre s, JavaBeans les da a sus componentes estas propiedades. JavaBeans es un modelo de componentes software que ofrece flexibilidad, reutilizacin y que puede ser visualizado por un lenguaje de programacin Java. Los beans pueden ser aplicaciones que se pueden personalizar. El API de bean incluye clases e interfaces para personalizar en tiempo de diseo y en tiempo de ejecucin. Se pueden personalizar sus propiedades. Las propiedades con tipos de datos simples no tienen problema, en cambio hay otro tipo de propiedades ms complejas que se entrecruzan y que necesitan para ser personalizadas un editor de propiedades que ayuda a tal tarea.

La especificacin del API JavaBeans es una descripcin completa de los JavaBeans, sta se puede hallar en la pgina web: http://java.sun.com/products/javabeans/docs/spec.html Los beans deben entenderse entre s de alguna forma, debe haber comunicacin entre ellos para que la aplicacin que forman realicen su misin. Los eventos son como los mensajes de C++ para la comunicacin entre los objetos. JavaBeans sigue el modelo de eventos de Java. Las propiedades de un objeto determinan su estado y lo diferencian del resto, el estado debe ser conocido para que se configuren sus caractersticas as como para que sus cambios se transmitan a otros beans. Hay ocasiones en las que no se puede, ni tampoco interesa, cambiar ni examinar el valor de ciertas propiedades. Dados varios beans, es tarea del diseador conectar los beans y construir una aplicacin coherente. Para ello es necesario que conozca sus propiedades y que se ajuste a las necesidades de la aplicacin completa. Por ltimo JavaBeans no tiene un soporte para persistencia, ms bien usa un mtodo primario como la serializacin. Pero la persistencia abarca adems la seguridad de los beans y la compatibilidad de versiones. ARQUITECTURAS DE CLIENTE-SERVIDOR EN DOS Y TRES NIVELES DE COMUNICACIONES. Introduccin a la arquitectura en 2 niveles. La arquitectura en 2 niveles se utiliza para describir los sistemas cliente/servidor en donde el cliente solicita recursos y el servidor responde directamente a la solicitud, con sus propios recursos. Esto significa que el servidor no requiere otra aplicacin para proporcionar parte del servicio.
Introduccin a la arquitectura en 3 niveles. En la arquitectura en 3 niveles, existe un nivel intermediario. Esto significa que la arquitectura generalmente est compartida por:

1. Un cliente, es decir, el equipo que solicita los recursos, equipado con una interfaz de usuario (generalmente un navegador Web) para la presentacin. 2. El servidor de aplicaciones (tambin denominado software intermedio), cuya tarea es proporcionar los recursos solicitados, pero que requiere de otro servidor para hacerlo. 3. El servidor de datos, que proporciona al servidor de aplicaciones los datos que requiere.
El uso masivo del trmino arquitectura en 3 niveles tambin denota las siguientes arquitecturas: Aplicacin compartida entre un cliente, un software intermedio y un servidor empresarial. Aplicacin compartida entre un cliente, un servidor de aplicaciones y un servidor de base de datos empresarial. Comparacin entre ambos tipos de arquitecturas. La arquitectura en 2 niveles es, por lo tanto, una arquitectura cliente/servidor en la que el servidor es polivalente, es decir, puede responder directamente a todas las solicitudes de recursos del cliente. Sin embargo, en la arquitectura en 3 niveles, las aplicaciones al nivel del servidor son descentralizadas de uno a otro, es decir, cada servidor se especializa en una determinada tarea, (por ejemplo: servidor web/servidor de bases de datos). La arquitectura en 3 niveles permite:

Un mayor grado de flexibilidad. Mayor seguridad, ya que la seguridad se puede definir independientemente para cada servicio y en cada nivel. Mejor rendimiento, ya que las tareas se comparten entre servidores. Arquitectura de niveles mltiples. En la arquitectura en 3 niveles, cada servidor (nivel 2 y 3) realiza una tarea especializada (un servicio). Por lo tanto, un servidor puede utilizar los servicios de otros servidores para proporcionar su propio servicio. Por consiguiente, la arquitectura en 3 niveles es potencialmente una arquitectura en N-niveles.
REDES P2P (PEER TO PEER) O DE IGUAL A IGUAL. A grandes rasgos, una red informtica entre iguales (en ingls peer-to-peer -que se traducira de par a par- o de punto a punto, y ms conocida como P2P) se refiere a una red que no tiene clientes ni servidores fijos, sino una serie de nodos que se comportan simultneamente como clientes y como servidores de los dems nodos de la red. Es una forma legal de compartir archivos de forma similar a como se hace en el email o mensajeros instantneos solo que de una forma mas eficiente. Este modelo de red contrasta con el modelo cliente-servidor el cual se rige de una arquitectura monoltica donde no hay distribucin de tareas entre s, slo una simple comunicacin entre un usuario y una terminal en donde el cliente y el servidor no pueden cambiar de roles.

Las redes de ordenadores Peer-to-peer (o "P2P") son redes que aprovechan, administran y optimizan el uso de banda ancha que acumulan de los dems usuarios en una red por medio de la conectividad entre los mismos usuarios participantes de la red, obteniendo como resultado, mucho ms rendimiento en las conexiones y transferencias que con algunos mtodos centralizados convencionales donde una cantidad relativamente pequea de servidores provee el total de banda ancha y recursos compartidos para un servicio o aplicacin. Tpicamente estas redes se conectan en gran parte con otros nodos va "ad hoc". Dichas redes son tiles para muchos propsitos pero se usan muy a menudo para compartir toda clase de archivos que contienen: audio, video, texto, software y datos en cualquier formato digital. Este tipo de red es tambin comnmente usado en telefona VoIP para hacer ms eficiente la transmisin de datos en tiempo real as como lograr una mejor distribucin del trfico de la telefona utilizando tecnologa P2P. Cualquier nodo puede iniciar, detener o completar una transaccin compatible. La eficacia de los nodos en el enlace y transmisin de datos puede variar segn su configuracin local (cortafuegos, NAT, ruteadores, etc.), velocidad de proceso, disponibilidad de ancho de banda de su conexin a la red y capacidad de almacenamiento en disco. Filosofa de las redes Peer-to-peer. El P2P se basa principalmente en la filosofa e ideales de que todos los usuarios deben compartir. Conocida como filosofa P2P, es aplicada en algunas redes en forma de un sistema enteramente meritocrtico en donde "el que ms comparta, ms privilegios tiene y ms acceso dispone de manera ms rpida a ms contenido". Con este sistema se pretende asegurar la disponibilidad del contenido compartido, ya que de lo contrario no sera posible la subsistencia de la red. Aquellos usuarios que no comparten contenido en el sistema y con ello no siguen la filosofa propia de esta red, se les denominan "leechers"; los cuales muchas veces representan una amenaza para la disponibilidad de recursos en una red P2P debido a que nicamente consumen recursos sin reponer lo que consumen, por ende podran agotar los recursos compartidos y atentar contra la estabilidad de la misma. Caractersticas. Seis caractersticas deseables de las redes P2P:

Escalabilidad. Las redes P2P tienen un alcance mundial con cientos de millones de usuarios potenciales. En general, lo deseable es que cuantos ms nodos estn conectados a una red P2P mejor ser su funcionamiento. As, cuando los nodos llegan y comparten sus propios recursos, los recursos totales del sistema aumentan. Esto es diferente en una arquitectura del modo servidor-cliente con un sistema fijo de servidores, en los cuales la adicin de ms clientes podra significar una transferencia de datos ms lenta para todos los usuarios. Algunos autores advierten de que si proliferan mucho este tipo de redes, Cliente-Servidor, podran llegar a su fin, ya que a cada una de estas redes se conectarn muy pocos usuarios. Robustez. La naturaleza distribuida de las redes peer-to-peer tambin incrementa la robustez en caso de haber fallos en la rplica excesiva de los datos hacia mltiples destinos, y -en sistemas P2P puros- permitiendo a los peers encontrar la informacin sin hacer peticiones a ningn servidor centralizado de indexado. En el ltimo caso, no hay ningn punto singular de falla en el sistema. Descentralizacin. Estas redes por definicin son descentralizadas y todos los nodos son iguales. No existen nodos con funciones especiales, y por tanto ningn nodo es imprescindible para el funcionamiento de la red. En realidad, algunas redes comnmente llamadas P2P no cumplen esta caracterstica, como Napster, eDonkey2000 o BitTorrent. Los costes estn repartidos entre los usuarios. Se comparten o donan recursos a cambio de recursos. Segn la aplicacin de la red, los recursos pueden ser archivos, ancho de banda, ciclos de proceso o almacenamiento de disco. Anonimato. Es deseable que en estas redes quede annimo el autor de un contenido, el editor, el lector, el servidor que lo alberga y la peticin para encontrarlo siempre que as lo necesiten los usuarios. Muchas veces el derecho al anonimato y los derechos de autor son incompatibles entre s, y la industria propone mecanismos como el DRM para limitar ambos. Seguridad. Es una de las caractersticas deseables de las redes P2P menos implementada. Los objetivos de un P2P seguro seran identificar y evitar los nodos maliciosos, evitar el contenido infectado, evitar el espionaje de las comunicaciones entre nodos, creacin de grupos seguros de nodos dentro de la red, proteccin de los recursos de la red... En su mayora an estn bajo investigacin, pero los mecanismos ms prometedores son: cifrado multiclave, cajas de arena, gestin de derechos de autor (la industria define qu puede hacer el usuario, por ejemplo la segunda vez que se oye la cancin se apaga), reputacin (slo permitir acceso a los conocidos), comunicaciones seguras, comentarios sobre los ficheros.

Aplicaciones de las redes P2P. En la actual Internet, el ancho de banda o las capacidades de almacenamiento y cmputo son recursos caros. En aquellas aplicaciones y servicios que requieran una enorme cantidad de recursos pueden utilizarse las redes P2P. Algunos ejemplos de aplicacin de las redes P2P: Intercambio y bsqueda de ficheros. Quizs sea la aplicacin ms extendida de este tipo de redes. Algunos ejemplos son BitTorrent o la red eDonkey2000. Sistemas de ficheros distribuidos, como CFS o Freenet. Sistemas de telefona por Internet, como Skype. A partir del ao 2006 cada vez ms compaas europeas y americanas, como Warner Bros o la BBC, empezaron a ver el P2P como una alternativa a la distribucin convencional de pelculas y programas de televisin, ofreciendo parte de sus contenidos a travs de tecnologas como la de BitTorrent. Clculos cientficos que procesen enormes bases de datos, como los bioinformticos. Las redes P2P pueden ser tambin usadas para hacer funcionar grandes sistemas software diseado para realizar pruebas que identifiquen la presencia de posibles drogas. El primer sistema diseado con tal propsito fue desarrollado en 2001, en el Centro Computacional para el Descubrimiento de Drogas (Centre for Computational Drug Discovery) en la prestigiosa Universidad de Oxford con la cooperacin de la Fundacin Nacional para la Investigacin del Cncer (National Foundation for Cancer Research) de Estados Unidos. Actualmente, existen varios sistemas software similar que se desarrollan bajo el auspicio de proyectos como el proyecto de Dispositivos Unidos en la Investigacin del cncer (United Devices Cancer Research Project). En una escala ms pequea, existen sistemas de administracin autnoma para los bilogos computacionales, como el Chinook, que se unen para ejecutar y hacer comparaciones de datos bioinformticos con los ms de 25 diferentes servicios de anlisis que ofrece. Uno de sus propsitos, consiste en facilitar el intercambio de tcnicas de anlisis dentro de una comunidad local. Las instituciones acadmicas tambin han comenzado la experimentacin con comparticin de archivos, como es el caso de LionShare.

Problemas de funcionamiento. La mayor parte de los nodos de Internet no disponen de una direccin IP fija o incluso accesible para otros nodos de Internet. Este es el caso, por ejemplo, de los nodos que se conectan a travs de redes locales como Wifi o Ethernet, de los que tienen algn tipo de Cortafuegos y NAT y de los que se conectan a travs de la mayor parte de los ISPs del mundo. Para el correcto funcionamiento de una red P2P hay que resolver dos problemas fundamentales: cmo se encuentra un nodo que ya est conectado a la red P2P, y cmo se conectan los nodos sin direccin IP pblica entre ellos. Para resolver el primer problema la solucin habitual es realizar una conexin a un servidor (o servidores) inicial con direccin bien conocida (normalmente IP fija) que el programa P2P tiene almacenada. Este servidor inicial se encarga de mantener una lista con las direcciones de otros nodos que estn actualmente conectados a la red. Tras esto, los clientes ya tienen informacin suficiente para entrar en la red y pueden intercambiar informacin con otros nodos ya sin intervencin de los servidores iniciales. Para resolver el problema de conexin cuando los nodos no tienen direccin pblica, estos se conectan a travs de otro nodo que funciona como proxy de la conexin. Los dos nodos se conectan al proxy, y ste enva la informacin que llega de uno al otro. Cualquier nodo con una direccin IP pblica puede ser escogido como proxy de una conexin entre dos nodos. Por ejemplo, en la red Skype a travs de nuestro ordenador pueden pasar conversaciones de otras personas. En estos casos, es imprescindible la implementacin de algn mecanismo de seguridad para evitar que los proxies pueden llegar a entender la comunicacin entre los dos nodos. Clasificacin. Una posible clasificacin de las redes P2P pudiera ser acorde a su grado de centralizacin: Redes P2P centralizadas. Este tipo de red P2P se basa en una arquitectura monoltica donde todas las transacciones se hacen a travs de un nico servidor que sirve de punto de enlace entre dos nodos, y que a la vez almacena y distribuye los nodos donde se almacenan los contenidos. Poseen una administracin muy dinmica y una disposicin ms permanente de contenido, sin embargo, est muy limitada en la privacidad de los usuarios y en la falta de escalabilidad de un slo servidor, adems de ofrecer problemas en puntos nicos de fallo, situaciones legales y enormes costos en el mantenimiento as como el consumo de ancho de banda. Una red de este tipo rene las siguientes caractersticas:

Se rige bajo un nico servidor que sirve como punto de enlace entre nodos y como servidor de acceso al contenido, el cual distribuye a peticin de los nodos. Todas las comunicaciones (como las peticiones y encaminamientos entre nodos) dependen exclusivamente de la existencia del servidor. Algunos ejemplos de este tipo de redes son Napster y Audiogalaxy. Redes P2P "puras" o totalmente descentralizadas. Las redes P2P de este tipo son las ms comunes, siendo las ms verstiles al no requerir de un gestionamiento central de ningn tipo, lo que permite una reduccin de la necesidad de usar un servidor central, por lo que se opta por los mismos usuarios como nodos de esas conexiones y tambin como almacenistas de esa informacin. En otras palabras, todas las comunicaciones son directamente de usuario a usuario con ayuda de un nodo (que es otro usuario) quien permite enlazar esas comunicaciones. Las redes de este tipo tienen las siguientes caractersticas: Los nodos actan como cliente y servidor. No existe un servidor central que maneje las conexiones de red. No hay un enrutador central que sirva como nodo y administre direcciones. Algunos ejemplos de una red P2P "pura" son, Ares Galaxy, Gnutella, Freenet y Gnutella2. Redes P2P hbridas, semi-centralizadas o mixtas: En este tipo de red, se puede observar la interaccin entre un servidor central que sirve como hub y administra los recursos de banda ancha, enrutamientos y comunicacin entre nodos pero sin saber la identidad de cada nodo y sin almacenar informacin alguna, por lo que el servidor no comparte archivos de ningn tipo a ningn nodo. Tiene la peculiaridad de funcionar (en algunos casos como en Torrent) de ambas maneras, es decir, puede incorporar ms de un servidor que gestione los recursos compartidos, pero tambin en caso de que el o los servidores que gestionan todo caigan, el grupo de nodos sigue en contacto a travs de una conexin directa entre ellos mismos con lo que es posible seguir compartiendo y descargando ms informacin en ausencia de los servidores. Este tipo de P2P sigue las siguientes caractersticas: Tiene un servidor central que guarda informacin en espera y responde a peticiones para esa informacin.

Los nodos son responsables de hospedar la informacin (pues el servidor central no almacena la informacin), que permite al servidor central reconocer los recursos que se desean compartir, y para poder descargar esos recursos compartidos a los peers que lo solicitan. Las terminales de enrutamiento son direcciones usadas por el servidor, que son administradas por un sistema de ndices para obtener una direccin absoluta. Algunos ejemplos de una red P2P hbrida son Bittorrent, eDonkey2000 y Direct Connect. Otras categoras en base a la red P2P. Algunos prefieren clasificar las redes P2P en base a su estructuracin, clasificando las redes en: Redes P2P estructuradas como CAN. Redes P2P sin estructura como Gnutella. Tambin se podra clasificar las redes P2P de acuerdo a su generacin y estas son: Primera Generacin de P2P: Son literalmente las primeras redes P2P las cuales eran centralizadas. Segunda Generacin de P2P: En esta generacin se implementa por primera vez la caracterstica de la descentralizacin, siendo esta caracterstica la ms comn en los actuales P2P. Tercera Generacin de P2P: Son aquellos P2P de generacin ms reciente, que implementan una comunicacin no directa, cifrada y annima. Existe tambin la posibilidad de clasificar las redes P2P concorde a sus caractersticas de anonimidad o exclusividad como: Sin caractersticas de anonimidad. Pseudonimo. Red P2P Privada. Friend-to-friend (de amigo-a-amigo). Redes P2P sin estructura vs. Redes P2P estructuradas.

La red de sobrecapa del P2P consiste en todos los peer que participan como nodos de red. Hay enlaces entre dos nodos cualesquiera que se conozcan: es decir si un peer participante conoce la localizacin de otro peer en la red del P2P, entonces hay un borde dirigido del nodo anterior al ltimo nodo en la red de sobrecapa. En base a cmo los nodos en la red de sobrecapa se enlazan el uno al otro, podemos clasificar las redes del P2P como no estructuradas o estructuradas. Una red P2P no estructurada se forma cuando los enlaces de la sobrecapa se establecen arbitrariamente. Tales redes pueden ser construidas tan fcilmente como un peer que desea unirse a la red puede copiar enlaces existentes de otro nodo y despus formar sus propios enlaces en un cierto plazo. En una red P2P no estructurada, si un peer desea encontrar un pedazo deseado de datos en la red, la peticin tiene que recorrer toda la red para encontrar tantos peers como sea posible, para conseguir a alguien que comparta los datos. La desventaja principal con estas redes es que las peticiones no pueden ser resueltas siempre. Un contenido popular es muy probable estar disponible en varios peers y cualquier peer que busca ese contenido popular, es muy probable que encontrase lo mismo pero, si un peer est buscando datos raros o no-tan-populares compartidos por solamente algunos otros peers, despus es altamente probable que la bsqueda no sea acertada. Puesto que no hay correlacin entre un peer y el contenido compartido por l, no hay garanta que la peticin encontrar al peer que tiene los datos deseados. El flooding tambin causa una alta cantidad de sealar trfico en la red y por lo tanto tales redes tienen tpicamente una eficacia muy pobre en los resultados de bsqueda. La mayora de las redes populares P2P tales como Napster, Gnutella y KaZaA son redes P2P sin estructura. Las redes P2P estructuradas superan las limitaciones de redes no estructuradas manteniendo una tabla de hash distribuida(DHT) y permitiendo que cada peer sea responsable de una parte especfica del contenido en la red. Estas redes utilizan funciones de hash distribuido y asignan valores a cada contenido y a cada peer en la red. Despus siguen un protocolo global en la determinacin de qu peer es responsable de qu contenido. Esta manera, siempre que un peer desee buscar ciertos datos, utiliza el protocolo global para determinar el(los) peer(s) responsable(s) de los datos y despus dirige la bsqueda hacia el(los) peer(s) responsable(s). Algunas redes P2P estructuradas son: Chord. Pastry P2P Network.

Tapestry P2P Network. Content Addressable Network. Tulip Overlay. REDES CLIENTE SERVIDOR. Introduccin a la arquitectura de un sistema cliente/servidor. Diversas aplicaciones se ejecutan en un entorno cliente/servidor. Esto significa que los equipos clientes (equipos que forman parte de una red) contactan a un servidor, un equipo generalmente muy potente en materia de capacidad de entrada/salida, que proporciona servicios a los equipos clientes. Estos servicios son programas que proporcionan datos como la hora, archivos, una conexin, etc. Los servicios son utilizados por programas denominados programas clientes que se ejecutan en equipos clientes. Por eso se utiliza el trmino "cliente" (cliente FTP, cliente de correo electrnico, etc.) cuando un programa que se ha diseado para ejecutarse en un equipo cliente, capaz de procesar los datos recibidos de un servidor (en el caso del cliente FTP se trata de archivos, mientras que para el cliente de correo electrnico se trata de correo electrnico). Ventajas de la arquitectura cliente/servidor. El modelo cliente/servidor se recomienda, en particular, para redes que requieran un alto grado de fiabilidad. Las principales ventajas son: Recursos centralizados: debido a que el servidor es el centro de la red, puede administrar los recursos que son comunes a todos los usuarios, por ejemplo: una base de datos centralizada se utilizara para evitar problemas provocados por datos contradictorios y redundantes. Seguridad mejorada: ya que la cantidad de puntos de entrada que permite el acceso a los datos no es importante. Administracin al nivel del servidor: ya que los clientes no juegan un papel importante en este modelo, requieren menos administracin. Red escalable: gracias a esta arquitectura, es posible quitar o agregar clientes sin afectar el funcionamiento de la red y sin la necesidad de realizar mayores modificaciones. Desventajas del modelo cliente/servidor. La arquitectura cliente/servidor tambin tiene las siguientes desventajas:

Costo elevado: debido a la complejidad tcnica del servidor. Un eslabn dbil: el servidor es el nico eslabn dbil en la red de cliente/servidor, debido a que toda la red est construida en torno a l. Afortunadamente, el servidor es altamente tolerante a los fallos (principalmente gracias al sistema RAID). Funcionamiento del sistema cliente/servidor. Un sistema cliente/servidor funciona tal como se detalla en el siguiente diagrama:
El cliente enva una solicitud al servidor mediante su direccin IP y el puerto, que est reservado para un servicio en particular que se ejecuta en el servidor. El servidor recibe la solicitud y responde con la direccin IP del equipo cliente y su puerto. DEFINICION DE TRANSACCIONES. Una transaccin es una unidad lgica de trabajo, la cual no necesariamente consta de una sola operacin en la base de datos; ms bien, es en general una secuencia de varias de esas operaciones mediante la cual un estado consistente de la base de datos se transforma en otro estado consistente, sin conservar por fuerza la consistencia en todos los puntos intermedios. El punto importante aqu es asegurar que la base de datos regresa a un estado consistente al fin de la ejecucin de una transaccin. Una transaccin es tambin la invocacin a un procedimiento remoto (RPC) que ejecuta un conjunto de operaciones sobre una base de datos bajo el principio de todo o nada. El concepto fundamental aqu es la nocin de ejecucin consistente o procesamiento confiable asociada con el concepto de una consulta. El concepto

transaccin es usado dentro del dominio de la base de datos como una unidad bsica de cmputo consistente y confiable. TIPOS DE ACCIONES EJECUTABLES EN UNA TRANSACCION. REGLAS PARA SU EJECUCION. A fin de soportar una respuesta favorable para la ejecucin de transacciones, el DBMS (Sistema Manejador de Bases de Datos) deber de manejar el procesamiento de transacciones. Esto es, deber de garantizar que si la transaccin ejecuta algunas modificaciones y despus se presenta una falla (por cualquier razn), antes de que llegue al termino normal de la transaccin, se anularn esas modificaciones. As, o bien se lleva a cabo la transaccin en su totalidad, o se cancela en su totalidad. De esta manera puede lograrse que una secuencia de operaciones, la cual en esencia no es atmica, aparente serlo desde un punto de vista externo. El componente del sistema encargado de lograr esta apariencia de atomicidad se conoce como Manejador de transacciones, y las operaciones de COMMIT (comprometer) y ROLLBACK (retroceder) son la clave de su funcionamiento. La operacin COMMIT seala el trmino exitoso de la transaccin: le dice al manejador de transacciones que se ha finalizado con xito una unidad lgica de trabajo, que la base de datos esta (o debera estar) de nuevo en un estado consistente, y que se pueden hacer permanentes todas las modificaciones efectuadas por esa unidad de trabajo. La operacin ROLLBACK, en cambio, seala e trmino no exitoso de la transaccin: le dice al manejador de transacciones que algo sali mal, que la base de datos podra estar en un estado inconsistente y que todas las modificaciones efectuadas hasta el momento por la unidad lgica de trabajo deben retroceder o anularse. PROPIEDADES DE LAS TRANSACCIONES. Una transaccin posee cuatro propiedades fundamentales Atomicidad. Una Transaccin es una unidad de trabajo indivisible; la totalidad de sus acciones son un xito un fracaso ("todo o nada"). Consistencia. Despus de ejecuta una Transaccin debe dejar al sistema en estado correcto o debe abortarlo. Si la Transaccin no puede alcanzar un estado final debe regresar al sistema a su estado original. Aislamiento. El comportamiento de una Transaccin no se ve afectado por el hecho de que otras Transacciones puedan estar ejecutndose de manera concurrente; dicho de otra manera, una Transaccin no puede revelar sus resultados a otras Transacciones concurrentes antes de su commit. La

Transaccin debe serializar todos los accesos a recursos compartidos y garantizar que ningn programa concurrente interferir con sus operaciones respectivas. Durabilidad. Los efectos de una Transaccin son permanentes despus de su grabacin. Sus cambios deben sobrevivir a fallas del sistema. (Persistencia). Atomicidad. Se refiere al hecho de que una transaccin se trata como una unidad de operacin. Por lo tanto, o todas las acciones de la transaccin se realizan o ninguna de ellas se lleva a cabo. La atomicidad requiere que si una transaccin se interrumpe por una falla, sus resultados parciales deben ser deshechos. La actividad referente a preservar la atomicidad de transacciones en presencia de abortos debido a errores de entrada, sobrecarga del sistema o interbloqueos se le llama recuperacin de transacciones. La actividad de asegurar la atomicidad en presencia de cadas del sistema se le llama recuperacin de cadas. Consistencia. La consistencia de una transaccin es simplemente su correctitud. En otras palabras, una transaccin es un programa correcto que lleva la base de datos de un estado consistente a otro con la misma caracterstica. Debido a esto, las transacciones no violan las restricciones de integridad de una base de datos. Aislamiento. Una transaccin en ejecucin no puede revelar sus resultados a otras transacciones concurrentes antes de su commit. Ms an, si varias transacciones se ejecutan concurrentemente, los resultados deben ser los mismos que si ellas se hubieran ejecutado de manera secuencial (seriabilidad). Durabilidad. Es la propiedad de las transacciones que asegura que una vez que una transaccin hace su commit, sus resultados son permanentes y no pueden ser borrados de la base de datos. Por lo tanto, los DBMS aseguran que los resultados de una transaccin sobrevivirn a fallas del sistema. Esta propiedad motiva el aspecto de recuperacin de bases de datos, el cual trata sobre como recuperar la base de datos a un estado consistente en donde todas las acciones que han hecho un commit queden reflejadas. BITCORA La operacin ROLLBACK esta basada en el uso de una bitcora. El DBMS (Sistema Manejador de Bases de Datos) mantiene una bitcora o diario en cinta o en disco (ms comnmente), en el cual se registran los detalles de todas las operaciones de actualizacin, en particular, los valores inicial y final del objeto modificado. Por tanto, si resulta necesario anular alguna modificacin especfica,

el sistema puede utilizar la entrada correspondiente de la bitcora para restaurar el valor original del objeto restaurado. PUNTO DE SINCRONIZACION Las operaciones COMMIT y ROLLBACK establecen lo que se le conoce como punto de sincronizacin lo cual representa el lmite entre dos transacciones consecutivas, o el final de una unidad lgica de trabajo, y por tanto al punto en el cual la base de datos esta (o debera estar) en un estado de consistencia. Las nicas operaciones que establecen un punto de sincronizacin son COMMIT, ROLLBACK y el inicio de un programa. Cuando se establece un punto de sincronizacin: Se comprometen o anulan todas las modificaciones realizadas por el programa desde el punto de sincronizacin anterior. Se pierde todo posible posicionamiento en la base de datos. Se liberan todos los registros bloqueados. Es importante advertir que COMMIT y ROLLBACK terminan las transaccin, no el programa. ESTADO DE LAS TRANSACCIONES. Transaccin Comprometida Una transaccin que termina su ejecucin con xito se dice que est comprometida. Una transaccin comprometida que haya hecho modificaciones transforma la base de datos llevndola a un nuevo estado consistente, que permanece incluso si hay fallo en el sistema. En ausencia de fallos, todas las transacciones se completan con xito. Transaccin Abortada Una transaccin que no termina su ejecucin con xito se dice que est abortada. Para asegurar la atomicidad, las transacciones abortadas no deben tener efecto sobre el estado de la base de datos cualquier cambio que haya hecho la transaccin abortada debe deshacerse. Una vez deshechos los cambios de una transaccin abortada se dice que la transaccin se ha retrocedido. Transaccin Compensadora Una vez que una transaccin se ha comprometido no se pueden deshacer sus efectos abortndola slo se pueden invertir sus efectos mediante una transaccin compensadora. No siempre se puede crear una transaccin

compensadora asociada a cada transaccin a realizar queda a responsabilidad del usuario. Modelo de Transaccin Una transaccin debe estar en uno de los siguientes estados: Activa (estado inicial): la transaccin permanece en este estado durante su ejecucin. Parcialmente Comprometida: la transaccin pasa a este estado cuando acaba de realizar la ltima instruccin. Fallida: la transaccin pasa a este estado tras descubrir que no puede continuar la ejecucin normal. Abortada: la transaccin pasa a este estado despus de haber restablecido la base de datos a su estado anterior. Comprometida: la transaccin pasa a este estado tras completarse con xito. Diagrama de Estados.
TIPOS DE TRANSACCIONES Transacciones simples. Todas las operaciones se llevan acabo en el mismo nivel dentro de una T La Transaccin empieza con un begin_transaction y termina ya sea con un commit_transaction o abort_transaction. Toda la transaccin es indivisible.

En un principio las Transacciones simples fueron suficientes por su sencillez y por su adaptacin a operaciones bancarias breves. Actualmente las Transacciones han incursionado en todas las facetas de la computacin pero no han resultado lo ms adecuado, ya que tienen un comportamiento: Frgil: En transacciones de negocios que se extienden por perodos largos. Dbil: En procesamiento por lotes. Nulo: Situaciones que requieren dar marcha atrs. Una Transaccin simple no dura ms de dos o tres segundo para evitar monopolizar recursos crticos del sistema como candados sobre la base de datos. As que los programas OLTP se dividen en transacciones breves ejecutadas una tras otra para producir resultados.
Transacciones Anidadas. Ejecutar transacciones anidadas. Consiste en tener transacciones que dependen de otras, estas transacciones estn incluidas dentro de otra de un nivel superior y se les conoce como: SubTransacciones. La transaccin de nivel superior puede producir hijos (Subtransacciones) que hagan ms fcil la programacin del sistema y mejorando el desempeo.
Transacciones Distribuidas (motor de base de datos) Las transacciones distribuidas abarcan dos o ms servidores conocidos como administradores de recursos. La administracin de la transaccin debe ser coordinada entre los administradores de recursos mediante un componente de servidor llamado administrador de transacciones. Cada instancia de SQL Server Database Engine (Motor de base de datos de SQL Server) puede funcionar como administrador de recursos en las transacciones distribuidas que coordinan los administradores de transacciones, como el Coordinador de transacciones

distribuidas de Microsoft (MS DTC) u otros administradores que admitan la especificacin X/Open XA del procesamiento de transacciones distribuidas. Para obtener ms informacin, consulte la documentacin de MS DTC. Una transaccin de una sola instancia de Database Engine (Motor de base de datos) que abarque dos o ms bases de datos es, de hecho, una transaccin distribuida. La instancia administra la transaccin distribuida internamente; para el usuario funciona como una transaccin local. En la aplicacin, una transaccin distribuida se administra de forma muy parecida a una transaccin local. Al final de la transaccin, la aplicacin pide que se confirme o se revierta la transaccin. El administrador de transacciones debe administrar una confirmacin distribuida de forma diferente para reducir al mnimo el riesgo de que, si se produce un error en la red, algunos administradores de recursos realicen confirmaciones mientras los dems revierten la transaccin. Esto se consigue mediante la administracin del proceso de confirmacin en dos fases (la fase de preparacin y la fase de confirmacin), que se conoce como confirmacin en dos fases (2PC). Fase de preparacin Cuando el administrador de transacciones recibe una solicitud de confirmacin, enva un comando de preparacin a todos los administradores de recursos implicados en la transaccin. Cada administrador de recursos hace lo necesario para que la transaccin sea duradera y todos los bferes que contienen imgenes del registro de la transaccin se pasan a disco. A medida que cada administrador de recursos completa la fase de preparacin, notifica si la preparacin ha tenido xito o no al administrador de transacciones. Fase de confirmacin Si el administrador de transacciones recibe la notificacin de que todas las preparaciones son correctas por parte de todos los administradores de recursos, enva comandos de confirmacin a cada administrador de recursos. A continuacin, los administradores de recursos pueden completar la confirmacin. Si todos los administradores de recursos indican que la confirmacin ha sido correcta, el administrador de transacciones enva una notificacin de xito a la aplicacin. Si algn administrador de recursos inform de un error al realizar la preparacin, el administrador de transacciones enva un comando para revertir la transaccin a cada administrador de recursos e indica a la aplicacin que se ha producido un error de confirmacin. Las aplicaciones de Database Engine (Motor de base de datos) pueden administrar transacciones distribuidas a travs de Transact-SQL o de la API de base de datos.

Tutorial Sistemas Distribuidos

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Tutorial Sistemas Distribuidos

Caricato da

Copyright:

Formati disponibili

Sistemas Distribuidos. Introduccin Y Generalidades.

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

Sistemas Distribuidos Unidad I Y II. .

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

Sistemas Distribuidos Unidad I Y II. .

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

Sistemas Distribuidos Unidad I Y II. .

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

Sistemas Distribuidos Unidad I Y II. .

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

Sistemas Distribuidos Unidad I Y II. .

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

1 .. 126 128 .. 191 192 .. 223

Sistemas Distribuidos Unidad I Y II. .

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

Sistemas Distribuidos Unidad I Y II. .

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

Sistemas Distribuidos Unidad I Y II. .

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

Sistemas Distribuidos Unidad I Y II. .

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

Direccin de origen Direccin de destino

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

Sistemas Distribuidos Unidad I Y II. .

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

Sistemas Distribuidos Unidad I Y II. .

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

Sistemas Distribuidos Unidad I Y II. .

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

Sistemas Distribuidos Unidad I Y II. .

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

Sistemas Distribuidos Unidad I Y II. .

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

Sistemas Distribuidos Unidad I Y II. .

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

Sistemas Distribuidos Unidad I Y II. .

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

Sistemas Distribuidos Unidad I Y II. .

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

TUTORIAL DE SISTEMAS DISTRIBUIDOS.

TUTORIAL DE SISTEMAS DISTRIBUIDOS.