Proyecto “Estudio y Definición de Protocolos Compañero a

Compañero para Soportar Servicios Distribuidos sobre Internet”

Reporte de Investigación
Septiembre/2003

ÍNDICE DISTRIBUIDO SOBRE UNA RED COMPAÑERO A COMPAÑERO

PARA BÚSQUEDAS POR CONTENIDO DE DOCUMENTOS
1
Tolosa, Gabriel ; Bordignon, Fernando y Peri, Jorge
{tolosoft, bordi, jperi)@unlu.edu.ar
Universidad Nacional de Luján
Departamento de Ciencias Básicas

Resumen

Los sistemas compañero a compañero (P2P) existentes de mayor utilización y desarrollo están
destinados al intercambio de archivos entre usuarios finales. Gnutella fue el primero de esta naturaleza,
pero presenta problemas de escalabilidad y eficiencia. Otras propuestas se basan en la construcción de
tablas de dispersión distribuidas sobre las que se mapean recursos y nodos. Son más escalables pero – en
general – no tienen en cuenta la heterogeneidad, el dinamismo de la red y no brindan flexibilidad. Cuando
se requiere indexar el contenido de documentos de texto, y no solo sus metadatos, estos sistemas
presentan limitaciones.

Se presenta un modelo que soporta la indexación completa de documentos y la distribución de los

términos sobre una red P2P. Se divide el índice invertido de términos y nodos de acuerdo a las letras del
alfabeto, es decir, diferentes nodos serán responsables de la parte del índice que corresponde a los
términos de una determinada letra. Un protocolo de búsqueda permite reducir el espacio de resolución de
una consulta sobre el índice.

El modelo pretende brindar tolerancia ante fallas, alta disponibilidad, escalabilidad y estabilidad. Los
estudios preliminares indican que el modelo es válido y brinda un mecanismo de búsqueda más expresivo,
el cual puede servir como base para una infraestructura de búsquedas sobre Internet.

Se presentan los resultados preliminares de las pruebas realizadas mediante simulación que
permiten validar el modelo. Además, se están realizando pruebas de eficiencia para determinar el costo de
operación y las restricciones a imponer para el desarrollo de un prototipo en un ambiente real.

1
Becario categoría iniciación. Secretaría de Investigación y Postgrado. Universidad Nacional de Luján
1 – Introducción

Las redes compañero a compañero (P2P) son una tema de investigación que se ha desarrollado de
manera sostenida durante los últimos años, principalmente desde la aparición de Gnutella [BOR00, DSS00]
en el año 2000. Como infraestructura de soporte de comunicaciones, una red P2P permite construir
sistemas de información distribuidos de forma descentralizada, a partir de los recursos disponibles de cada
uno de los nodos que forman la red.

Sobre este tipo de sistemas se desarrollaron diferentes servicios distribuidos como sistemas de
archivos, servicios de directorio y procesamiento. Sobre estas ideas base se han desarrollado proyectos
cuyo objetivo es la construcción de sistemas de localización de recursos dentro de una red compañero a
compañero, sistemas de ruteo de consultas, de distribución de metadatos y – en menor medida – sistemas
de búsquedas a partir del contenido de documentos.

Algunas propuestas utilizan enfoques híbridos [YAN01a] con servidores centralizados y técnicas de
resumen para reducir la cantidad de información intercambiada entre los nodos [BAW03]. Otros enfoques se
basan en la utilización de tablas de dispersión distribuidas en las cuales se pueden mapear nodos y
recursos sobre un único espacio n-dimensional de identificadores. Si bien permiten mayor escalabilidad, en
general, no tienen en cuenta la heterogeneidad, el dinamismo de la red y no brindan flexibilidad en cuanto a
las capacidades de búsqueda. Cuando se requiere indexar completamente documentos de texto estos
sistemas presentan serias limitaciones. Los proyectos más relevantes que utilizan este enfoque son Chord
[DAB01], CAN [RAT01] y Pastry [ROW01].

Sin embargo, algunos investigadores del área han reconocido las limitaciones de estos sistemas
para la recuperación de información [CHA03] a partir del contenido completo de los documentos de texto y
proponen continuar la investigación en redes P2P de las características básicas de Gnutella.

En este trabajo se presenta un modelo que soporta la indexación completa de documentos y la

distribución de los términos sobre una red P2P. Se divide el índice invertido de términos y nodos de acuerdo
a las letras del alfabeto, es decir, diferentes nodos serán responsables de la parte del índice que
corresponde a los términos de una determinada letra.

Se presentan los resultados preliminares de las pruebas realizadas mediante simulación que
permiten validar el modelo y una comparación de tráfico generado contra Gnutella para resolver una
consulta genérica.

2 – Propuesta

Sobre una red p2p se disponen un conjunto de n nodos los cuales poseen documentos para
compartir con los demás usuarios del sistema. De cada documento el nodo extrae un conjunto de términos
significativos que lo representan, que deberán ser publicados en algunos nodos de la red. La selección de
los nodos a donde se publicará cada término dependerá de la letra inicial del término, por ejemplo, para
publicar el término “colina” se enviará un mensaje de publicación a un nodo que tenga bajo su dominio la
parte del índice correspondiente a la letra “C”.

