REDES INTEGRADAS DE TELECOMUNICAÇÕES I 2008 / 2009

Transcrição

1 Departamento de Engenharia Electrotécnica REDES INTEGRADAS DE TELECOMUNICAÇÕES I 2008 / 2009 Mestrado Integrado em Engenharia Electrotécnica e Computadores 4º ano 7º semestre 2º Trabalho Prático: Localização e troca de ficheiros através de multicast em IPv6 Luis Bernardo/Rodolfo Oliveira

2 1. Objectivos Familiarização com a programação usando endereços IPv6, o ambiente gráfico Gnome/Gtk+, e os mecanismos de gestão de processos e de comunicação entre processos no sistema operativo Linux. O trabalho consiste no desenvolvimento de uma aplicação para troca de ficheiros numa rede dual stack. A aplicação regista-se num endereço IPv6 Multicast, e envia os pacotes de pesquisa para esse endereço sempre que o utilizador desencadeia uma pesquisa. Desta forma, cada participante recebe o pedido respondendo caso possua o ficheiro. Em seguida, a aplicação descarrega o ficheiro em paralelo a partir de vários pares, utilizando sub-processos (através de sockets ). O trabalho consiste no desenvolvimento de um executável: fileexchange. 2. Especificações A aplicação fileexchange necessita de dois parâmetros de configuração: o endereço IP Multicast do grupo (por defeito vai-se usar o endereço "ff18:10:33::1") e o número de porto UDP (por defeito vai-se usar o porto 20000). fileexchange fileexchange UDP????? UDP????? Canal Multicast IPv6 UDP fileexchange UDP????? fileexchange????? A aplicação fileexchange realiza a pesquisa por ficheiros utilizando um socket datagrama. Para receber pedidos para o grupo usa um socket UDP associado ao grupo e configurado para o número de porto. Para enviar pedidos e receber resposta usa outro socket UDP privado (com um porto único). Para trocar ficheiros são usados um socket para receber ligações (com um porto único) mais um número arbitrário de sockets para enviar ficheiros. A aplicação fileexchange começa por aguardar que o utilizador configure o canal Multicast IPv6 (endereço IPv6 + número de porto) onde pretende escutar. Após o utilizador premir um botão, a aplicação arranca com os três sockets, e fica preparada para enviar ou receber mensagens UDP ou ligações. Paralelamente, a aplicação permite modificar a lista de ficheiros partilhados. Quando o utilizador escolher a pesquisa de um ficheiro especifica quantas ligações pretende usar para o descarregar (N). A aplicação começa por enviar para o grupo o pedido e fica à

3 espera de N respostas até um tempo máximo de espera. Caso tenha tido pelo menos uma resposta, deve lançar um sub-processo por cada ligação, que cria um socket temporário para receber um fragmento do ficheiro. Caso falhe uma das ligações, deve tentar usar outro servidor para receber o fragmento omisso. Depois de receber todos os fragmentos, deve criar um ficheiro completo, numa directoria de saída definida na interface gráfica. Após a recepção de uma nova ligação, também deve ser criado um sub-processo para enviar o ficheiro pedido. A janela principal deve listar todos os sub-processos activos, os ficheiros recebidos, e os bytes transferidos ou o ritmo de transferência. Para facilitar o desenvolvimento do trabalho, é fornecido um ficheiro de especificação de interface "gui_t2.glade" com a janela principal do programa, mais algumas funções adicionais de acesso à interface gráfica e de interacção com sockets, e todas as funções de manipulação da lista de ficheiros partilhados. Estes ficheiros já incluem o arranque do socket UDP privado e o esqueleto da callback de dados UDP (que processa os pedidos). Para reduzir a carga horária do trabalho, reduziu-se o trabalho apenas à componente de pedido e recepção de ficheiros, deixando-se como opcional o módulo de distribuição de ficheiros Pesquisa de ficheiros A partir do momento em que ficar activa, a aplicação pode enviar um pacote de pesquisa de ficheiro para o grupo. O nome a pesquisar não deve incluir o caminho (nomes de directórios) e deve ser terminado com o carácter '\0'. Este pacote identifica o utilizador (pelo número de porto) e o número de pesquisa (número de sequência), permitindo a existência de vários pedidos simultaneamente. A mensagem de pedido enviada para o grupo consiste num octeto com o tipo de mensagem, seguida do número de porto do socket (ou do socket UDP privado, para quem não realizar o envio de ficheiros), o número de sequência único, e de uma cadeia de caracteres com o nome que se pretende registar (terminado com o caracter '\0'). Mensagem pesquisa de ficheiro: { sequência contígua de } unsigned char tipo; // tipo de mensagem - Query= 60 unsigned short portoe; // porto do socket (id único) int seq; // número de sequência de pedido char *nome; // array de caracteres terminado por '\0' strlen(nome)+1 Query tipo= 10 tipo portoe seq nome O utilizador pode especificar o número de feixes que pretende para descarregar o ficheiro. A aplicação deve aguardar pela recepção de respostas ao pedido até que recolha um número de respostas igual ao número de feixes pedidos pelo utilizador, até um tempo máximo de cinco segundos. Caso não receba nenhuma resposta deve abortar a transferência. Extra: Ao receber o pacote de pedido a aplicação fileexchange deve comparar o nome do ficheiro com os nomes de ficheiros partilhados (excluindo o caminho) e devolver um pacote de resposta ao emissor, onde indica as características do ficheiro encontrado (o comprimento e o valor de hash) e o número de porto onde o emissor se deve ligar e a partir de onde pode descarregar o ficheiro. Inclui ainda os dados do emissor, para permitir realizar a associação ao pedido (quando existem vários pedidos em paralelo). 3

