REDES INTEGRADAS DE TELECOMUNICAÇÕES I 2003 / 2004

Transcrição

1 UNIVERSIDADE NOVA DE LISBOA Faculdade de Ciências e Tecnologia Departamento de Engenharia Electrotécnica REDES INTEGRADAS DE TELECOMUNICAÇÕES I 2003 / 2004 Licenciatura em Engenharia Electrotécnica e de Computadores 4º ano 8º semestre 2º Trabalho Prático: Chat multicast com troca de ficheiros para IPv6 Luis Bernardo

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 de conversa em grupo numa rede dual stack. A aplicação regista-se num endereço IPv6 Multicast, enviando periodicamente um pacote de registo do nome do participante. Desta forma, cada participante tem uma imagem actualizada de todos os participantes na conversa. A aplicação permite o envio de mensagens de texto para o grupo (usando sockets ), ou o envio de ficheiros entre dois participantes utilizando sub-processos (através de sockets ). O trabalho consiste no desenvolvimento de um executável:. 2. Especificações A aplicação necessita de três parâmetros de configuração: o endereço IP Multicast do grupo (por defeito vai-se usar o endereço "ff18:10:33::1"), o número de porto (por defeito vai-se usar o porto 20000), e o nome do utilizador (e.g. "Grupo 21") Canal Multicast IPv A aplicação troca mensagens de registo no grupo e de utilizador utilizando um socket datagrama. Para receber e enviar dados para o grupo usa um socket associado ao grupo e configurado para o número de porto. 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 começa por aguardar que o utilizador configure o canal (endereço IPv6 + número de porto) onde pretende escutar. Após o utilizador premir um botão, a aplicação arranca uma tarefa de registo periódico do nome do utilizador, e fica preparada para enviar ou receber mensagens ou ligações nos sockets. Quando o utilizador escolher o envio de um ficheiro para um dos participantes no grupo, dever-se-á abrir uma nova janela onde é seleccionado o ficheiro a enviar, e deve ser lançado um

3 sub-processo que abre um novo socket e trata do envio do conteúdo do ficheiro. Após a recepção de uma nova ligação, também deve ser criado um sub-processo para receber o ficheiro. A janela principal deve listar todos os sub-processos activos, os ficheiros recebidos, e os bytes transferidos ou o ritmo de transferência. Um temporizador de inactividade (opcional) permitirá lidar com a terminação abrupta do participante remoto da ligação. Para facilitar o desenvolvimento do trabalho, é fornecido um ficheiro de especificação de interface "demo_t2.glade" com a janela principal do programa, mais algumas funções adicionais de acesso à interface gráfica e de interacção com sockets Registo do nome A partir do momento em que ficar activa, a aplicação deverá enviar um pacote de registo do nome para o endereço IPv6 multicast, de 20 em 20 segundos. Este pacote identifica o utilizador, e simultaneamente, anuncia o endereço IPv6 e o número de porto do socket, usado nas transferências de ficheiros. A mensagem enviada para o grupo consiste num octeto com o tipo de mensagem, seguida do número de porto do socket, e de uma cadeia de caracteres com o nome que se pretende registar (terminado com o caracter '\0'). A mensagem de cancelamento de registo tem uma estrutura semelhante. Mensagem registo/cancelamento de nome: { sequência contígua de } unsigned char tipo; // tipo de mensagem - Registo=21 /Cancelamento=20 unsigned short porto; // porto do socket char *nome; // array de caracteres terminado por '\0' 1 2 strlen(nome)+1 Registo tipo porto nome tipo= 21 Cancelamento tipo= 20 A aplicação deverá apresentar a lista de participantes do grupo numa tabela (componente GtkCList) permitindo uma visualização fácil de quem pertence ao grupo. Extra: Um participante no grupo pode terminar sem enviar o pacote de cancelamento de registo no nome. Caso não seja recebido nenhum pacote de registo do nome de um utilizador ao fim de 40 segundos o utilizador deverá ser retirado do grupo. Há várias hipóteses para medir o tempo: criar um temporizador por cada utilizador activo no sistema que é reinicializado de cada vez que se receber um pacote de registo; ter um registo do último acesso que é verificado periodicamente; etc. Não é necessário que seja exactamente 40 segundos, mas que a partir de 40 segundos o utilizador seja retirado da lista Envio de mensagens para o grupo A aplicação deverá permitir enviar mensagens de texto para o grupo de participantes (endereço IPv6 multicast). A estrutura desta mensagem é idêntica à das mensagens de registo e cancelamento do nome, devendo a mensagem ser terminada pelo caracter '\0'. O tipo da mensagem de dados tem o valor 10. 3

