[1] Es una implementación del protocolo Kademlia, el cual aporta la base teórica al protocolo y por tanto, hay muchas partes de Kademlia que KAD hereda y reutiliza.
También usa UDP debido a que no necesita establecer sesiones entre los peers, pues se suele enviar una sola petición de un peer a otro; cuando obtiene la respuesta es cuando repite la operación con el siguiente peer.
Sólo cuatro grandes clientes admiten actualmente la implementación de la red Kad.
Al contrario que otras implementaciones y protocolos, en KAD la distancia entre dos nodos es la misma en ambos sentidos, es decir es bidireccional.
Esto es un ejemplo simplificado de lo que sería KAD con tan solo 4 bits.
Este mensaje se envía de un peer a otro, que suponemos nos contestará.
Este mensaje primitivo (no iterativo) incluye una clave de 160 bit.
El receptor deberá devolver k triadas a no ser que el receptor no conozca más contactos y devuelva todos los que conoce.
Si la clave que busca el emisor es la clave de uno de los contactos, o del mismo peer al que se le está enviando este mensaje; aun así el receptor debe devolver k triadas.
Este mensaje primitivo (no iterativo) incluye una clave de 160 bit.
Cada nodo en la red KAD debe tener un identificador único, así que si no se ha asignado uno a un cliente, lo genera él mismo de manera aleatoria.
Una vez llegue este mensaje al emisor, se envía una comprobación de firewall (si este proceso ocurrió tras el bootstrapping) o un paquete del tipo ‘HELLO’ (en cualquier otro caso) en cuya ocasión se responderá con un ‘HELLO RESPONSE’.
El firewall bloqueará todas las conexiones entrantes que no hayan sido previamente especificadas por defecto.
KAD posee una implementación específica que averigua si un puerto de un cliente P2P tiene conectividad directa o no, y siempre que se establece la conexión de un peer con la red KAD, se ejecuta este proceso.
El contacto más cercano a la clave buscada (llamado closestNode) de destino, se guarda.
Con estos contactos cada vez nos acercaremos más (de nuevo en cuanto a métricas XOR) al nodo objetivo, puesto que cada búsqueda actualiza el closestNode para continuar buscando hasta el nodo deseado.
Las peticiones iterativeStores se usan para la publicación de datos o replicarlos en la red KAD.
Se lleva a cabo como una búsqueda de nodo, y por lo tanto genera una lista con los k contactos más cercanos.
Sin embargo, esto se hace usando mensajes del tipo FIND_VALUE en lugar de los FIND_NODE.
Sin embargo, la replicación de contenido hace que la publicación se haga en varios peers diferentes.
Estas notas son unos comentarios que se usan a modo de calificación del contenido, de manera que si un supuesto peer malicioso intentase contaminar la red publicando contenidos corruptos o no legítimos, el cliente peer que recibe ese archivo lo detecta evitando publicarlo o compartirlo de nuevo al resto de la red, y evitar así su masificación por la red KAD.
Dichas notas no solo sirven para esto, sino que además se utilizan para almacenar otros tipos de información relativa a contenidos de la red KAD.
Si este FILERATING se establece en 0, significa que la nota es un mero comentario.
El cliente que recibe la nota la añade al ID de la fuente correspondiente.
Estos host peer solo mantendrán la información durante un periodo determinado de tiempo preestablecido, para evitar referencias corruptas que no apunten a ningún contenido.
Esto mejora el rendimiento y además evita sobrecarga de tráfico en la red.
Un ejemplo de publicación de contenido en la red KAD se podría plantear como lo mostramos en la imagen anterior, donde podemos ver los peers implicados con la información que contiene cada uno del contenido almacenado.
Se puede apreciar que el contenido a publicar tiene por título una serie de 3 palabras, por tanto como se explicó anteriormente tendremos 3 hashes de las referencias al peer que almacena el contenido real.
Los clientes P2P implantan un sistema de crédito para incitar a los usuarios a compartir más archivos y así recibir mejor prestaciones y mejores contenidos que otros usuarios.