Sistemas 67

Introducción

Peer-to-peer es una arquitec-tura de red en la que cadacomputador tiene capaci-dades y responsabilidadesequivalentes [1], esta es la definiciónmás simple que podemos encontrar yademás nos da indicios sobre laarquitectura p2p.

Primero que todo, el hecho de quecada computador (nodo) en la redtenga capacidades y responsabilida-des implica que se trata de una reden la cual un servidor no es una parteesencial de ella (con excepcionescomo los servidores centrales confunciones como proveer el índice dearchivos).

El objetivo de este artículo es seguiruna serie de conceptos para llegar a

presentar Pastry como solución a losproblemas de una red descentraliza-da y estructurada.

El presente trabajo fue desarrolladoen el Politécnico Grancolombianocomo trabajo de aula para la materiatelecomunicaciones, bajo la asesoríadel profesor Daniel A. Torres Falko-nert.

A. Sistemas Centralizados P2P

Redes P2P y enrutamiento encapa de aplicaciónJairo A. Afanador J.Diego F. RiberoGermán E. Ulloa

Una mirada a Pastry como solución en una reddescentralizada y estructurada

t r e s

F i g u r a 1 . R e d p 2 p c e n t r a l i z a d a

En un sistema centralizado se hacenecesario tener un servidor comocentro de conexión, en la mayoría delos casos la función del servidor esalojar bases de datos con los índicesde los archivos que cada usuariotiene y almacenar las direcciones decada uno de ellos que se encuentreconectado a él. Cada vez que unusuario se conecte a la red p2p, elservidor sincroniza la informaciónde cada nodo entre cliente - servidor.

Napster, que fue pionero de la tecno-logía p2p, funcionaba de una formacentralizada. Este sistema tiene laventaja de ser muy rápido paraencontrar la información deseada, elproblema con este sistema es que siel servidor tiene algún tipo de incon-veniente o si sufre un ataque, estared dejara de funcionar.

B. Sistemas Descentralizados P2P

En una red descentralizada no sedepende de la presencia de un servi-dor para ayudar a los clientes aencontrar la información requerida ycual nodo la posee, esta responsabi-

lidad recae completamente en elconjunto de nodos que conforman lared.

Al eliminar el servidor central se eli-mina una parte clave para realizarataques a la red, la cual no dependede este punto vulnerable sino delconjunto de clientes que la confor-man.

En este tipo de redes se requiere unaforma de buscar archivos o conteni-do únicamente con ayuda de los pro-pios clientes, es así como aparecendos tipos de estructura de estasredes, estructuradas y no estructura-das.

C. Redes P2P estructuradas y no estructu-radas

Las redes P2P se pueden clasificarpor tener o no una estructura. Unared P2P estructurada es una red en laque cada cliente cuenta con su pro-pia tabla de hash (Pastry, por ejem-plo). Una tabla de Hash Distribuidaes una tabla única que tiene cadacliente, en la cual se encuentra elcamino más eficiente conocido poreste nodo para llegar a otro en la red.

A diferencia de este tipo de estructu-ra, las redes P2P no estructuradasson redes en las que a los nodos seles asignan enlaces arbitrariamente,por lo tanto cuando se ejecuta unabúsqueda, se realiza una inundacióncon la consulta. Es decir, se pide a

Figura 2. Red p2p descentralizada

68 Sistemas

todos los clientes conocidos por elnodo de origen que emprenda la bús-queda de la misma forma anterior.

Este tipo de funcionamiento tienealgunos inconvenientes como elexcesivo tráfico generado en la red,además, debido a que el alcance dela búsqueda se limita con el tiempode vida de los paquetes (TTL) no esseguro que se pueda llegar un nodocon un contenido poco difundido enla red.

I. Routing Overlays

"Un problema clave para sistemaspeer-to-peer es la colocación deobjetos de datos a través de varioshosts y la subsiguiente provisión deacceso a ellos en una manera quebalancee la carga de trabajo y asegu-re disponibilidad sin adicionarsobrecargas innecesarias" [2].

El problema principal del modelocentralizado de la primera genera-ción de arquitecturas p2p era ladependencia de una conexión con unservidor central, sin el cual, los no-dos no son consientes de la ubica-ción de sus pares, y mucho menos decuáles de ellos disponen de los obje-tos requeridos.

La idea es proveer de una capa desoftware (middleware para el casode "routing overlay") para que seausada por los diseñadores y progra-madores sin que dependan del siste-