4 A mensagem de resposta enviada para o emissor do pedido consiste num octeto com o tipo de mensagem, seguida do número de porto enviado pelo emissor, do número de sequência enviado pelo emissor, do nome do ficheiro pedido, do porto do socket onde recebe ligações, do comprimento do ficheiro, e do valor de hash do conteúdo do ficheiro. Mensagem encontrou ficheiro: { sequência contígua de } unsigned char tipo; // tipo de mensagem - Hit=70 unsigned short portoe; // porto do emissor (id de emissor) int seq; // número de sequência de pedido char *nome; // array de caracteres terminado por '\0' unsigned short portos; // porto do servidor long len; // Comprimento do ficheiro encontrado int hash; // Valor de hash do ficheiro encontrado strlen(nome)+1 tipo portoe seq nome portos len hash Hit tipo= 20 O envio da resposta a uma Query e o envio de ficheiros deve ser realizada apenas após estar concluída a pesquisa e recepção de ficheiros. Extra: A aplicação pode realizar apenas uma pesquisa de cada vez, ou suportar várias pesquisas em paralelo. Sugere-se que se realize várias pesquisas por ficheiros diferentes em paralelo apenas após realizar as funcionalidades básicas (transferência de um ficheiro de cada vez, e envio de ficheiro) Transferência de ficheiros Depois de reunir as várias respostas, a aplicação deverá seleccionar um número de servidores igual (ou menor, se não houve respostas suficientes) ao número pedido pelo utilizador (N), e descarregar o ficheiro em N segmentos. Deve calcular qual a dimensão dos segmentos que pretende de cada servidor, e descarregar cada segmento individualmente. A leitura e escrita dos segmentos de ficheiro deve ser realizada em sub-processos criados no emissor e no receptor do ficheiro. Após seleccionar um servidor, o receptor do ficheiro (que enviou a Query) deve criar um sub-processo de recepção (descarga) de ficheiro (1), que cria um socket temporário para receber o ficheiro. Após o subprocesso estabelecer ligação (2), é disparada no emissor (que enviou o Hit) a callback de aceitação de ligações. Esta callback deverá também lançar um sub-processo (3), que envia o ficheiro pretendido. 4

5 fileexchange fileexchange pipe sinal SIGUSR1 (1) (2) (4)????? pipe (3) sinal SIGUSR1 (5) No canal de comunicação entre o receptor e o emissor, a comunicação deve iniciar-se com o envio de um pedido de ficheiro (4). O receptor indica ao emissor os dados recebidos no pacote Hit (nome, hash e len), e indica qual o segmento que pretende receber do emissor (os caracteres a começar na posição n0 até à posição n1-1). O emissor deve validar os dados do pedido e em seguida deve enviar o conteúdo do segmento pedido pelo receptor (5): Pedido de ficheiro no canal : { sequência contígua de } int len_filename; // Comprimento do nome do ficheiro (máx. 256 bytes) char *filename; // array de caracteres terminado por '\0' int hash; // Valor de hash do ficheiro encontrado long len; // Comprimento do ficheiro encontrado int n0; // Primeiro byte a enviar (começa em 0 o ficheiro) int n1; // Byte final (transmitir até n1-1) 4 len_filename len_filename filename hash len n0 n1 Os sub-processos poderão comunicar com os processos pai através de um pipe criado antes da separação do sub-processo, enviando mensagens com uma estrutura arbitrária, que informem o processo pai de: conteúdo do cabeçalho para preenchimento da interface gráfica (no caso do emissor de ficheiros); informação sobre evolução da transferência; fim da transferência (com informação sobre se houve erro, tempo de transferência e número de bytes). Como estas mensagens são internas ao programa, não são normalizadas no enunciado, devendo ser os alunos a definir a sua estrutura. O processo pai apenas vai comunicar com os sub-processos quando os quiser parar, utilizando o sinal SIGUSR1 para esse efeito. O processo pai também vai poder seguir o que está a ocorrer nos sub-processos através da rotina de tratamento do sinal SIGCHLD, corrida quando morre um dos seus filhos. Através da análise do motivo de saída (_exit ou sinal) e do valor do _exit, é possível detectar se o processo enviou uma mensagem através do pipe, ou se falhou. Extra: A aplicação pode usar apenas uma ligação por emissor, ou criar várias ligações para o mesmo emissor em paralelo. Sugere-se que deixe este extra para o fim. 5

