RC Peer-to-Peer. 1. Introdução. 2. Especificação. Redes de Computadores 2º Semestre 2008/2009. Projecto de Laboratório

Transcrição

1 RC Peer-to-Peer Redes de Computadores 2º Semestre 2008/2009 Projecto de Laboratório 1. Introdução Pretende-se desenvolver uma aplicação Peer-to-Peer (P2P) de partilha de ficheiros. A aplicação compreende um tracker (fornecido pelos docentes) e vários peers (um por cada grupo de alunos). O tracker mantém informação sobre o swarm associado a cada ficheiro partilhável. Cada peer tem uma interface de utilizador e subentende dois protocolos da camada de aplicação, um para comunicação com o tracker e outro para comunicação com outros peers. Numa aplicação P2P, um utilizador que pretenda fazer download de um ficheiro tem que primeiro obter a localização do tracker que gere o swarm associado. Por uma questão de simplificação, neste projecto, a localização do tracker é bem conhecida e este pode ser interrogado sobre os ficheiros dos quais possui um swarm. A partilha dos ficheiros propriamente dita é feita através da transferência de blocos de 2 14 bytes entre peers. Os protocolos da camada de aplicação operam de acordo com o paradigma cliente-servidor e servem-se dos serviços da camada de transporte através da interface de sockets. Na comunicação entre um peer e o tracker, o peer é o cliente e o tracker o servidor. Cada peer obtém junto do tracker a lista de ficheiros partilhados e, para cada ficheiro, o swarm associado. A comunicação entre peer e tracker deve ser suportada na camada de transporte UDP, devendo a interface de sockets ser programada para esse efeito. Na comunicação entre peers, aquele que faz download é o cliente e o outro é o servidor. Assim sendo, cada peer tem de estar preparado para operar quer em modo cliente quer em modo servidor no que diz respeito à partilha de ficheiros. A comunicação entre peers deve ser suportada na camada de transporte TCP, devendo a interface de sockets ser programada para esse efeito. Neste projecto, cada peer pode estar envolvido apenas na partilha de um ficheiro a cada momento. 2. Especificação A especificação de um peer é constituída pela especificação da interface de utilizador (secção 2.1), a especificação do protocolo da camada de aplicação que permite a comunicação com o tracker (secção 2.2) e a especificação do protocolo da camada de 1

2 aplicação que permite a comunicação directa entre dois peers para partilha de ficheiros (secção 2.3). 2.1 Interface de utilizador dos peers O peer é invocado com o comando em que rcp2p [-n trackername] [-p trackerport] [-s seedport] - trackername é o nome da máquina que aloja o tracker. Este argumento é opcional. Em caso de omissão, assume o valor tejo.ist.utl.pt. - trackerport é o porto bem-conhecido no qual o tracker recebe pedidos dos peers. Este argumento é opcional. Em caso de omissão, assume o valor seedport é o porto no qual o peer aceita pedidos de outros peers para a partilha de ficheiros. Este argumento é opcional. Em caso de omissão, assume o valor Logo após a invocação do peer, este activa a interface de utilizador através da qual o utilizador tem à disposição os seguintes comandos: a) list O utilizador pede ao tracker a lista de todos os ficheiros disponíveis para partilha e respectivo número de bytes. O resultado do pedido deve ser ecoado no ecrã. Esta lista de ficheiros permite ao utilizador escolher qual o ficheiro de que deseja fazer download. b) seed <filename> O utilizador disponibiliza o ficheiro <filename> para partilha. Por uma questão de simplificação, apenas um ficheiro pode ser partilhado de cada vez. Ao invocar este comando, o peer deve criar um ficheiro por cada bloco de 2 14 bytes em que o ficheiro <filename> é partido, usando, por exemplo, os nomes block0, block1, block2, Possivelmente o último bloco do ficheiro conterá menos do que 2 14 bytes. Em resultado deste comando, o peer deve informar o tracker de que é um seeder do ficheiro <filename>. A dimensão do ficheiro é também enviada ao tracker para que mais tarde os peers interessados neste ficheiro possam determinar o número de blocos envolvidos na sua transferência. 2

