Clase 03: Arquitecturas de Sistemas DistribuidosLos sistemas distribuidos son comúnmente piezas complejas de software cuyo...
Clase 03: Arquitecturas de Sistemas DistribuidosLa idea básica tras el estilo arquitectónico en capas es simple: los compo...
Clase 03: Arquitecturas de Sistemas Distribuidosproceso a proceso. A esto se le conoce como desacoplamiento en el espacio ...
Clase 03: Arquitecturas de Sistemas DistribuidosFigura 3.3. Interacción general entre un cliente y un servidor.La comunica...
Clase 03: Arquitecturas de Sistemas DistribuidosSin embargo, considerando que muchas aplicaciones cliente-servidor están o...
Clase 03: Arquitecturas de Sistemas DistribuidosFigura 3.5. Organización simplificada en tres niveles diferentes de un mot...
Clase 03: Arquitecturas de Sistemas DistribuidosFigura 3.6. (a) Sistema peer-to-peer (P2P), (b) Sistema centralizado con c...
Clase 03: Arquitecturas de Sistemas DistribuidosFigura 3.7. Mapeo (asociación) de datos y nodos en el Sistema Chord.Cuando...
Clase 03: Arquitecturas de Sistemas Distribuidosconexiones entre peers no es determinada por un algoritmo. Napster es un e...
Clase 03: Arquitecturas de Sistemas DistribuidosEn un sistema BitTorrent para descargar un archivo, el usuario debe tener ...
Clase 03: Arquitecturas de Sistemas Distribuidosadaptivos, más en cuanto a su comportamiento de su ejecución y no en cuant...
Clase 03: Arquitecturas de Sistemas DistribuidosHash tables should not be confused with the hash lists and hash trees used...
Upcoming SlideShare
Loading in …5
×

Clase03