Cada nodo debe mantener una tabla de contactos con – al menos – una dirección de un nodo índice
por letra (la dirección del nodo estará compuesta por dirección IP + puerto TCP del servicio), es decir, la
tabla de contactos contendrá 26 entradas (letras de la A a la Z). Por ejemplo:

L Dirección del nodo

A 646; 125
B 154
… Nnn
Y 147; 287; 156
Z 200; 874

Luego, cada nodo que maneje una letra deberá tener una porción del índice invertido donde se
asocie el término indexado con la lista de nodos que contienen documentos con el mismo. Por ejemplo, la
porción de índice para la letra “C” podría ser la siguiente:
Términos Nodos
Casa 154; 165; 947; 877
Colina 472; 554; 489
Corona 587; 154; 554; 145
…
…

El proceso completo requiere a) seleccionar los documentos a compartir, b) seleccionar de los

documentos los términos representativos (indexación local), c) publicar los términos en los nodos
correspondientes y d) actualizar o confirmar la publicación. Luego de este proceso el sistema cuenta con
información distribuida para soportar el servicio de consulta.

3 – Ingreso de nodos a la red

Para acceder a la red, un nodo X debe conocer la dirección de – al menos – otro nodo participante P
y establecer un contacto con éste. Luego de aceptada la conexión, es necesario determinar si X va a operar
como parte del índice distribuido y – en caso afirmativo – es necesario determinar qué letra del alfabeto le
corresponde ya que existirán en la red más de un nodo que maneje la misma letra.

La determinación de si un nodo opera como índice ó no se realiza mediante una función

probabilística que toma como parámetro un valor que pondera los recursos con que cuenta el nuevo nodo X
para tal tarea, por ejemplo: potencia de CPU y ancho de banda de su red. A continuación, P revisa su tabla
de ruteo buscando entradas vacías (ej(TR) = {}), es decir, letras para las cuales a P le falta la dirección de
un nodo índice. Si posee entradas vacías asigna la letra correspondiente a la primera de ellas al nodo X,
Letra(ej (TR)). En el caso que no posea entradas vacías P selecciona una letra aleatoriamente de aquellas
entradas que no se encuentren completas y la asigna al nodo X. Se define que existirá una cantidad
máxima de contactos por letra. Cuando se complete la tabla no se asignará letra alguna al nuevo nodo.

Aquí se debe tener en cuenta que se ha tomado que las letras ocurren todas con la misma
probabilidad (P(l)) = 1/26. Una implementación más precisa requiere de un estudio de la distribución de las
palabras por idioma para determinar la frecuencia de aparición de cada letra en palabras de un alfabeto en
particular. El algoritmo para la asignación de índice a un nodo se describe en la Figura 1.