ma de p2p que se esté usando, bus-cando que cada nodo tenga la infor-mación suficiente sobre localizaciónde una porción de pares y de objetos.

Routing overlay es un tipo de algo-ritmo implementado en la capa deaplicación, cuya función es asegurarque cada nodo encuentre el objetorequerido por él, a través de losdemás y sin la utilización de un índi-ce central. Además "… analizar al-goritmos bajo este modelo va aayudar significativamente en el dise-ño de algoritmos para redes distri-buidas modernas" [3], routingoverlays está basado en los trabajosde Plaxton en [3].

Haremos énfasis en una versión:Algoritmo de Pastry (presentado porRowstron y Druschel en [4]), estatoma la forma de un modelo tipoTabla Hash (DHT, distributed hashtable), lo que significa que se haceuso de llaves para acceder directa-mente a los datos requeridos en latabla.

II. Pastry

Pastry utiliza las características deun modelo DHT. "Cada nodo en lacubierta de red de peer-to-peer dePastry se le asigna un identificadorde nodo (nodeId) de 128-bits" [4] (oGlobal Unique IDentifier: GUID en[2]), estos identificadores son núme-ros en base 16 (hexadecimal). EnPastry se envían mensajes desde un

Sistemas 69

nodo a otro mediante un algoritmopara buscar la ruta (ver [2]). Cadanodo tiene una tabla de enrutamientoy un vector con los GUIDs e IPs desus vecinos más cercano, normal-mente se registran los ocho menoresy ocho mayores.

Cuando el nodo de interés seencuentra en este vector, se envíadirectamente el mensaje, sino se uti-liza la tabla de enrutamiento de lasiguiente forma:

Los dígitos de los GUIDs funcionancomo llaves en las tablas de enruta-miento.

La figura 3 muestra las primerasfilas de la tabla de enrutamiento(para GUIDs de 128 bits las tablastendrán 32 filas) de un nodo cuyosprimeros dígitos de su GUID son1234.

En las celdas de cada fila se hacevariar el último dígito, conservandolos anteriores que corresponden alnodo al que pertenece la tabla, asípues, en la fila cero, se tiene unavariación de 0 a F, en la uno todas lasceldas empiezan con 1 y variamosentonces el segundo digito, la fila 2tiene fijo el 12 y variamos el tercer

digito una vez mas, y continuamosasí hasta el final.

La búsqueda de los datos sobre laubicación del nodo se realiza compa-rando, hasta donde sea posible, dígi-to por dígito entre los GUIDs delnodo actual y el de destino en latabla de enrutamiento, acercándoseasí al el cada vez más, si no se puedecontinuar recorriendo la tabla delnodo actual y no se ha encontrado elGUID exacto del destino, se envía labúsqueda al nodo que se encuentreen la celda con la llave mas cercada.

Por ejemplo: En una celda A379F1se podría encontrar la IP del nodoA379F14F y podemos inferir que siel mensaje es enviado a este nodo, lacelda pertenecía a la tabla de unnodo con GUID A379FXYZ donde0?X?F tal que X?1 y 0?Y,Z?F. Ográficamente:

Si enviamos un mensaje del nodo1234 al nodo 134D, el nodo 1234busca en su tabla la celda con elGUID más cercano al deseado, comopodemos ver, no es posible que labúsqueda pase de la segunda fila, yaque los nodos comparten solamenteun digito de sus GUIDs:

0 0 1 2 3 4 5 6 … F1 10 11 12 13 14 15 16 … 1F2 120 121 122 123 124 125 126 … 12F3 1230 1231 1232 1233 1234 1235 1236 … 123F

70 Sistemas

Figura 3: Cuatro primeras filas de la Tabla deenrutamiento del nodo con GUID: 1234

0 0 1 2 3 4 5 6 … F1 10 11 12 13 14 15 16 … 1F2 120 121 122 123 124 125 126 … 12F

Figura 4: Tabla de enrutamiento del nodo 1234

Sistemas 71

GUID) en su tabla (B), y ademáspodemos asegurar que la primera filade la tabla de enrutamiento de estenodo (A) sirve como base para elnuevo nodo (por ser un nodo cerca-no en cuanto a una métrica de red), yademás: el segundo (B) y tercernodo contactado (C) comparten susegunda y tercer fila con el nuevonodo, y así sucesivamente hasta for-mar su tabla de enrutamiento com-pleta. Además, el vector de vecinosdel último nodo le sirve al nuevonodo ya que son vecinos.

