Sie sind auf Seite 1von 6

Universidad Simón Bolívar

Departamento de Computación y Tecnología de Información


Redes de Computadores II (CI-5832)
Integrantes: Christian Chomiak (05-38034)
Daniel Ramírez (05-38781)
Miguel De Los Ríos (05-38084)

Propuesta de Proyecto para la Cadena de Redes


BootyNet: Red de distribución basada en seguimiento

Marco Teórico

“La historia de la piratería es casi tan antigua como la historia de la humanidad. Cuando
algunos hombres se dieron cuenta de que podían viajar por el mar, se volvieron navegantes; y
cuando otros hombres se dieron cuenta de que podían asaltar a esos navegantes, se volvieron
piratas.
...
Desde entonces, las playas y los mares de muchas partes del mundo comenzaron a
poblarse de esos personajes que amaban el peligro, odiaban el trabajo y ambicionaban las
riquezas que poseían los demás.

En la isla de La Tortuga, todos esos piratas habían formado una república, a la que
pusieron por nombre Cofradía de los Hermanos de la Costa. Los piratas vivían en aquella isla
como querían, sin importarles si uno era inglés, el otro francés, o el de más allá holandés. Allí no
había policías, ni jueces, ni cárceles.

En la isla de La Tortuga tampoco existía la propiedad privada de la tierra, o sea que la
isla era de todos pero, a la vez, de nadie en particular.” [1]

Análogamente, uno de los aspectos más predominantes y atractivos de las


conexiones y comunicación entre equipos, sin importar el lugar donde se encuentren, es la
capacidad de obtener recursos de manera remota, compartiendo de esta forma fotos, videos,
música, documentos y más.

Este aspecto resulta aún más interesante cuando, más allá de que un usuario dependa de
un servidor de algún tercero (o una serie de ellos) para obtener dichos recursos, pueda
conseguirlos a partir de otros usuarios y al mismo tiempo poder compartir con también los
archivos que posee. A esto lo denominamos ​peer-to-peer ​(P2P).
En el sentido estricto, como su nombre lo indica, estas redes son entre usuarios que tienen
el mismo rango entre sí, por lo que se realiza una solicitud de un recurso, los usuarios que poseen
responden y se realiza la descarga.

Descripción del Proyecto

El objetivo de este proyecto es establecer un mecanismo con el cual un usuario ponga a


disposición de un grupo de usuarios, un conjunto de recursos; así como permitirle hacerles
seguimiento a otros usuarios, con el fin de poder obtener los recursos que dichos usuarios
ofrezcan.

Un usuario podrá decidir si descargar o compartir un recurso publicado por alguno de los
usuarios a los que hace seguimiento.

A la hora de solicitar un recurso, el usuario deberá proceder a comunicarse con los nodos
a los que sigue; en caso de que uno o más nodos conozcan terceros (a quienes le hagan
seguimiento) que posean dichos archivos, podrán indicarle al agente del usuario que dichos
terceros también poseen el recurso, para agilizar la transferencia de archivos.

Es importante que la comunicación entre los usuarios sea segura (es decir, que la
comunicación y transmisión de datos debe estar cifrada); ésto se deberá hacer mediante el uso de
claves públicas y privadas.

A la hora de instalar el agente, se deberá registrar ante un servidor de usuarios existente,


bajo un userID (el mismo agente puede estar registrado en varios servidores independientes, bajo
userIDs distintos). No deberá ser necesario estar registrado ante un servidor (lo cual es sólo una
facilidad para ser encontrado por otros usuarios); se deberá permitir a este tipo de usuarios poder
compartir sus recursos vía invitaciones de descarga.

La ubicación de los recursos deberá ser transparente para el usuario final, sin embargo, al
desear éste descargar un recurso, el agente deberá saber qué miembros anunciaron tener dicho
recurso y comunicarse con éstos a fin de poder descargar dicho recurso.

Se deberán desarrollar cuatro (4) elementos claves:

1. Servidor​: ubicación donde se podrán registrar los usuarios, a fin de poder facilitar la
comunicación entre los mismos.
2. Agente​: programa que deberá ser instalado en el sistema operativo del usuario y que se
encargará de manejar las peticiones de recursos (descarga y subida) y de recolectar
información sobre los recursos de los usuarios a los que se le hace seguimiento.
3. Plug-in o extensión​: programa para navegador Firefox y/o Chrome/Chromium, para
permitir el manejo de invitaciones para descargar recursos de un usuario.
4. Interfaz gráfica​: Renderización de la información recolectada por el agente, para que sea
presentable para el usuario final (vía navegador web). GUI para la configuración del
agente.

Protocolos a utilizar

Se deberán usar tres protocolos, uno para solicitar la información de contacto cuando se
desee establecer comunicación con otro usurario (para la cual se realiza una conexión con el
servidor que gestiona al conjunto de usuarios), otro para el intercambio de mensajes entre los
agentes de los usuarios, y un tercero para la transmisión de los datos (a la hora de descargar un
archivo).

Protocolo de ubicación de contacto ANCHOR ​(Another Competent Handling of Requests -


Otro manejo competente de las solicitudes):

Paso 1 (Avast!): “Usuario ​A​” envía una petición de inicio de conversación, para lo cual
realiza una conexión con el servidor para solicitar la información de contacto del
“Usuario ​B​” con el que desea establecer comunicación.

Paso 2 (Aye aye!): El servidor revisará en su lista de usuarios registrados la existencia


del “Usuario ​B​” con el que el “Usuario ​A​” se desea contactar. El servidor le enviará al
“Usuario ​A​” la información necesaria para establecer la conexión con el “Usuario ​B​”.

Otros mensajes​ ANCHOR:

● Registro​: un agente desea registrarse ante un servidor con un userID.


● Des-registro ​(Walk the plank): un agente desea no formar parte de un servidor en
el que se encuentra registrado.
● Petición de ubicación​: un usuario pregunta dónde puede conseguir a otro usuario
(se pide el IP con que se encuentra registrado el otro usuario, ante el servidor).

Protocolo de comunicación YARR ​(Yarr, automatic request and response - Yarr, petición y
respuesta automática):

Paso 1​: “Usuario ​A​” solicita información de contacto del “Usuario ​B​” mediante el
Protocolo ANCHOR.

Paso 2 (Ahoy!): Teniendo la información de contacto, el “Usuario ​A​” envía una petición
de conexión al “Usuario ​B​”, anexando su userID y su clave pública.

Paso 3 (Arrr!): El “Usuario ​B​” verifica si el userID del “Usuario ​A​” está en su lista de
seguidores, en caso de ser así, responde con su clave pública, cifrando esta respuesta con
la clave pública del “Usuario ​A​”.

Paso 4 (Parley): “Usuario ​A​” envía el mensaje al “Usuario ​B​”, encriptado con la clave
pública del “Usuario ​B​”.
Otros mensajes​ YARR:

● Seguimiento ​(I'd love to drop anchor in your lagoon): Un usuario le pide


autorización a otro usuario, de hacer seguimiento de sus publicaciones.
● Solicitud de Estado (Come show me how ye bury yer treasure, lad!): Un usuario
le pide a otro usuario al que sigue, que le diga qué recursos comparte.

Protocolo de transferencia P2P ​(Pirate-to-pirate - Pirata-a-pirata):

El “Usuario ​A​” solicita un recurso y su agente se encargará de comunicarse con aquellos


nodos (por ejemplo: ​B​, ​C​, ​D​) que hayan indicado que posee dicho archivo. El agente cada cierto
periodo de tiempo debe invocar al Protocolo ANCHOR para asegurarse que la información de
los nodos que poseen los recursos deseados no ha cambiado.

Paso 1​: ​A​ envía un mensaje a ​B​, ​C​ y ​D ​vía Protocolo YARR solicitando el recurso.

Paso 2​: Si por ejemplo ​B hace seguimiento de otro(s) usuario(s) (ejemplo, usuario ​E​)
que también posea dicho recurso, ​B deberá comunicarse con el servidor mediante el
Protocolo ANCHOR para solicitar la información de contacto de ​E e indicarle que ​A
desea obtener un recurso e igualmente notificarle a ​A que ​E también posee el recurso que
desea.

Paso 2.1​: En caso de ​A ​ser notificado de nodos externos, deberá solicitar


conexión usando el Protocolo YARR (usando la clave pública de ​E que fue obtenida a
través de ​B​).

Paso 3 (Prepare to be boarded!): A medida que el “Usuario ​A​” establezca las conexiones
con los nodos que poseen los recursos deseados, se deberá iniciar la transferencia de
tramas del recurso desde de los diferentes nodos fuente.

Paso 4​: Una vez descargado el recurso deseado y realizado el chequeo de verificación de
correctitud de las tramas, terminar la conexión con los nodos con los que se estableció la
comunicación. En caso de fallar el checksum de alguna de las tramas, será necesario
re-emitir la petición; de detectarse que muchas tramas vienen corruptas, por parte de
alguno de los nodos (salvo el caso en que únicamente haya o quede uno), se deberá dejar
de pedir el recurso a dicho nodo.

Otros mensajes​ P2P:

● Comenzar ​(Where be the treasure?): El usuario que desea descargar, le pide al


otro usuario que le dé información básica del recuros (i.e. tamaño o número de
bytes).
● Obtener ​(RAMMING SPEED!): Un usuario le pide un segmento de bytes dado
(junto con su checksum pertinente), del archivo al otro usuario.
● Finalizar (Land Ahoy): El usuario que descarga le indica al otro usuario que no
desea pedirle más segmentos.
● Error de descarga ​(Aaaarrrrgggghhhh!): el usuario indica al usuario fuente que
se produjo un error en el checksum y solicita un reenvio de la trama que llegó
corrupta.

Cabe destacar que para los tres protocolos a utilizar se definieron los tipos de mensajes básicos
que deben implementarse. Es a discreción del grupo de trabajo, si se desea agregar otros
mensajes para facilitar la comunicación entre los agentes.

Estructura de los usuarios

Existen varios tipos de usuarios de la aplicación. Estos son:

● Visitantes​: Este tipo de usuarios no posee un agente instalado en su estación de


trabajo y podrá “abrir” invitaciones de descarga de archivos.
● Miembros​: Aquellos usuarios que tengan instalado el agente y estén (o no)
registrados en un servidor, podrán hacer seguimiento de otros usuarios dentro de los
servidores en que se encuentre registrado, así como poder ser seguidos. Como fue
indicado anteriormente, el registro ante un servidor únicamente facilitará que estos
“miembros” puedan ser encontrados y encontrar a otros, con mayor facilidad.

Primera entrega

Para la primera entrega, se espera que estén disponibles una versión preliminar del agente, del
servidor y del plug-in.

Segunda entrega

Para la segunda entrega, se deberá trabajar toda la interfaz gráfica (vía una página web), así
como la interacción de la misma con el agente de esa estación de trabajo.

Tiempo estimado para el proyecto

El proyecto podrá ser finalizado en un (1) trimestre según lo especificado en este documento; sin
embargo, se podría expandir para un trimestre más, con el fin de agregar nuevas funcionalidades,
como un cliente para Android, por ejemplo.
Funcionalidades del Sistema

● Acceder a los recursos de los usuarios a los que se les haga seguimiento.
● Modificar o agregar recursos para compartir con los usuarios que hagan seguimiento.
● Seguir a tantos usuarios como se quiera que estén registrados en un servidor.
● Invitar a otras personas a hacer seguimiento a algún usuario.

Referencias
[1] Sobre piratas: ​http://bibliotecadigital.ilce.edu.mx/sites/colibri/cuentos/piratas/htm/sec_2.htm

[2] Para entender los términos piratas: ​http://www.talklikeapirate.com/howto.html