Si (ManejarIndice(P(ndx) ) {
Si (TablaIncompleta) {
LT = SeleccionarLetraEntradaVacía
AsignarLetra(LT)
}
sino {
LT = SeleccionarLetraAlAzar(P(l))
}
}
sino {
LT = “”
}
Retornar LT
Figura 1 – Algoritmo para la asignación de índice a un nodo

Luego de asignada – o no – la letra correspondiente a una parte del índice, P envía a X su tabla de
ruteo para brindarle información que le permita operar dentro de la red. Con la información de la tabla el
nuevo nodo se contacta con los otros nodos que se encargan de la misma letra, anuncia su presencia e
intercambian tablas de contactos. Esta situación le permite a X completar e incrementar la información en su
tabla inicial obtenida de P. El gráfico 1 muestra un ejemplo de un conjunto de nodos con sus tablas de
contactos.
 TC
244 A 100, 105
TC 100 “A” B 100
A 105, 244 “B” C 102
B 140 …
C 102
…

TC
105 A 244, 342
“A” B 100
C 102
TC 140 …
A 105, 244 “B”
B 100
C 102, 133 TC
… 133 A 105
“C” B 100
C 102, 146
…

Gráfico 1 – Ejemplo del estado de las tablas de contactos

4 – Publicación de términos

Cuando un nodo accede a la red – independientemente si es responsable de una parte del índice ó
no – seguramente cuente con un conjunto de documentos que se desean compartir con el resto de los
participantes. Para permitir a los demás nodos realizar búsquedas basadas en el contenido de sus
documentos primero debe realizar el proceso de indexación local y extraer los términos más relevantes de
los mismos. Aquí resulta importante aplicar técnicas del área de recuperación de información para
determinar – por ejemplo, por frecuencia de aparición o posición dentro del documento – el conjunto a
publicar. Esto tiene como objetivo reducir la cantidad de términos de manera de que el proceso de
publicación resulte eficiente.

Una vez seleccionados los términos se agrupan por letra inicial y se selecciona de la tabla de ruteo
un nodo Si,l encargado de la parte del índice correspondiente a la letra correspondiente. Al nodo Si,l se le
envía un mensaje de publicación anunciando el término o los términos por los cuales puede resolver
consultas.
TC
244 A 100, 105
3 – p(100, “árbol”) “A”
TC 100 B 100
A 244, 105 “B” C 102
B 140 …
C 102, 165 4,6
T:casa, árbol TI
…
árbol 100, 140
… …
… …

TC
105 A 244, 342
1 – p(100, “casa”) “A” B 100
C 102
5 – p(140, “árbol”) …

TC
102 A 105
TC 140 7 – p(140, “colina”) “C” B 100
A 244 “B”
C 102, 146
B 100
…
C 102, 133
… T: árbol, colina, bota
TI
2,8
casa 100
 Gráfico 2 – Proceso de publicación de términos

En el gráfico 2 se muestra el proceso de publicación. En este ejemplo existen dos nodos con
términos a publicar. El nodo 100, con los términos “casa” y “árbol” y el nodo 140 con los términos “árbol” y
“colina”. El nodo 100 requiere publicar el primer término para lo cual revisa su tabla de rutas y en la entrada
para la letra “C” posee dos direcciones: 102 y 165. Toma la primera y envía al nodo un mensaje de
publicación del término “casa” (paso 1). El nodo receptor verifica que la inicial del término corresponde con
la letra de la cual es responsable e incluye una entrada en su tabla de índice (TI) (paso2). A continuación, el
nodo 100 repite el proceso para el término “árbol”. En este caso envía el mensaje de publicación al nodo
244 (paso 3) el cual agrega la entrada en su TI correspondiente (paso 4).

Este proceso se repite para el nodo 140 que requiere publicar los términos “árbol”, “colina” y “bota”.
En este caso se enviarán mensajes de publicación a los nodos 244 y 102 respectivamente (pasos 5 a 8)
para los dos primero, mientras que por el término “bota” se realizará una publicación en la TI local debido a
que el nodo 140 es responsable de parte del índice correspondiente a la letra “B”.

5 – Resolución de consultas

Cuando un nodo requiere resolver una consulta por un conjunto de términos debe utilizar la
información de su tabla de contactos para identificar los nodos responsables del índice que le corresponde a
cada uno de dichos términos.

Por ejemplo, supóngase que en el nodo 105 se requiere resolver la consulta por los términos “árbol”
y “colina”. En primer lugar, se consulta la tabla de contactos local para obtener las direcciones de los nodos
responsables de los índices (NI) por las letras iniciales de cada término:

NIA = consulta(TC, “árbol”) ? NIA = {244, 342}

NIc = consulta(TC, “colina”) ? NIc = {102}

A continuación, se consulta a los NI correspondientes. En el gráfico 3 se muestra este proceso.

Dado que existen dos NI para la letra “A”, en este caso se seleccionó solamente el primero debido a que
aquí se presenta la idea básica del proceso. Una versión optimizada puede operar de manera similar a las
técnicas de “random walk” y “k-walker” [LVQ02] sobre los NI.

TC TI
244 A 100, 105
100 “A” árbol 100, 140
TC B 100 … …
A 244, 105 “B” C 102 … …
B 140 …
C 102, 165
…
1) q(“árbol”)

2) r = 100, 140

TC
105 A 244, 342
“A” B 100
5) q(“árbol” y “colina”) C 102
3) q(“colina”) …

6) r = {lista docs}
140 4) r = 140
TC
A 244 “B”
TR
B 100 102 A 105
C 102, 133 “C” B 100
…
C 102, 146
TI …
casa 100
colina 140
… …
 Gráfico 3 – Proceso de consulta

En el paso 1 se realiza una consulta al nodo 244 por direcciones de nodos que publicaron contener
el término “árbol” y se obtiene un conjunto respuesta surgido de la tabla de índice del nodo 244 (paso 2).

R(“árbol”) = consulta(244, “árbol”) ? R(“árbol”) = {100, 140}

De manera similar, se consulta al nodo 102 con el término “colina” y se obtiene un nuevo conjunto
respuesta (pasos 3 y 4).

R(“colina”) = consulta(102, “colina”) ? R(“colina”) = {140}

Como la consulta corresponde a una conjunción de ambos términos, la respuesta final se obtiene
calculando la intersección de los dos conjuntos de respuestas parciales:

R = R(“árbol”) ? R(“colina”) ? R = {140}

Esto significa que el nodo 140 ha publicado de manera distribuida (en dos nodos en este caso) que
contiene ambos términos en uno o varios documentos, pero no asegura que los contenga dentro de un
mismo documento. El paso posterior es enviar un mensaje al nodo 140 por la expresión de consulta
completa (pasos 5 y 6).

Si los resultados obtenidos no son satisfactorios, se puede continuar el proceso consultando a otros
nodos conocidos por letra, es decir, continuar la misma contra los demás nodos existentes en la tabla de
ruteo. En el ejemplo anterior, la única posibilidad – debido al estado de las tablas de ruteo – es que el nodo
105 consulte al nodo 342 por el término árbol y repita el proceso. Esta técnica es similar a la conocida en el
área de inteligencia artificial como iterative deepening [RUS95] y permite mantener control sobre la
búsqueda ya que permite definir cuando continuar o detenerla de acuerdo a un nivel de satisfacción de las
respuestas.

6 – Experimento por Simulación

A los efectos de validar la propuesta se construyó una simulación de una red compañero a
compañero implementando el algoritmo de asignación de índice por letras utilizando diferentes valores de la
probabilidad de que un nodo sea índice P(ndx). Se tomó como base de la simulación una red de 10000
nodos y un alfabeto completo de 26 letras. La cantidad de nodos se estableció sobre la base de la Ley de
los Grandes Números para tener una probabilidad alta (P) de que las frecuencias relativas y la media
discrepen – respectivamente – de la probabilidad teórica (p) y del valor esperado en un ? suficientemente
pequeño, resultando:

p = 0,5 P = 0,95 ? = 0,0225 n ? 9876 ? n = 10000

Se estableció un comportamiento binomial para el algoritmo de elección de índices ya que en

principio un nodo puede (o no) ser responsable del índice con probabilidad P(ndx) y luego se selecciona la
letra mediante una Ley de Distribución Discreta de eventos equiprobables (la probabilidad de elegir una letra
cualquiera es 1/26). Aunque los experimentos han sido realizados con diferentes probabilidades P(ndx), la
varianza binomial p * (1 - p) alcanza su máximo valor cuando p = 0,5. Se toma entonces n superior a (0,25) /
2
(1 - P) * (?) . Se eligió P = 0,95 como valor de "confianza" de que la distancia entre las frecuencias relativas
y la probabilidad teórica – así como entre la media y el valor esperado – no será superior a un ? elegido
inferior a 0,025.

Luego de definidos los 10000 nodos con las asignaciones correspondientes de letras del índice, se
generaron aleatoriamente entradas en las tablas de rutas de cada uno. En un primer experimento se eligió
como cantidad máxima de nodos por entrada en tabla de rutas qnmax = 3, tal que 1 ? qnmax ? 3.
 Se realizaron 20 repeticiones de cada experimento para probabilidades de que un nodo sea índice
P(ndx) = 0.125, 0.25, 0.375, 0.50, 0.625, 0.75 y 0.875. Los resultados observados se contrastaron con los
esperados (teóricos) mediante un test chi-cuadrado con un nivel de significación 0,05 (la probabilidad de
aceptar la hipótesis es 0,95) y un análisis de varianzas. En ambos casos, no existieron diferencias
significativas entre los valores entregados por la simulación y los teóricos calculados sobre la base de la
distribución de probabilidades, con lo cual se verifica la validez del método de simulación y la aleatorización
de la distribución de nodos y letras.

4 – Resultados

A partir de las muestras obtenidas se obtuvo la distribución promedio de nodos por letra para los
diferentes valores de P(ndx), resumidos en la tabla 1 y expuestos en el gráfico 4.

p(ndx) Media
0,125 47
0,25 95
0,375 144
0,5 192
0,625 243
0,75 288
0,875 337
Tabla 1 – Distribución promedio de letras según p(ndx)

450
Cantidad Promedio de Nodos por Letra

400

350

300

250

200

150

100

50

0
0,125 0,25 0,375 0,5 0,625 0,75 0,875
p(ndx)

Gráfico 4 – Distribución promedio de letras según p(ndx)

Se calculó para cada letra la cantidad de nodos que – en promedio – seleccionaron un mismo nodo
índice (Qnil), que surge del cociente entre la cantidad de nodos por letra (Qn) sobre la cantidad total de
nodos elegidos por letra en tablas de ruteo (Qnrt) de los 10000 nodos de la red. En la tabla 2 se muestra un
ejemplo para corrida de la simulación con P(ndx) = 0.25.

L Qn Qnrt Qnil L Qn Qnrt Qnil

A 92 19935 216,68 N 92 19966 217,02
B 107 20019 187,09 O 92 20087 218,34
C 96 19944 207,75 P 97 19973 205,91
D 81 20021 247,17 Q 89 19909 223,70
E 83 19934 240,17 R 91 20086 220,73
F 102 20019 196,26 S 89 19991 224,62
G 87 19863 228,31 T 102 19924 195,33
H 113 19940 176,46 U 106 19916 187,89
I 102 19984 195,92 V 68 19926 293,03
J 105 20075 191,19 W 95 19910 209,58
K 90 19918 221,31 X 108 19793 183,27
L 95 20107 211,65 Y 100 20077 200,77
M 86 19994 232,49 Z 88 20070 228,07
Tabla 2 – Distribución de nodos por letra, índices elegidos
y la cantidad de nodos elegidos por letra para P(ndx)=0.25

Nótese – a modo de caso ejemplo – que existen en la red 92 nodos que se encargan de manejar la
parte del índice correspondiente a la letra “A”. Esos 92 nodos fueron seleccionados 19935 veces por los n
nodos de la red en sus tablas de rutas (el máximo posible es 30000 ya que puede haber hasta 3 entradas
por letra en cada nodo). Un resumen de los promedios de la ejecución completa de la simulación se
presenta en la tabla 3 y el gráfico 5.

p(ndx) Qnil
0,125 436,2
0,25 211,25
0,375 140,4
0,5 104,5
0,625 82,93
0,75 69,6
0,875 59,35
Tabla 3 – Promedio de nodos por índice por letra

Cabe mencionar que los recursos computacionales necesarios para procesar eficientemente la
información según los nodos de la tabla 3 es un punto a evaluar puntualmente. Por ejemplo, si se tienen en
promedio 200 documentos por nodo [OSO02] donde cada uno de éstos tiene 100 términos específicos (no
comunes a otros) de una letra y se toman 10 bytes como longitud promedio de cada uno se requieren
aproximadamente 80 MB de almacenamiento secundario para la parte del índice correspondiente a cada
nodo. Esto es una limitante para que un nodo cualquiera pueda manejar o no una parte del índice
distribuido.