3 c) unseed O utilizador deixa de partilhar o ficheiro que anteriormente estava a disponibilizar. Os blocos associados ao ficheiro que agora deixa de ser disponibilizado devem ser apagados. Para além disso, o peer deve informar o tracker de que já não é um seeder desse ficheiro. d) download <filename> O utilizador quer fazer download do ficheiro <filename>. Em resultado deste comando, o peer interroga o tracker acerca do swarm associado à partilha do ficheiro <filename>. Em resposta a esta interrogação, o tracker retorna a dimensão do ficheiro e o swarm a ele associado. De seguida, o peer informa o tracker que passará a ser um leecher do ficheiro <filename>. Uma vez conhecendo o swarm associado ao ficheiro, o peer estabelece uma sessão TCP com cada um dos seus peers interrogando-os acerca dos blocos do ficheiro <filename> que têm disponíveis para partilha. Com a lista de blocos que cada um dos outros peers dispõe, o peer estabelece uma estratégia relativamente a quais os blocos de que irá fazer download de cada um dos outros peers. Concluída a transmissão dos blocos pedidos, os peers servidores fecham a sessão TCP. Depois de terminadas todas as sessões, o peer avalia se dispõe de todos os blocos necessários para reconstruir o ficheiro <filename> ou se é necessário repetir todo o procedimento descrito nos últimos dois parágrafos. A partir do momento em que se inicia o download, o peer disponibiliza um servidor concorrente, suportado em TCP, com porto bem-conhecido seedport, para aceitação de pedidos de blocos do ficheiro <filename> vindos de outros peers. Assume-se que se surgirem pedidos antes de o peer dispor de blocos para partilhar, o peer pode responder indicando uma lista de blocos vazia. Concluído o download, o peer mantém-se como seeder do ficheiro recebido. e) status O utilizador pede para que seja ecoado o estado do download em curso. O estado deve conter o nome do ficheiro, a sua dimensão, a percentagem de blocos já recebidos e a constituição do último swarm associado ao ficheiro de que se está a fazer download. f) stop O utilizador pede para que seja interrompido o download em curso. Os blocos já recebidos irão continuar a ser disponibilizados. 3

4 g) help h) exit O utilizador pede para que seja ecoada a lista de comandos disponível. Comando utilizado para terminar a execução do peer. Todas as sessões TCP devem ser terminadas. Caso se esteja a disponibilizar um ficheiro, o tracker deve ser informado de que o peer irá deixar de pertencer ao swarm e os ficheiros dos blocos devem ser apagados. 2.2 Protocolo Peer-Tracker O tracker fornecido pelos docentes gere a base de dados dos ficheiros partilhados. Para cada ficheiro é guardada a sua dimensão, em bytes, bem como o endereço IP e o porto bemconhecido do servidor de cada peer pertencente ao swarm associado. Por omissão, o tracker encontra-se na máquina tejo.ist.utl.pt no porto UDP O protocolo de comunicação entre o cliente a ser concretizado no peer pelos alunos e o tracker contempla os seguintes comandos e respostas: a) LST\n O peer pede ao tracker a lista de todos os ficheiros disponíveis para partilha e respectivo número de bytes. A resposta a este comando é composta por várias linhas. A primeira linha contém a seguinte informação: OBJ\n As linhas seguintes contêm pares nome de ficheiro, número de bytes, separados por um espaço. A última linha é vazia (contém apenas o terminador \n ). Exemplo: OBJ\n goodmovie.avi \n badmusic.mp \n \n b) ADD <filename> <size> <seedingport>\n O peer pede para ser registado como fazendo parte do swarm associado ao ficheiro <filename>. Caso este ficheiro ainda não se encontre a ser partilhado, uma nova entrada será registada na base de dados do tracker, ficando guardado o nome do ficheiro e o respectivo número de bytes. 4

5 O endereço IP do remetente do pedido e o <seedingport> são acrescentados ao swarm. A resposta do tracker a este pedido é OK\n. c) CLR <filename> <seedingport>\n O peer pede para que o seu registo no swarm, associado ao ficheiro <filename>, seja removido. O tracker identifica o registo através do nome do ficheiro <filename>, do endereço IP do peer e do número do porto, <seedingport>, onde o peer aceitava pedidos para a partilha de ficheiros. A resposta do tracker a este pedido é OK\n. d) QRY <filename>\n O peer pede ao tracker a dimensão do ficheiro <filename> e o swarm associado. A resposta a este comando é composta por várias linhas. A primeira linha contém a seguinte informação: SWARM <filename> <size>\n em que <filename> é o nome do ficheiro e <size> é a sua dimensão em bytes. As linhas seguintes contêm pares de endereço IP, número do porto, separados um do outro pelo carácter :. A última linha é vazia (contém apenas o terminador \n ). Exemplo: SWARM goodmovie.avi \n :9000\n :9000\n \n Em caso de erro em qualquer dos comandos anteriormente apresentados, o tracker responde com uma mensagem de uma linha, terminada por \n e que começa pela palavra ERR. 2.3 Protocolo Peer-Peer Quando, em resultado da interacção com o tracker, o peer fica a conhecer o endereço IP e o porto bem-conhecido dos servidores nos peers do swarm associado ao ficheiro de que se pretende fazer download, ele pode estabelecer sessões TCP com cada um desses peers. O 5