Cada nodo continuamente notifica asus vecinos que está activo, si elnodo falla, los nodos en su tabladejarán de recibir la señal y asumi-rán que se presentó un error, enton-ces, actualizarán su tabla parareemplazarlo por otro nodo activo.

Por supuesto si un nodo desea aban-donar la red, este notificara volunta-riamente a los demás para quecambien sus tablas, en todas las filasde la tabla de enrutamiento exceptola ultima, se hace referencia a uno devarios nodos posibles, si existe unnodo que pueda ocupar una posicióny este se encuentra más cerca (métri-ca de red), se cambiara la tabla parahacer referencia al más cercano paramejorar la eficiencia.

Con lo anterior se tiene una idea glo-bal del funcionamiento de Pastrycomo modelo de enrutamiento. Noes el único foco de trabajo para este

La celda 13 contiene la informacióndel nodo más cercano en términos desu GUID al nodo 134D, ahorasupongamos que el GUID de lacelda 13 contiene la IP del nodo135A, nos vamos para ese nodo:

Supongamos que llegamos a la celda134 y en ella encontramos la IP delnodo 134D, aunque podríamos con-tinuar por ejemplo si se trata delnodo 134F.

Por tratarse de una estructura de tipoárbol, en Pastry se lograra llegar alnodo deseado con complejidadO(Log N).

Cuando un nodo nuevo quiere for-mar parte de la red, este adquiere supropio GUID o nodeID, luego notifi-ca de su existencia a otro nodo en suvecindad "Tal nodo puede ser locali-zado automáticamente, por ejemplo,usando "expanding ring IP multi-cast" o ser obtenido por el adminis-trador del sistema a través de canalesexternos" [4], otra opción para la ini-cialización de nodos en este y otrosmodelos similares es la propuesta decrear un "anillo universal" que pro-vea este tipo de servicios[5]. El nodocontactado (A) reenvía el mensaje alnodo más cercano (en términos de

0 0 1 2 3 4 5 6 … F1 10 11 12 13 14 15 16 … 1F2 130 131 132 133 134 135 136 … 13F3 1350 1352 1352 1353 1354 1355 1356 … 135F

Figura 5: Tabla de enrutamiento del nodo 135A

tipo de redes, pero es una aproxima-ción interesante para la solución deltipo de problemas que se puedenpresentar en las redes p2p antes des-critas.

La mayoría de estos trabajos sonrelativamente nuevos lo que haceque las implementaciones sean pocodifundidas y con algunas limitacio-nes, para el caso de Pastry se tienedisponible FreePastry [6] desarrolla-do por Rice University, Houston,USA bajo el modelo de softwarelibre.

Referencias

[1] M. Miller, Discovering P2P,San Francisco London: Sybex, 2001.[2] G. Coulouris, Distributed Sys-tems: Concepts and design. Estados

Unidos: Addison-Wesley, 2005, pp.397-430.[3] C. G. Plaxton, R. Raja-raman, y A. W. Richa. AccessingNearby Copies of Replicated Objectsin a Distribute d Environment. En Pro-ceedings of the 9th Annual ACM Sym-posium on Parallel Algorithms andArchitectures (SPAA), 1997.[4] A. Rowstron, P Druschel.Pastry: Scalable, decentralized objectlocation and routing for large-scalepeer-to-peer systems. En 18thIFIP/ACM International Conferenceon Distributed Systems Platforms(Middleware 2001). Heidelberg, Ger-many, November 2001. [5] Castro, M., Druschel, P., Ker-marrec, A., y Rowstron, A. One ring torule them all: service discovery andbinding in structured peer-to-peeroverlay networks. En Proceedings ofthe 10th Workshop on ACM SIGOPSEuropean Workshop: Beyond the PC,Saint-Emilion France. 2002.

72 Sistemas

Jairo A. Afanador J. Estudiante de Ingeniería de Sistemas del Politécnico Grancolom-biano.

Diego Fernando Ribero Nieto. Estudiante de Ingeniería de Sistemas, cuarto semestre.Líder de la célula de investigación de Java en el Politécnico Grancolombiano.

Germán Enrique Ulloa Barón. Estudiante de Ingeniería de Sistemas del PolitécnicoGrancolombiano, becado por excelencia académica. Miembro fundador del Capitulo Estu-diantil ACM del Politécnico Grancolombiano. Participante activo del circuito Redis/Acis deMaratones de programación. Integrante del equipo Yellow [marine] que participó en laXX Maratón Nacional de Programación ACM y clasificó a la Maratón Regional Surame-ricana ACM-ICPC 2006.