450

400
Cant.nodos por índice por letra

350

300

250

200

150

100

50

0
0,125 0,25 0,375 0,5 0,625 0,75 0,875
p(ndx)
 Gráfico 5 – Cantidad de nodos que – en promedio – seleccionaron cada nodo índice por letra

Evaluación inicial de tráfico generado

Para una evaluación inicial del ancho de banda utilizado por el modelo propuesto para la operación
de consulta se tiene:

Longitud Identificador de nodo (Li) = 32 bits (4 bytes)

Longitud promedio término (Lt ) = 80 bits (10 bytes)
Longitud encabezado PDU (Le) = 160 bits (20 bytes)

Costo total de una consulta

por un término a un índice (Cct ) = 2 * Le + Cq + Cr

Donde:
Cq = Lt
Cr = Qnil * p(ni, t) * Li

p(ni, t) = Probabilidad de que el nodo ni tenga el término t

Luego, el costo total Ct resulta = Cct + Cci

Donde:
Cci = Lt * Qni + Lc * Qnr

Qni = Cantidad de nodos índice consultados

Qnr = Cantidad de nodos en la respuesta
Lc = Longitud de la consulta completa

Inicialmente, se tomó p(ni, t) = 0,5 a partir de suponer optimistamente que la mitad de los nodos que
publicaron en un índice poseen documentos con el término t (tabla 4). Luego, en el gráfico 6 se muestra
comparativamente el costo de una consulta a un índice para diferentes Qnil y p(ni, t).

P(ndx) Qnil P(ni, q) Cr Cct (bytes)

0,125 436 0,5 872 922
0,25 211 0,5 423 473
0,375 140 0,5 281 331
0,5 105 0,5 209 259
0,625 83 0,5 166 216
0,75 70 0,5 139 189
0,875 59 0,5 119 169
Tabla 4 – Cálculo de costo de consulta a un índice
 1600,00

1400,00

1200,00

1000,00
bytes

800,00

600,00

400,00

200,00

0,00
0,25
0,27
0,29
0,31
0,33
0,35
0,37
0,39
0,41
0,43
0,45
0,47
0,49
0,51
0,53
0,55
0,57
0,59
0,61
0,63
0,65
0,67
0,69
0,71
0,73
0,75
p(ni, q)

Qnil 436 211 140 105 83 70 59

Gráfico 6 – Costo comparativo de una consulta a un índice según diferentes Qnil y p(ni, t)

Comparación con Gnutella

Suponiendo valores típicos de una consulta Gnutella [RIT01] – donde una consulta tiene 83 bytes
(incluyendo encabezados TCP e IP) – la cantidad de bytes generados para alcanzar la misma cantidad de
nodos en este modelo resulta:

Cq = 83 bytes

Se requieren 83 bytes por término de la consulta para alcanzar – en promedio – la cantidad de

nodos especificada en la tabla 7 para diferentes valores de p(ndx). Por ejemplo: con p(ndx) = 0,125 se
alcanzan 436 nodos con una consulta de 83 bytes. En Gnutella, para obtener un alcance similar (484 nodos)
se requiere de 4 conexiones por nodo con TTL = 5, lo que genera 40.172 bytes.

Debido a que en [RIT01] se tomaron 18 bytes como expresión de consulta, para acercar la
comparación se suponen 2 términos en la expresión, lo que generaría 2 mensajes de consulta, es decir, 166
bytes. Aquí también se supone el peor – y más común – de los casos donde cada término comienza con
una letra diferente. Suponiendo que se desea un mayor alcance, se pueden realizar consultas recurrentes a
mayor cantidad de nodos índice por letra, teniéndose que cada 166 bytes se alcanzan 436 nodos.

En el gráfico 7 se muestra la relación entre la cantidad de nodos alcanzados y los bytes utilizados
por Gnutella y el modelo propuesto. En este caso se tomaron diferentes valores de P(tr) que representa la
probabilidad de que un nodo del índice contenga el término buscado. Esta situación modifica el valor Qnr de
la expresión de costo total. Para la comparación se tomaron los siguientes valores:

Cci = Lt * Qni + Lc * Qnr

Qnr = Cantidad total de nodos por índice * P(tr)

Lc = 70 bytes (20 bytes de encabezado IP, 20 bytes de encabezado TCP, 10 de
encabezado de protocolo, 20 bytes de términos de consulta)

En el gráfico 8 se muestra una comparación directa entre la cantidad de bytes utilizada por Gnutella
y el modelo propuesto para P(tr) = 0,25.
 1000000
900000
800000
700000
600000
Bytes

500000
400000
300000
200000
100000
0
2
6

44
80

52

24
60
96
32

04

76
12
48
84
20

92
08

16

88

68

40

56

8
87
43

02
17
21

30

39
43
47
52

61

69
74
78
82
87

95
13

26

34

56

65

91

10
Cant.nodos alcanzados

P(tr)=1 P(tr)=0,75 P(tr)=0,5 P(tr)=0,25 Gnutella

Gráfico 7 – Nodos alcanzados según bytes utilizados

1000000
900000
800000
700000
600000
Bytes

500000
400000
300000
200000
100000
0
2

44

16

88

60
96

68

40

12

84
20
56
92
6

08

80

52

24

32

04

76

48