4 1 2 strlen(msg)+1 Dados Multicast 10 porto msg 2.3. Transferência de ficheiros A aplicação deverá permitir a troca de ficheiros entre dois participantes no grupo. A leitura e escrita dos ficheiros deve ser realizada em sub-processos criados no emissor e no receptor do ficheiro. Após seleccionar o ficheiro a enviar, o emissor deve criar um sub-processo de envio de ficheiro (1), que cria um socket temporário para enviar o ficheiro. Após o cliente estabelecer ligação (2), é disparada no receptor a callback de aceitação de ligações. Esta callback deverá também lançar um sub-processo (3), que fica em ciclo a receber o ficheiro e a escrevê-lo num ficheiro de saída. pipe sinal SIGUSR1 (1) (2) (4) pipe (3) sinal SIGUSR1 No canal de comunicação entre o emissor e o receptor (4), o envio do ficheiro deve ser precedido do envio de um cabeçalho com a seguinte estrutura: Cabeçalho de ficheiro: { sequência contígua de } int len_nome; // Comprimento do nome do emissor (máx 128 bytes) char *nome; // array de caracteres terminado por '\0' int len_filename; // Comprimento do nome do ficheiro (máx. 256 bytes) char *filename; // array de caracteres terminado por '\0' long filelength; // Comprimento do ficheiro a transmitir 4 len_nome len_nome nome 4 len_filename 4 len_filename filename filelength 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 receptor); 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. 4

5 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. 3. Desenvolvimento da aplicação 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 à esquerda. A interface contém uma linha inicial onde se configura o endereço IPv6 multicast, o número de porto, e o nome do participante. 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 participantes activos na rede (representa o endereço IP, o porto, o nome e o número de intervalos de duração 20 segundos em que esteve inactivo. Na quarta linha contém um entry para escrever uma mensagem e um conjunto de quatro botões para: enviar mensagem para grupo, enviar ficheiro, parar o envio de um ficheiro, e limpar a janela de texto da sexta linha. Na quinta 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 nome do parceiro, o número de bytes transferidos/recebidos, e o nome do ficheiro. A sexta e última linha contem uma caixa para escrever mensagens. O trabalho deve ser desenvolvido em várias fases distintas: 1. inicialização e paragem dos sockets e, no botão de arranque; 2. programação do temporizador de envio do nome, que de 20 em 20 segundos envia o pacote de registo no socket. Modificação do botão de arranque para registar/cancelar registo. 3. programação da rotina de recepção de dados, que recebe e trata o registos/cancelamentos, preenchendo a janela de participantes. 4. programação do envio da mensagem para o grupo 5. Programação das rotinas de envio de ficheiro, incluindo as rotinas de tratamento do sinal SIGCHLD, SIGUSR1, e a rotina principal de envio do ficheiro. 6. Programação das rotinas de recepção do ficheiro. O ficheiro pode ser guardado num ficheiro de nome 'file000.out', onde o número é incrementado por cada ficheiro recebido, ou numa subdirectoria. Evite escrever na directoria onde tem o executável para não perder nenhum ficheiro inportante (e.g. callbacks.c). 7. Programação da rotina de recepção de dados do pipe, no programa principal, e que enviam as mensagens nos sub-processos. 8. Programação do algoritmo de exclusão dos participantes que não enviaram mensagens durante 40 segundos. 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. Observe-se que o programa de teste 5

6 é 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. Para se conseguir chegar ao fim das seis semanas do trabalho com tudo pronto é necessário utilizar todas as aulas práticas, devendo-se: começar a fase (3) durante a semana 8; a fase (5) durante a semana 9; a fase (6) durante a semana 10; e concluir a fase (7) durante a semana 11. 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. DATAS LIMITE A parte laboratorial é composta por dois trabalhos de avaliação. A duração prevista para o segundo trabalho é de 6 semanas. O trabalho tem o seu início formal na semana de 13 de Abril. O quadro seguinte mostra as datas de entrega de cada trabalho de avaliação (P) e as datas previstas para os testes teóricos (T): Março 2004 Maio P T Abril 2004 Junho P P T