6 3. Desenvolvimento da aplicação Configuração do grupo Botão de arranque Dados da aplicação Lista de ficheiros partilhados Gestão da lista de ficheiros partilhados Pedido de ficheiro Parar transferência Nº feixes pretendido Directoria onde coloca ficheiros recebidos Lista de subprocessos activos Janela de Log Para facilitar o desenvolvimento da aplicação é fornecido um programa de teste totalmente funcional, mais um ficheiro glade-2 com a definição da interface gráfica do programa de teste, representada acima. Também o núcleo inicial do programa, e um conjunto de funções para gerir as tabelas gráficas (acrescentar e retirar elementos, pesquisar elementos), ficheiros (calcular comprimentos, valor de hash, juntar ficheiros, abrir directorias, apagar ficheiros, etc.), sockets (ficheiro sock.c), etc. A interface contém uma linha inicial onde se configura o endereço IPv6 multicast e o número de porto, e onde a aplicação escreve o número de porto onde recebe ligações e o número de processo. O botão "Activo" controla o arranque do servidor. Na segunda e terceira linha contém uma tabela (do tipo GtkCList) com a lista de ficheiros partilhados (representa o nome de ficheiro, o comprimento, e o valor de hash do conteúdo do ficheiro). A linha seguinte contém os comandos da lista de ficheiros: permite acrescentar ou remover um ficheiro, e gravar ou ler um ficheiro com uma lista de ficheiros, com o nome representado na caixa à direita. A linha seguinte controla a transferência de ficheiros: permite pedir ficheiros definindo o número de segmentos a usar, parar uma transferência, e escreve a directoria onde os ficheiros temporários, com os segmentos, e o ficheiro final, são escritos. O nome da directoria resulta da concatenação do "output" com o pid do processo. O nome dos ficheiros de saída resulta da concatenação do nome, com o pid, com o número de pedido, e no caso dos segmentos, com o número de segmento. Esta linha inclui ainda um botão para limpar a janela de texto da última linha. A sexta linha contém a lista de sub-processos activos num dado instante, com o número de pid, de pipe, se é emissor (SND) ou receptor (RCV), o valor de "n0 - n1" do fragmento transmitido, a percentagem de bytes transferidos/recebidos, e o nome do ficheiro. A sexta, e última linha, contém uma caixa para escrever mensagens. 6

7 O trabalho deve ser desenvolvido em várias fases distintas: 1. ler e compreender o código que é fornecido com o enunciado do trabalho (ANTES DA PRIMEIRA AULA); 2. terminar a programação da rotina que envia o pacote "Query" e arma o temporizador (de forma a ter apenas um pedido de cada vez); 3. terminar a programação da rotina de recepção de dados UDP, que recebe e trata os pacotes "Hit", guardando-os numa lista; 4. programação da rotina que analisa a lista de resposta, e lança os sub-processos de recepção de ficheiros; 5. Programação das rotinas de recepção de segmento de ficheiro. O ficheiro deve ser guardado na directoria que é criada no botão de arranque para esse efeito. Deve ainda enviar o estado e o resultado final através do pipe; 6. Programação da rotina de recepção de dados do pipe, no programa principal, que actualizam a janela, e que reúnem os vários segmentos do ficheiro, no ficheiro final (é fornecido o código); 7. Programação da rotina de recuperação de erros, caso falhe uma transmissão de segmento de ficheiro. Deve pedir o segmento a outro servidor. 8. Se tiver tempo, programação do emissor de ficheiros criar socket, programar rotina que recebe pedido de ligação e lança sub-processo, que recebe pedido (por ) e envia o ficheiro pedido. 9. Se tiver tempo, teste de velocidade na transferência de ficheiro, modificando a dimensão dos buffers de envio e recepção de dados no nível e no ciclo de envio e recepção do ficheiro nos sub-processos, e o número de feixes em paralelo. Observe-se que o programa de teste é intencionalmente lento porque inclui um 'usleep' no ciclo de envio de ficheiro, que o faz "dormir" durante 5 ms entre envios de blocos do ficheiro. Planeamento (ver o calendário na última página): 1. começar a fase (3) durante a semana 7; 2. começar a fase (5) durante a semana 8; 3. começar a fase (6) durante a semana 9; 4. começar a fase (7) durante a semana 10. Não se esqueça que no dia 28 de Novembro vai ser necessário entregar TODOS os trabalhos. Não deixe para a última semana o que pode fazer ao longo das cinco primeiras semanas, porque NÃO VAI CONSEGUIR FAZER TODOS OS TRABALHOS NESSA SEMANA. Postura dos Alunos Cada grupo deve ter em consideração o seguinte: Não perca tempo com a estética de entrada e saída de dados Programe de acordo com os princípios gerais de uma boa codificação (utilização de indentação, apresentação de comentários, uso de variáveis com nomes conformes às suas funções...) e Proceda de modo a que o trabalho a fazer fique equitativamente distribuído pelos dois membros do grupo. 7

8 DATAS LIMITE O quadro seguinte mostra a datas de entrega o trabalho de avaliação (P): Setembro 2008 Outubro Novembro 2008 Dezembro P