8
87
43

02
17

26

34

43
47

56

65

74

82
87
91
95
13

21

30

39

52

61

69

78

10

Cant.nodos alcanzados

P(tr)=0,25 Gnutella

Gráfico 8 –Nodos alcanzados y bytes utilizados

por Gnutella y el modelo propuesto con P(tr) =0,25
5 – Discusión

El modelo propuesto presenta algunos aspectos interesantes a evaluar. En primer lugar se puede
observar que el costo de una consulta resulta más eficiente en Gnutella. Por ejemplo, si se presume que el
25% de los nodos que publicaron en un índice pueden satisfacer una consulta, la optimización es
aproximadamente un 80%.

Por otro lado, es necesario evaluar el costo de publicación de los términos en los nodos índice. Si
bien esta actividad introduce tráfico extra, se presume que una vez estabilizado el contenido del índice las
búsquedas serán actividades más frecuentes que las actualizaciones de índices.

Si bien la comparación se realizó con Gnutella, hay que tener en cuenta que el modelo propuesto
permite la indexación completa de documentos y soporta búsquedas por términos y solamente por el
nombre de un recurso. Además, se utilizaron valores típicos de tráfico en experimentos de análisis de
Gnutella pero es posible y necesario ajustar tales valores a los requerimientos del modelo, que – al ser
menores – redundarán en una mejora de las prestaciones.

Los resultados iniciales son alentadores y brindan una base para continuar con el desarrollo del
modelo propuesto. En especial se considera necesario una evaluación del mecanismo de búsqueda desde
el punto de vista de un sistema de recuperación de información. En particular, se debería realizar pruebas
empíricas que permitan estimar valores adecuados para las probabilidades intervinientes como p(ni, q) y
P(tr) y los valores de la cantidad de nodos por entrada en la tabla de contactos (que en los experimentos se
fijó en 3).

Por último, se considera que en el análisis final se debe tener en cuenta el valor de contar con una
infraestructura que soporte indexación completa de documentos y búsquedas sobre un índice distribuido,
situación que resulta difícil de cuantificar.

6 – Trabajos Futuros
Sobre la base del modelo propuesto, los experimentos iniciales y los resultados obtenidos se
propone realizar pruebas empíricas exhaustivas que permitan establecer un mecanismo de evaluación de la
performance global del sistema y sus posibilidades.

Además, propone estudiar y verificar un conjunto de optimizaciones que permitirían aumentar la

eficiencia de los procesos de publicación y búsqueda. Por ejemplo, se plantea la posibilidad de incluir una
funcionalidad extra en algunos nodos para almacenar información acerca de direcciones de contactos
responsables de diferentes partes del índice distribuido. Esta posibilidad permitiría aumentar la completitud
de las respuestas. En el mismo sentido, se plantea la utilización de técnicas de compresión para reducir el
tráfico generado.

Finalmente, se realizará un análisis del sistema desde la perspectiva del proceso de recuperación
de información, con el objetivo de analizar cualitativa y cuantitativamente el resultado de las búsquedas.

7 - Bibliografía

[ASV02] Asvanund, A.; Clay, K.; Krishnan, R.; Smith, M. "An Empirical Analysis of Network
Externalities in Peer-To-Peer Music Sharing Networks”. International Conference on
Information Systems (ICIS). 2002.

[BAW03] Bawa, M.; Bayardo, R.; Rajagopalan, S.; Shekita, E. “Make it Fresh, Make it Quick –
th
Searching a Network of Personal Web Servers”. En 12 International WWW Conference.
Mayo, 2003.

[BOR00] Bordignon, F. y Tolosa, G. “Gnutella: Sistema Distribuido para Almacenamiento y

Búsqueda de Información. Descripción del Modelo”. Reporte de Investigación. Maestría en
Redes de Datos Facultad de Informática. Universidad Nacional de La Plata, 2000.
[CHA03] Chawathe, Y.; Ratnasamy, S.; Breslau, L.; Lanham, N.; Shenker, S. “Making Gnutella-like
P2P Systems Scalable”. Interl Research Report. IRB-TR-03-014. Abril, 2003.

[DAB01] Dabek, F.; Brunskill, E.; Kaashoek, M.; Karger, D.; Morris, R.; Stoica, I.; Balakrishnan, H.
“Building Peer-to-Peer Systems with Chord, a Distributed Lookup Service”. En Proceedings
of the 8th Workshop on Hot Topics in Operating Systems (HotOS-VIII). Mayo, 2001.

[DSS00] Distributed Search Services. “The Gnutella Protocol Specification v0.4”. http://dss.clip2.com.
Septiembre, 2000.

[LVQ02] Lv, Q. “Search and Replication in Unstructured Peer-to-Peer Networks”. En Proceedings of

th
the 16 ACM International Conference on Supercomputing. 2002.

[OSO02] Osokine, S. “Search Optimization in the Distributed Networks”

[RAT01] Ratnasamy, S.; Francis, P.; Handley, M.; Karp, R. ”A Scalable Content-Addressable Network
(CAN)”. En Proceedings of ACM SIGCOMM. 2001.

[RIT01] Ritter, J. “Why Gnutella Can’t Scale. No Really”.

http://www.darkridge.com/~jpr5/doc/gnutella.html