6 protocolo da camada de aplicação entre peers contempla os seguintes comandos e respostas: a) BLK <filename>\n O peer cliente pede ao peer servidor a lista dos blocos disponíveis pertencentes ao ficheiro <filename>. A resposta a este comando é composta por várias linhas. Cada linha contém o número de um bloco e é terminada com o carácter \n. A última linha é vazia (contém apenas o terminador \n ). Exemplo: 0\n 1\n 33\n 324\n 325\n 326\n 702\n \n b) DWNLD\n<x 1 >\n<x 2 >\n \n<x k >\n\n Depois de recebida a resposta do peer servidor, o peer cliente estabelece uma estratégia relativamente a quais os blocos que irá fazer download de cada um dos peers servidores. Estabelecida essa estratégia, envia a cada peer servidor um comando composto por várias linhas. A primeira linha contém a seguinte informação: DWNLD\n Cada uma das linhas seguintes contém o número de um bloco e é terminada com o carácter \n. A última linha é vazia (contém apenas o terminador \n ). Exemplo: DWNLD\n 0\n 1\n 33\n 324\n \n Em resposta, o peer servidor envia os bytes dos blocos pedidos (sem delimitadores ou terminadores). Concluída a transmissão dos blocos, o peer servidor termina a sessão TCP. 6

7 3. Desenvolvimento Deve garantir que o seu código compila e executa correctamente no ambiente de desenvolvimento disponível no laboratório: Compilador: gcc versão Depurador: ddd versão glibc: versão 2.4 Baseie a operação do seu programa no seguinte conjunto de chamadas de sistema: Nome da máquina: gethostname(). Endereço IP de uma máquina remota a partir do seu nome: gethostbyname(). Leitura de informação do utilizador para a aplicação: fgets(). Gestão de um cliente UDP: socket(), close(). Comunicação UDP: sendto(), recvfrom(). Gestão de um cliente TCP: socket(), connect(), close(). Gestão de um servidor TCP: socket(), bind(), listen(), accept(), close(). Comunicação TCP: write(), read(). Multiplexagem de informação: select(). Criação de um processo concorrente: fork(). O código desenvolvido deve estar convenientemente estruturado e comentado. As chamadas de sistema read() e write() podem ler e escrever, respectivamente, um número de bytes inferior ao que lhes foi solicitado. Quer os processos cliente quer os processos servidor devem terminar graciosamente pelo menos nas seguintes situações de falha: mensagens do protocolo erradas vindas da entidade par correspondente; ligação TCP do cliente ou do servidor fechada de forma imprevista; condições de erro das chamadas de sistema. 4. Bibliografia José Sanguino, A Quick Guide to Networking Software, 2009 W. Richard Stevens, Unix Network Programming: Networking APIs: Sockets and XTI (Volume 1), 2a edição, Prentice-Hall PTR, 1998, ISBN X, capítulo 5 Michael J. Donahoo, Kenneth L. Calvert, TCP/IP Sockets in C: Practical Guide for Programmers, Morgan Kaufmann, ISBN , 2000 Manual on-line, comando man 7

8 5. Entrega do Projecto O código a entregar é composto pelos ficheiros fonte do conversador e a correspondente makefile. A entrega do trabalho é feita por ao seu docente de laboratório. Deve criar um único ficheiro de arquivo zip com todos os ficheiros fonte e outros ficheiros necessários à execução das aplicações. O arquivo deve estar preparado para ser aberto para o directório corrente e compilado com o comando make. O nome do ficheiro submetido deve ter o seguinte formato: proj<número_do_grupo>.zip 6. Glossário Seeder: É um peer que tem todo o ficheiro que está a ser partilhado. Leecher: É um peer que só tem parte do ficheiro que está a ser partilhado. Assim que receber todo o ficheiro passa a ser um seeder. Swarm: Conjunto de todos os seeders e leechers associados a um ficheiro que está a ser partilhado. Tracker: É um servidor que mantém actual o swarm associado a cada ficheiro partilhável. 8