245 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
245
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Clase03

  1. 1. Clase 03: Arquitecturas de Sistemas DistribuidosLos sistemas distribuidos son comúnmente piezas complejas de software cuyos componentes estándispersos en máquinas múltiples. Si se desea tener control sobre esta complejidad, es crucial que estossistemas estén apropiadamente organizados.La organización de los sistemas distribuidos depende mayormente de los componentes desoftware que constituyen al sistema. Estas arquitecturas de software establecen como son organizadosvarios componentes del software y cómo interactúan entre ellos.La implementación de un sistema distribuido requiere de la división e identificación de loscomponentes de software y su instalación en máquinas reales. La implementación e instalación final dela arquitectura de software se conoce como arquitectura de software.Como se explicó con anterioridad, un objetivo importante de los sistemas distribuidos es separarlas aplicaciones de las plataformas subyacentes mediante una capa de middleware. La adopción de estacapa en una importante decisión arquitectónica, y su principal objetivo es proveer una distribucióntransparente de la aplicación. La transparencia de la distribución implica en muchos casos la necesidadde hacer ciertos sacrificios o concesiones, por lo que es conveniente que el middleware sea adaptable.Esta adaptabilidad también se puede lograr permitiendo que el sistema monitoree su propiocomportamiento y que tome las medidas necesarias cuando se requiera. Estos sistemas distribuidos sonorganizados frecuentemente en la forma de retroalimentación de control.3.1 Estilos ArquitectónicosPara iniciar la discusión sobre arquitecturas, se debe considerar en principio la organización de sistemasdistribuidos en componentes de software, también conocida como arquitectura de software.El estilo arquitectónico está formulado en términos de componentes, la forma en que estoscomponentes están conectados unos con otros y los datos intercambiados entre ellos. Un componentees una unidad modular con interfaces bien definidas, y que puede ser reemplazado en el sistema.Tal vez un término más complejo es el de conector, el cual generalmente es descrito como unmecanismo que media la comunicación, coordinación o cooperación entre componentes. Por ejemplo,un conector puede implementarse mediante RPCs, transferencia de mensajes o flujos de datos.Existen varias configuraciones de componentes y conectores que definen el estilo arquitectónicode un sistema distribuido. Los estilos más importantes son:• Arquitecturas en capas• Arquitecturas basadas en objetos• Arquitecturas centradas en datos• Arquitecturas basadas en eventos
  2. 2. Clase 03: Arquitecturas de Sistemas DistribuidosLa idea básica tras el estilo arquitectónico en capas es simple: los componentes están organizados enforma de capas, en la que un componente en una determinada capa puede llamar a componentes en lacapa inmediata inferior. Una observación clave es que el control generalmente fluye de capa en capa:las peticiones van de arriba abajo y los resultados de abajo a arriba, tal como se puede observar en laFigura 3.1(a).Una organización, por mucho más suelta, se tiene en arquitecturas basadas en objetos, tal comose muestra en la Figura 3.1(b). En esencia, cada objeto corresponde a lo que hemos definido comocomponente, y estos componentes están conectados mediante un mecanismo RPC. No es de sorprenderque esta arquitectura de software se adapte al modelo cliente-servidor que trataremos más adelante.Figura 3.1. (a) estilo arquitectónico en capas; (b) estilo arquitectónico basado en objetos.Las arquitecturas centradas en datos evolucionan en torno a la idea de que los procesos secomunican a través de un repositorio o medio común, ya sea pasivo o activo (ver Figura 3.2 (a)). Porejemplo, una cantidad importante de aplicaciones distribuidas en las que la comunicación se establecepor medio de un archivo compartido a través de un sistema de archivos distribuidos.En las arquitecturas basadas en eventos, los procesos se comunican esencialmente por mediode la propagación de eventos, los cuales de manera opcional pueden llevar datos consigo, tal como semuestra en la Figura 3.2 (b). Generalmente, en los sistemas distribuidos, la propagación de eventos seha asociado con lo que se conoce como sistemas publicar/subscribir (publish/subscribe systems). La ideabásica es que los procesos publican eventos tras los cuales el middleware asegura que sólo esosprocesos que se subscribieron a esos eventos, los recibirán. La ventaja principal de esta arquitectura esque los procesos están acoplados flojamente. En principio, no se requiere una referencia explícita de
  3. 3. Clase 03: Arquitecturas de Sistemas Distribuidosproceso a proceso. A esto se le conoce como desacoplamiento en el espacio o referencialmentedesacoplados.Figura 3.2. (a) arquitectura centrada en datos; (b) arquitectura basada en eventos.3.2 Arquitecturas de SistemasYa que se ha discutido brevemente sobre algunos estilos arquitectónicos comunes, se verá cómomuchos sistemas distribuidos están organizados, considerando la manera en que sus componentes desoftware fueron establecidos. El determinar que componentes de software se usarán, cómointeractuarán y cómo se distribuirán es lo que se conoce como una instancia de arquitectura desoftware, también llamada arquitectura de sistema.3.2.1. Arquitecturas CentralizadasA pesar de las diferencias en cuanto a varios aspectos de los sistemas distribuidos, solo hay un aspectoen los que muchos expertos coinciden: pensar en términos de clientes que solicitan servicios aservidores ayuda a entender y administrar la complejidad de los sistemas distribuidos.En el modelo básico cliente-servidor, los procesos en un sistema distribuido están divididos endos grupos, que posiblemente se traslapan. Un servidor es un proceso que implemente un servicioespecífico, por ejemplo, un servicio de sistema de archivos distribuido o de base de datos. Un cliente esun proceso que solicita un servicio a un servidor, enviándole una petición y subsecuentementeesperando la respuesta del servidor. La interacción cliente-servidor, también conocida como solicitud-respuesta, se muestra en la Figura 3.3.
  4. 4. Clase 03: Arquitecturas de Sistemas DistribuidosFigura 3.3. Interacción general entre un cliente y un servidor.La comunicación entre un cliente y un servidor puede ser implementada por medio de un simpleprotocolo no orientado a la conexión (sin conexión) cuando la red subyacente es suficientementeconfiable como es el caso de muchas redes de área local (LANs). En estos casos, cuando un clientesolicita un servicio, empaca simplemente el mensaje para el servidor, identificando el servicio querequiere y anexando los datos de entrada necesarios. El mensaje es posteriormente enviado al servidor.El servidor se encuentra continuamente en espera de recibir solicitudes, tras lo cual las procesa,empaqueta los resultados en un mensaje de respuesta, y finalmente envía este mensaje al cliente.Implementación de aplicaciones en capasEl modelo cliente-servidor ha sido sujeto de muchos debates y controversias a lo largo de los años. Unade las principales cuestiones es el cómo establecer una clara distinción entre un cliente y un servidor. Noes de sorprender que en muchas ocasiones esta distinción no es tan clara. Por ejemplo, un servidor deuna base de datos distribuida a través de la web puede actuar continuamente como cliente porque éstetransfiere las solicitudes a varios servidores de archivos responsables de implementar las tablas de lasbases de datos. En este caso, el servidor de base de datos por sí mismo no hace más que procesar lassolicitudes de búsqueda o filtrado. La Figura 3.4 muestra este caso.Figura 3.4. Ejemplo de servidor actuando como cliente.
  5. 5. Clase 03: Arquitecturas de Sistemas DistribuidosSin embargo, considerando que muchas aplicaciones cliente-servidor están orientadas a facilitaral usuario el acceso a la base de datos, mucha gente ha establecido una distinción entre los tres nivelessiguientes, esencialmente usando el estilo arquitectónico en capas que se vio previamente:1. El nivel de interfaz de usuario.2. El nivel de procesamiento.3. El nivel de datos.El nivel de interfaz de usuario contiene todo lo necesario para establecer una interfaz directa con elusuario, tal como la administración del despliegue de la información. El nivel de procesamientotípicamente contiene las aplicaciones. El nivel de datos administra los datos sobre los cuales se estátrabajando.Los clientes normalmente implementan el nivel de interfaz de usuario. Este nivel consiste de losprogramas que permiten al usuario final interactuar con las aplicaciones. Hay una diferenciaconsiderable en que tan sofisticada puede ser una interfaz de usuario. La más simple no es más que unasimple pantalla de caracteres.Como ejemplo considérese un motor de búsqueda en Internet. La interfaz es muy simple: unusuario introduce una cadena de palabras claves y subsecuentemente se le presenta una lista de títulosde páginas web. El extremo opuesto de la operación está constituido por una gran base de datos depáginas web, las cuales han sido extraídas e indexadas. El núcleo del motor de búsqueda es un programaque transforma la cadena de palabras claves que proporcionó el usuario en una o más peticiones debúsqueda a la base de datos. Subsecuentemente clasifica los resultados en una lista y transforma estalista en una serie de páginas HTML. Dentro del modelo cliente-servidor, esta parte de extracción deinformación es típicamente localizada en el nivel de procesamiento. La Figura 3.5 muestra estaorganización.
  6. 6. Clase 03: Arquitecturas de Sistemas DistribuidosFigura 3.5. Organización simplificada en tres niveles diferentes de un motor de búsqueda.3.2.2 Arquitecturas DescentralizadasLas arquitecturas multinivel cliente-servidor, como la del ejemplo del motor de búsqueda mostradoanteriormente, son una consecuencia directa del dividir las aplicaciones en los tres niveles: interfaz deusuario, componentes de procesamiento y datos. Los diferentes niveles corresponden directamente conla organización lógica de las aplicaciones. En muchos ambientes, el procesamiento distribuido esequivalente a organizar una aplicación cliente servidor como una arquitectura multinivel. A este tipo dedistribución se le conoce como distribución vertical. La característica relevante de una distribuciónvertical es que esta puede realizarse disponiendo componentes lógicamente diferentes en máquinasdiferentes máquinas. Una vez más, desde la perspectiva de administración del sistema, el tener unadistribución vertical puede ser una ayuda: las funciones estás lógica y físicamente divididas y distribuidasen múltiples máquinas, mientras cada máquina está configurada para trabajar óptimamente con ungrupo específico de funciones.Sin embargo, la distribución vertical es tan solo una manera de organizar aplicaciones cliente-servidor.En arquitecturas modernas, es común que la distribución de clientes y servidores sea el factor másimportante, por lo que a este forma de distribución se le conoce como distribución horizontal. En estetipo de distribución, un cliente o un server puede estar físicamente dividido en partes lógicamenteequivalentes, pero cada parte opera con su proprio conjunto integral de datos, balanceando(equilibrando) la carga del sistema. En esta sección se analizará los sistemas peer-to-peer, una de lasarquitecturas modernas que soportan la distribución horizontal.Un sistema distribuido peer-to-peer (de igual a igual), comúnmente abreviado P2P, es una arquitecturacompuesta por participantes que ponen a disposición directa de los otros participantes del sistemaparte de sus recursos (poder de procesamiento, almacenamiento de disco, ancho de banda, etc.), sin lanecesidad de una instancia de coordinación central, tales como servidores o hosts permanentes (verFigura 3.6). Desde una alta perspectiva, los peers (iguales) de un sistema P2P son todos iguales, lo quesignifica que las funciones que deben ser desarrolladas en el sistema pueden ser realizadas por todopeer participante. En consecuencia, mucha de la interacción entre los procesos participantes (peers) essimétrica, por lo tanto, los peers pueden ser a la vez tanto proveedores (servidores) como consumidores(clientes).
  7. 7. Clase 03: Arquitecturas de Sistemas DistribuidosFigura 3.6. (a) Sistema peer-to-peer (P2P), (b) Sistema centralizado con cervidorEn su concepto más amplio, los participantes de un sistema peer-to-peer pueden ser computadoras,aplicaciones, procesos, etc. A fin de desarrollar el tema de esta sección, se considerará que losparticipantes del sistema distribuido P2P son procesos que conforman una aplicación distribuida, esdecir, componentes de software.Los sistemas P2P fueron popularizados por aplicaciones para compartir archivos (file sharing), talescomo Napster. Las redes P2P para compartir archivos han inspirado nuevas estructuras y filosofías enotras áreas de la interacción humana. En tales contextos, P2P, como tal, hace referencia a una red socialigualitaria que actualmente está emergiendo en nuestra sociedad, habilitada en mucho por la Internet.Los sistemas P2P típicamente se forman dinámicamente mediante la adición de nodos (peersparticipantes). La eliminación de nodos no tiene un impacto significativo en el sistema. La arquitecturadistribuida de una aplicación P2P provee una mayor escalabilidad y servicios más robustos.En los sistemas P2P frecuentemente se implementa, a nivel de Capa de Aplicación del protocolo decomunicación, una red sobreimpuesta sobre la red física. Tal sobreimposición es usada para el indexadoo descubrimiento de los peers. En pocas palabras, la organización y optimización de la interconectividadentre los peers es implementada en la red sobreimpuesta . El contenido (información) típicamente esintercambiado directamente sobre la red IP subyacente. Existen dos tipos de redes sobreimpuestas: lasque son estructuradas y las no estructuradas.Sistemas P2P Estructurados. La conectividad en la red sobreimpuesta es fija (la organización que defineque peers se interconectan entre sí es fija). En estos sistemas, la red sobreimpuesta es construidausando procedimientos o algoritmos determinísticos. El procedimiento más usado es organizar laconectividad mediante una Tabla Hash Distribuida (DHT, Distributed Hash Table).En un sistema basado en un DHT, a cada dato se le asigna una llave aleatoria obtenida en un espacio deidentificadores (valores) muy grande; por ejemplo, podría ser un identificador de 128 o 160 bits.Igualmente, a los nodos o peers, se les asigna un identificador obtenido en este mismo espacio deidentificadores. La función crucial de un sistema basado en una DHT es implementar un esquemaeficiente y determinístico que mapee de manera única la llave asignada al dato con el identificador delnodo, basado en una métrica de distancia. Más importante aún, cuando se busca un dato específico, seproporciona la dirección de red del nodo responsable de ese dato. Efectivamente, esto se lograenrutando una solicitud de dato con el nodo responsable.Por ejemplo, en el Sistema Chord, los nodos se organizan lógicamente en un anillo de tal maneraque un dato con llave k es mapeado (asociado) a un nodo con el identificador id, el cual es el nodo conel menor identificador posible que cumple la condición id ≥ k. A este nodo se le llama sucesor de la llavek y se denota como succ(k), tal como se muestra en la Figura 3.7. Al buscar el dato con llave k, unaaplicación que corre en un nodo arbitrario llamará a la función LOOKUP(k), la cual, subsecuentemente,regresará la dirección de red succ(k). En este punto, la aplicación puede contactar el nodo para obteneruna copia del dato.
  8. 8. Clase 03: Arquitecturas de Sistemas DistribuidosFigura 3.7. Mapeo (asociación) de datos y nodos en el Sistema Chord.Cuando un nodo quiere agregarse al sistema, este empieza por generar un identificador id. Noteque el espacio de identificadores es lo suficientemente grande, por lo que el generador de númerosaleatorios es de buena calidad; es decir, la probabilidad de generar un identificador que ya ha sidoasignado a otro nodo es casi nula. Entonces, el nodo simplemente realiza una búsqueda usando id, locual resulta en la dirección de red succ(id). En este punto, el nuevo nodo simplemente contacta asucc(id) y su predecesor, y se inserta entre éstos en el anillo. Claro, en este esquema es necesario quecada nodo contenga la información sobre su predecesor. La inserción del nuevo nodo implica que cadadato cuya llave está ahora asociada al nodo id, sea transferido desde succ(id). El que el nodo idabandone el sistema es tan simple como informar a su sucesor y predecesor de su partida, y transferirtodos sus datos al nodo succ(id).Sistemas P2P No Estructurados. Estos sistemas no proveen un algoritmo para la organización yoptimización de las conexiones en la red. A continuación, se presentan los tres modelos dearquitecturas P2P no estructuradas, sin embargo es oportuno puntualizar que el primer modelo,Sistemas P2P centralizados, clasifica como la arquitectura centralizada descrita en la sección anterior; elsegundo modelo, Sistemas P2P puros, es el único modelo que podemos definir como descentralizado; eltercer modelo involucra un tercer tipo de arquitectura, la hibrida, la cual combina la arquitecturacentralizada y la descentralizada.• Sistemas P2P centralizados. Se utiliza un servidor central para indexar las funciones ycoordinar el sistema. Aunque tiene similaridades con la arquitectura estructurada, las
  9. 9. Clase 03: Arquitecturas de Sistemas Distribuidosconexiones entre peers no es determinada por un algoritmo. Napster es un ejemplo desistema no estructurado centralizado.• Sistemas P2P puros (descentralizados). El sistema consiste en únicamente en peersequipotentes. Existe sólo una capa de enrutamiento, y no hay nodos preferidos con unafunción de infraestructura especial. Gnutella y Freenet son ejemplos de sistemas P2Ppuros.• Sistemas P2P hibridos. El sistema permite la existencia de nodos especiales con unafunción de infraestructura, comúnmente llamados supernodos. Kazaa y los sistemasBitTorrent son ejemplos de sistemas P2P hibridos.3.2.3 Arquitecturas HibridasHasta el momento nos hemos concentrado en arquitecturas cliente-servidor y arquitecturas peer-to-peer. Muchos sistemas distribuidos combinan las características de ambas. Como se mencionó en lasección anterior, los Sistemas P2P Hibridos pueden ser clasificados en esta categoría arquitectónica.Para ejemplificar este caso, considérese el caso de los sistemas para compartir archivos, usando elesquema BitTorrent (ver Figura 3.8). En estos sistemas, la idea básica es que un usuario que busca unarchivo pueda descargarlo (bajarlo) en partes obtenidas de otros usuarios, hasta que todas las partesobtenidas puedan ser ensambladas para reproducir el archivo de forma integral. Un aspecto importantede este diseño es el asegurar la colaboración. En la mayoría de las aplicaciones para compartir archivos,la mayoría de los usuarios sólo descargan archivos, sin contribuir en casi nada. En un sistema BitTorrent,un archivo puede ser descargado únicamente cuando el usuario cliente también provee contenido aotro usuario.Figura 3.8. Principio de operación de un sistema BitTorrent.
  10. 10. Clase 03: Arquitecturas de Sistemas DistribuidosEn un sistema BitTorrent para descargar un archivo, el usuario debe tener acceso a un directorioglobal, el cual es un conjunto de páginas web. Este directorio contiene referencial (enlaces o links) a loque se conoce como archivos .torrent. Un archivo .torrent contiene la información necesaria paradescargar un archivo específico. En particular, se establece una referencia a lo que se conoce comotracker (rastreador), el cual es un servidor que mantiene un registro preciso de todos los nodos activosque tienen partes del archivo deseado. Un nodo activo es aquel que en el momento está descargandootro archivo. Obviamente, habrá varios trackers diferentes, aunque generalmente solo habrá uno porarchivo (o colección de archivos).Una vez que los nodos de los que se pueden descargar partes del archivo han sido identificados,el nodo del usuario que desea descargar el archivo, se vuelve activo. En este punto, este nodo seráforzado a ayudar a otros, tal vez proporcionando a otros las partes que aún no han obtenido del archivoque se está descargando. Esta regla tiene origen en la siguiente regla: si el nodo P nota que el nodo Qestá descargando más de lo que está distribuyendo (subiendo) a otros, P puede decidir reducir lavelocidad a la que le envía información (parte de un archivo, en este caso). Este esquema trabaja bien,siempre que P tenga algo que descargar de Q. Por esta razón, los nodos obtienen referencias a muchosotros nodos, lo cual los sitúa en una mejor posición para negociar datos.3.3 Arquitectura v.s. MiddlewareCuando se consideran los aspectos arquitectónicos que se han considerado hasta el momento, uno debepreguntarse dónde entra el middleware. Como se enseño en clases pasadas, el middleware forma unacapa entre las plataformas de aplicación y distribución. Un propósito importante es proveer un ciertonivel de transparencia en la distribución, ocultando en lo posible la distribución de datos, elprocesamiento y el control de la aplicación.Lo que comúnmente pasa es que el middleware sigue un estilo arquitectónico específico. Porejemplo, muchos sistemas de middleware han adoptado un estilo arquitectónico basado en objetos,tales como CORBA; otros, como TIB/Rendeznous, siguen el estilo arquitectónico basado en eventos.El moldear el middleware a un estilo arquitectónico específico tiene la ventaja de diseñar aplicacionesmás simples. Sin embargo, una desventaja es que el middleware puede volverse dejar de ser óptimopara lo que el desarrollador tenía en mente.Aunque se supone que el middleware tiene como propósito transparentar la distribución,generalmente se requiere que el middleware se adapte a las aplicaciones. Una solución sería desarrollarvarias versiones del middleware y otra sería el crear middleware fácilmente configurable y adaptable,según lo requiera la aplicación.3.4 Autoadministración en Sistemas DistribuidosLos sistemas distribuidos y el middleware asociado a ellos requieren proveer soluciones generalesorientadas a crear un escudo contra condiciones indeseables inherentes a la red, de tal manera quepuedan brindar soporte a tantas aplicaciones como sea posible. Los sistemas distribuidos deben ser
  11. 11. Clase 03: Arquitecturas de Sistemas Distribuidosadaptivos, más en cuanto a su comportamiento de su ejecución y no en cuanto a los componentes desoftware que lo conforman.Cuando se requiere de adaptación automática, existe una fuerte interrelación entre las arquitecturas delsistema y las arquitecturas del software. Por otro lado, se requiere organizar los componentes de unsistema distribuido en tal forma que se pueda implementar el monitoreo y ajuste del sistema; tambiéndecidir dónde deben ejecutarse los procesos para facilitar la adaptabilidad.Conceptos:Plataforma: Generalmente se refiere a la combinación hardware – sistema operativo que determina lasprincipales características computacionales de una computadora.Aplicaciones distribuidas: Aplicaciones de software que consisten en varias partes o componentes queson distribuidos en un sistema distribuido y que se intercomunican entre sí para lograr el objetivo de laaplicación.HASH TABLES:In computer science, a hash table or hash map is a datastructure that uses a hash function to efficiently mapcertain identifiers or keys (e.g., person names) toassociated values (e.g., their telephone numbers). Thehash function is used to transform the key into the index(the hash) of an array element (the slot or bucket) wherethe corresponding value is to be sought.Ideally the hash function should map each possible keyto a different slot index, but this ideal is rarelyachievable in practice (unless the hash keys are fixed; i.e. new entries are never added to thetable after creation). Most hash table designs assume that hash collisions — pairs of differentkeys with the same hash values — are normal occurrences and must be accommodated in someway.In a well-dimensioned hash table, the average cost (number of instructions) for each lookup isindependent of the number of elements stored in the table. Many hash table designs also allowarbitrary insertions and deletions of key-value pairs, at constant average (indeed, amortized[1])cost per operation.[2][3]In many situations, hash tables turn out to be more efficient than search trees or any other tablelookup structure. For this reason, they are widely used in many kinds of computer software,particularly for associative arrays, database indexing, caches, and sets.
  12. 12. Clase 03: Arquitecturas de Sistemas DistribuidosHash tables should not be confused with the hash lists and hash trees used in cryptography anddata transmission.

×