[ROW01] Rowstron, A.; Druschel, P. “Pastry: Scalable, distributed object location and routing for
large-scale peer-to-peer systems”. En IFIP/ACM International Conference on Distributed
Systems Platforms (Middleware), p329-350. Noviembre, 2001.

[RUS95] Russel, S.; Norvig, P. Artificial Intelligence: A Modern Approach. Prentice-Hall, 1995.

[YAN01a] Yang, B.; Garcia-Molina, H. “Comparing Hybrid Peer-to-Peer Systems”. En VLDB’01

Conference. 2001.

[YAN01b] Yang, B.; Garcia-Molina, H. “Improving Search in Peer-to-Peer Networks”.

8 – Anexos

Tablas de datos

Longitud Identificador de nodo (Li) = 32 bits (4 bytes)

Longitud promedio término (Lt)= 80 bits (10 bytes) – Ver número
Longitud encabezado PDU (Le)= 160 bits (20 bytes)

Costo consulta por un término (Cct) = 2 * Le + Cq + Cr

Cq = Lt
Cr = Qnil * p(ni, q) * Li

p(ni, q) = Probabilidad de que el nodo ni tenga el término q

Cq 10
Cr = Qnil * p(ni, q) * Li
Li 4

p(ndx) Qnil p(ni, q) Cr Cct

0,125 436 0,5 872 922 bytes
0,25 211 0,5 423 473 bytes
0,375 140 0,5 281 331 bytes
0,5 105 0,5 209 259 bytes
0,625 83 0,5 166 216 bytes
0,75 70 0,5 139 189 bytes
 0,875 59 0,5 119 169 bytes

Qnil 436 211 140 105 83 70 59

p(ni, q) Cct
0,25 486,20 261,25 190,40 154,50 132,93 119,60 109,35
0,26 503,65 269,70 196,02 158,68 136,25 122,38 111,72
0,27 521,10 278,15 201,63 162,86 139,56 125,17 114,10
0,28 538,54 286,60 207,25 167,04 142,88 127,95 116,47
0,29 555,99 295,05 212,86 171,22 146,20 130,74 118,85
0,3 573,44 303,50 218,48 175,40 149,52 133,52 121,22
0,31 590,89 311,95 224,10 179,58 152,83 136,30 123,59
0,32 608,34 320,40 229,71 183,76 156,15 139,09 125,97
0,33 625,78 328,85 235,33 187,94 159,47 141,87 128,34
0,34 643,23 337,30 240,94 192,12 162,78 144,66 130,72
0,35 660,68 345,75 246,56 196,30 166,10 147,44 133,09
0,36 678,13 354,20 252,18 200,48 169,42 150,22 135,46
0,37 695,58 362,65 257,79 204,66 172,74 153,01 137,84
0,38 713,02 371,10 263,41 208,84 176,05 155,79 140,21
0,39 730,47 379,55 269,02 213,02 179,37 158,58 142,59
0,4 747,92 388,00 274,64 217,20 182,69 161,36 144,96
0,41 765,37 396,45 280,26 221,38 186,01 164,14 147,33
0,42 782,82 404,90 285,87 225,56 189,32 166,93 149,71
0,43 800,26 413,35 291,49 229,74 192,64 169,71 152,08
0,44 817,71 421,80 297,10 233,92 195,96 172,50 154,46
0,45 835,16 430,25 302,72 238,10 199,27 175,28 156,83
0,46 852,61 438,70 308,34 242,28 202,59 178,06 159,20
0,47 870,06 447,15 313,95 246,46 205,91 180,85 161,58
0,48 887,50 455,60 319,57 250,64 209,23 183,63 163,95
0,49 904,95 464,05 325,18 254,82 212,54 186,42 166,33
0,5 922,40 472,50 330,80 259,00 215,86 189,20 168,70
0,51 939,85 480,95 336,42 263,18 219,18 191,98 171,07
0,52 957,30 489,40 342,03 267,36 222,49 194,77 173,45
0,53 974,74 497,85 347,65 271,54 225,81 197,55 175,82
0,54 992,19 506,30 353,26 275,72 229,13 200,34 178,20
0,55 1009,64 514,75 358,88 279,90 232,45 203,12 180,57
0,56 1027,09 523,20 364,50 284,08 235,76 205,90 182,94
0,57 1044,54 531,65 370,11 288,26 239,08 208,69 185,32
0,58 1061,98 540,10 375,73 292,44 242,40 211,47 187,69
0,59 1079,43 548,55 381,34 296,62 245,71 214,26 190,07
0,6 1096,88 557,00 386,96 300,80 249,03 217,04 192,44
0,61 1114,33 565,45 392,58 304,98 252,35 219,82 194,81
0,62 1131,78 573,90 398,19 309,16 255,67 222,61 197,19
0,63 1149,22 582,35 403,81 313,34 258,98 225,39 199,56
0,64 1166,67 590,80 409,42 317,52 262,30 228,18 201,94
0,65 1184,12 599,25 415,04 321,70 265,62 230,96 204,31
0,66 1201,57 607,70 420,66 325,88 268,94 233,74 206,68
0,67 1219,02 616,15 426,27 330,06 272,25 236,53 209,06
0,68 1236,46 624,60 431,89 334,24 275,57 239,31 211,43
0,69 1253,91 633,05 437,50 338,42 278,89 242,10 213,81
0,7 1271,36 641,50 443,12 342,60 282,20 244,88 216,18
0,71 1288,81 649,95 448,74 346,78 285,52 247,66 218,55
0,72 1306,26 658,40 454,35 350,96 288,84 250,45 220,93
0,73 1323,70 666,85 459,97 355,14 292,16 253,23 223,30
0,74 1341,15 675,30 465,58 359,32 295,47 256,02 225,68
0,75 1358,60 683,75 471,20 363,50 298,79 258,80 228,05
Lq 83 (1 consulta a índices)
Qni 436
Bcn 60 (IP+TCP+Aplicación+Término)

Qna P(tr)=1 P(tr)=0, P(tr)=0, P(tr)=0, Gnutella

75 5 25
Qna 1 0,75 0,5 0,25 Gnutella
1 436 26243 19682 13122 6561 40172
2 872 52486 39365 26243 13122 80344
3 1308 78729 59047 39365 19682 120516
4 1744 104972 78729 52486 26243 160688
5 2180 131215 98411 65608 32804 200860
6 2616 157458 118094 78729 39365 241032
7 3052 183701 137776 91851 45925 281204
8 3488 209944 157458 104972 52486 321376
9 3924 236187 177140 118094 59047 361548
10 4360 262430 196823 131215 65608 401720
11 4796 288673 216505 144337 72168 441892
12 5232 314916 236187 157458 78729 482064
13 5668 341159 255869 170580 85290 522236
14 6104 367402 275552 183701 91851 562408
15 6540 393645 295234 196823 98411 602580
16 6976 419888 314916 209944 104972 642752
17 7412 446131 334598 223066 111533 682924
18 7848 472374 354281 236187 118094 723096
19 8284 498617 373963 249309 124654 763268
20 8720 524860 393645 262430 131215 803440
21 9156 551103 413327 275552 137776 843612
22 9592 577346 433010 288673 144337 883784
23 10028 603589 452692 301795 150897 923956

Lq 166 (2 consultas a índices)

Bcn 70 (IP+TCP+Aplicación+Término)

Qna P(tr)=1 P(tr)=0, P(tr)=0, P(tr)=0, Gnutella

75 5 25
Qna 1 0,75 0,5 0,25 Gnutella
1 436 30686 23015 15343 7672 40172
2 872 61372 46029 30686 15343 80344
3 1308 92058 69044 46029 23015 120516
4 1744 122744 92058 61372 30686 160688
5 2180 153430 115073 76715 38358 200860
6 2616 184116 138087 92058 46029 241032
7 3052 214802 161102 107401 53701 281204
8 3488 245488 184116 122744 61372 321376
9 3924 276174 207131 138087 69044 361548
10 4360 306860 230145 153430 76715 401720
11 4796 337546 253160 168773 84387 441892
12 5232 368232 276174 184116 92058 482064
13 5668 398918 299189 199459 99730 522236
14 6104 429604 322203 214802 107401 562408
15 6540 460290 345218 230145 115073 602580
16 6976 490976 368232 245488 122744 642752
17 7412 521662 391247 260831 130416 682924
18 7848 552348 414261 276174 138087 723096
 19 8284 583034 437276 291517 145759 763268
20 8720 613720 460290 306860 153430 803440
21 9156 644406 483305 322203 161102 843612
22 9592 675092 506319 337546 168773 883784
23 10028 705778 529334 352889 176445 923956

Lq 249 (3 consultas a índices)

Bcn 80 (IP+TCP+Aplicación+Término)

Qna P(tr)=1 P(tr)=0, P(tr)=0, P(tr)=0, Gnutella

75 5 25
Qna 1 0,75 0,5 0,25 Gnutella
1 436 35129 26347 17565 8782 40172
2 872 70258 52694 35129 17565 80344
3 1308 105387 79040 52694 26347 120516
4 1744 140516 105387 70258 35129 160688
5 2180 175645 131734 87823 43911 200860
6 2616 210774 158081 105387 52694 241032
7 3052 245903 184427 122952 61476 281204
8 3488 281032 210774 140516 70258 321376
9 3924 316161 237121 158081 79040 361548
10 4360 351290 263468 175645 87823 401720
11 4796 386419 289814 193210 96605 441892
12 5232 421548 316161 210774 105387 482064
13 5668 456677 342508 228339 114169 522236
14 6104 491806 368855 245903 122952 562408
15 6540 526935 395201 263468 131734 602580
16 6976 562064 421548 281032 140516 642752
17 7412 597193 447895 298597 149298 682924
18 7848 632322 474242 316161 158081 723096
19 8284 667451 500588 333726 166863 763268
20 8720 702580 526935 351290 175645 803440
21 9156 737709 553282 368855 184427 843612
22 9592 772838 579629 386419 193210 883784
23 10028 807967 605975 403984 201992 923956

Cantidad de docs x nodo 200,00

Cantidad de términos x doc 100,00
Tamaño promedio x término 10,00 bytes

Bytes totales x nodo 200000,00 bytes

195,31 Kb
0,19 MB
Bytes totales x índice x cant nodos

436 83,20 MB
211 40,29 MB
140 26,78 MB
105 19,93 MB
83 15,82 MB
70 13,28 MB
59 11,32 MB