Proj1s2007.html

O objetivo deste projeto é desenhar e implementar protocolos das camadas de rede, transporte e aplicação para uma rede virtual. Trata-se de tarefa desafiadora que é necessária para o entendimento em profundidade das redes de computadores. Este documento apresenta uma especificação genérica da funcionalidade dos protocolos, que poderá ser ajustada às preferências de projeto de cada grupo.

Esta especificação está baseada em propostas de projetos finais de disciplinas similares oferecidas pela PUC-Campinas e por outras instituições, em especial [1] e [2].

Emulação da Topologia da Rede

Cada nó da rede virtual será emulado por uma instância de execução do programa desenvolvido, endereçada por um par (<endereço da máquina>,<porta UDP>). Uma mesma estação poderá, portanto, executar vários nós virtuais.

Um Arquivo de Configuração Inicial (ACI) especificará os nós da rede virtual e as ligações entre eles. A instância do programa que implementa a pilha de protocolos de um nó receberá dois argumentos na linha de comando, o nome do arquivo de configuração e o identificador do nó que o respectivo processo deverá emular. Por exemplo, a topologia ilustrada pela figura 1, seria descrita por um arquivo com o seguinte conteúdo:

// top_1.cnf

1 (10.0.0.2 5000) (2 1000)

2 (10.0.0.2 5001) (1 2000) (3 2000) (4 3000)

3 (10.0.0.3 5000) (2 1000) (4 3000)

4 (10.0.0.4 5000) (2 1000) (3 2000)

A primeira linha do arquivo é um comentário, que indica o nome do arquivo de configuração. A segunda linha do arquivo especifica que a instância que emula o nó 1 da rede virtual está localizado na estação com endereço IP 10.0.0.2 e comunica-se com as demais instâncias (nós) usando a porta UDP 5000. Essa linha especifica ainda que o nó 1 está ligado ao nó 2 e o MTU (Maximum Transfer Unit) nesse enlace é de 1000 bytes. A terceira linha indica que o nó 2 localiza-se também na estação com endereço IP 10.0.0.2 e utiliza a porta UDP 5001 para comunicação, estando ligado aos nós 1, 3 e 4, etc.

O arquivo de configuração poderá incluir um número arbitrário de espaços entre argumentos sucessivos e linhas em branco. Não deve ser feita distinção entre caracteres maiúsculos e minúsculos, ou seja a interpretação do arquivo de configuração é insensível à caixa dos caracteres (case insensitive).

Supondo que o programa executável que implementa a pilha de protocolos chame-se ptc_redes, e que o arquivo de configuração chame-se top_1.cnf. Para emular a rede do exemplo acima deve-se executar quatro instâncias de ptc_redes. Observe-se que ptc_redes recebe 2 argumentos, o nome do arquivo de configuração e o identificador do nó a emular.

O ACI define a topologia inicial da rede. Essa topologia inicial será conectada, ou seja, haverá um caminho entre os nós da rede, ainda que indireto. Lendo o ACI, cada nó identificará os seus vizinhos na rede. Após a iniciação, o protocolo de roteamento deverá ser capaz de encontrar os demais nós na rede e o próximo salto (hop) para esses nós. O protocolo de roteamento deverá também detectar mudanças na topologia e reagir a elas determinando novas rotas de menor custo. Dois tipos de mudanças de topologia podem ocorrer:

1. Falha de nós, decorrentes do cancelamento dos processos que emulam os correspondentes nós da rede.

2. Falha de enlaces, decorrente da remoção (lógica) de enlaces específicos.

Ambas falhas podem ser permanentes ou temporárias. Ou seja, nós ou enlaces que foram removidos poderão ser reiniciados. Entretanto, não haverá a introdução de nós ou enlaces que não estejam presentes na topologia inicial.

Assuma que o número de nós da rede será de até 32, o número de enlaces de até 128 e o número de enlaces por nó de até 8.

Emulação de Enlaces Ponto-a-Ponto

Os enlaces especificados no AIC serão emulados através da troca de datagramas UDP entre os processos que emulam os nós conectados na rede virtual. Por exemplo, se o nó 1 estiver conectado ao nó 2, qualquer mensagem que ele deseje enviar ao nó 2 deverá ser encapsulada em um datagrama UDP e enviada para o processo que emula o nó 2 através de um soquete UDP.

O MTU de cada enlace é especificado no AIC. A presença de enlaces com diferentes MTUs significa que deverá ser suportada a fragmentação de pacotes na camada de rede.

Considerando que a rede local dos nossos laboratórios é bastante confiável, não se espera a ocorrência de erros de rede. Para tornar o projeto mais desafiador, será introduzido um módulo adulterador de pacotes entre o protocolo de camada de rede implementado e o UDP. Sempre que for enviado um pacote de um nó a outro, o adulterador irá introduzir, de acordo com uma dada probabilidade, os seguintes tipos de erros:

1. Perda do pacote

2. Corrupção de um ou mais bits do pacote

3. Duplicação do pacote

O código fonte do modulo adulterador deverá ser integrado ao código produzido. Para usar o adulterador, deve-se trocar todas as instâncias de chamadas à primitiva sendto, da API sockets, por sendto_garbled. Ambas as funções têm exatamente os mesmos argumentos.

A Camada de Rede

O Protocolo de Datagramas de Rede (PDR)

O protocolo de rede usará os enlaces ponto-a-ponto para transferir pacotes de um nó da rede para outro, mesmo quando eles não estejam diretamente conectados. Essa funcionalidade será oferecida pelo Protocolo de Datagramas de Rede (PDR) que deverá ser projetado. O PDR deverá ter as seguintes características:

· O PDR será baseado em datagramas, ao invés de circuitos virtuais.

· O PDR não será confiável, isto é, ele não trata erros, perdas ou duplicações de pacotes.

· O PDR deverá incluir um campo de TTL (Time to Live) no cabeçalho para evitar que pacotes circulem pela rede indefinidamente.

· O PDR deverá transportar pacotes de tamanho variável, desde que menores que o MTU do enlace ponto-a-ponto subjacente.

· O PDR deverá tratar enlaces com diferentes MTUs, logo, deve suportar a fragmentação de pacotes. A remontagem de fragmentos de pacotes deve ser feita pelo PDR do receptor.

· O PDR deverá ser capaz de demultiplexar pacotes entrantes para diferentes protocolos de transporte.

O Protocolo de Roteamento (PR)

Cada nó manterá uma tabela de roteamento que fornecerá o próximo passo para cada nó de destino. A tabela de roteamento será construída por um Protocolo de Roteamento por Vetor de Distâncias (PRVD). O PRVD deverá ter as seguintes características:

· O PRVD será um protocolo do tipo vetor de distâncias, em vez de estado do enlace.

· O PRVD detectará mudanças na topologia da rede e reagirá a elas recalculando as rotas de menor custo.

· O PRVD usará o PDR, ou seja, todos os pacotes produzidos pelo PRVD são encapsulados em pacote PDR.

Deve-se observer que os pacotes do PRVD também estão sujeitos a serem adulterados, já que eles são encapsulados em pacotes do PDR , que não é confiável. Logo, é importante prover o PRVD com mecanismos que lide com os possíveis efeitos negativos decorrentes de perdas, erros e duplicação sobre as decisões de roteamento.

A Camada de Transporte

O PDR oferece um servido de entrega de pacotes fim-a-fim , mas ele não é confiável. Ele não efetua controle de fluxo e não fornece uma semântica de comunicação do tipo fluxo de bytes (byte stream). Esta é a tarefa do Protocolo de Transporte Confiável (PTC) a ser projetado. O PTC terá as seguintes características:

· O PTC oferecerá uma semântica de comunicação representada por um fluxo de bytes bidirecional e confiável. Para isso, o PTC deverá tratar perdas, duplicações de pacotes, e entrega de pacotes fora de ordem. Note que a entrega de pacotes fora de ordem pode ocorrer devido à possibilidade de haver mudança dinâmica de rotas enquanto uma transferência estiver em progresso.

· O PTC permitirá demultiplexar pacotes recebidos para até 256 “pontos de serviço” (portas) no nó receptor.

· O PTC usará um algoritmo de janela deslizante para implementar controle de fluxo e confiabilidade.

· O tamanho máximo da janela deve ser de 16.000 bytes.

· O PTC deverá usar um algoritmo de soma de verificação (checksum) para detecção de erros.

· O PTC deverá usar confirmações seletivas.

· O PTC deverá usar os maiores pacotes que o MTU do enlace do emissor permita.

A Camada de Aplicação

Na camada mais alta, será implementada uma aplicação simples de transferência de arquivos e de gerência da rede. Esta aplicação, chamada Transferência Não-bloqueante de Arquivos (TNA), irá rodar em cada um dos nós da rede emulada.

A TNA fornecerá aos usuários uma interface de linha de comando. A interface será não-bloqueante, no sentido de que a solicitação de execução de um comando deverá retornar “imediatamente” sem esperar que a correspondente operação (por exemplo, uma transferência de arquivo) seja completada. Note que a natureza não-bloqueante da aplicação implica, entre outras coisas, em que a implementação deverá conter múltiplas linhas de execução (multi-treaded), com uma linha para cada transferência em curso.

A interface da TNA irá permitir o estabelecimento de conexões com nós remotos, a definição do tamanho da janela das conexões, a transferência de arquivos e algumas outras operações de “gerência da rede”. A lista a seguir apresenta as operações que a interface deverá suportar. A interpretação de comandos e de seus argumentos deve ser insensível à caixa dos caracteres (“case-insensitive), sendo permitidos números arbitrários de espaços e linhas em branco:

iniciar_serviço(MaxConex), is(...)
define um ponto de serviço no nó local. O comando retorna um Identificador de Serviço (IdS) IS, que é único para cada ponto de serviço no nó. Outros nós podem conectar-se a IS e descarregar arquivos a partir desse ponto de serviço. O argumento MaxConex indica o número máximo de conexões abertas que IS pode aceitar. Requisições para mais de MaxConex conexões são rejeitadas. Exemplos de mensagens de resultado:
" iniciar_serviço(3) - Sucesso: IdS=123, MaxConex=3"
" iniciar_serviço(0) - Falha: MaxConex =0 argumento inválido"
parar_serviço(IS), ps(...)
requisita o término do serviço com IdS IS do nó local. Todas as conexões abertas em IS serão canceladas. Exemplos de mensagens de resultado:
" parar_serviço(123) - Sucesso: IdS=123 terminado"
" parar_serviço(200) - Falha: IdS=200 não existe "
conectar(NóDest, IS, TamJan), c(...)
requisita o estabelecimento de uma conexão entre o nó local e o ponto de serviço IS no nó remoto NóDest. A janela da conexão deverá ter tamanho TamJan. O comando retorna um Identificador de Conexão (IdC) único para cada conexão aberta no nó local. Exemplos de mensagens de resultado:
" conectar(2, 123, 15000) - Sucesso: NóDest=2, IdS=123, IdC=3, TamJan=15000 bytes"
" conectar(3, 123, 15000) - Falha: NóDest =3, tempo de espera por conexão expirado"
" conectar(3, 123, 15000) - Falha: NóDest=3, requisição de conexão rejeitada "
desconectar(IC), d(...)
fecha a conexão com IdC IC. Exemplos de mensagens de resultado:
" desconectar(3) - Sucesso: IdC=3 foi fechada "
" desconectar(7) - Falha: IdC=7 não está aberta "
" desconectar(8) - Falha: IdC=8 não pode ser fechada "
baixar(IC, Arq), b(...)
solicita a transferência de um arquivo remoto com o nome Arq através da conexão com IdC IC. A transferência será possível apenas se a conexão não estiver ocupada com outra operação de transferência. O arquivo Arq deve estar presente no diretório de trabalho do processo que emula o nó remoto. Quando a transferência estiver completa, uma mensagem deve indicar a duração e vazão media da transferência. Uma mesma conexão pode ser usada para várias operações (não simultâneas) de descarga. Exemplos de mensagens de resultado:
" baixarr(4, foo) - Sucesso: Arquivo=foo foi descarregado (duração=3s, vazão=160 Kbps)"
" baixarr(4, bar) - Falha: Arquivo=bar não existe "
" baixarr(5, foo) - Falha: IdC=5 não existe"
" baixarr(6, bar) - Falha: IdC=6 está ocupada com outra transferência "
" baixarr(7, bar) - Falha: IdC=7 está quebrada"
conf_adulterador(Perda, Corrupção, Duplicação), ca(...)
configura os parâmetros no modulo adulterador do nó local.

Perda: fração de pacotes perdidos (entre 0 e 100)
Corrupção: fração de pacotes corrompidos (entre 0 e 100)
Duplicação: fração de pacotes duplicados (entre 0 e 100)

Exemplos de mensagens de resultado :
" conf_adulterador(1, 1, 2) - Sucesso: Perda=1%, Corrupção=1%, Duplicação=2%"
" conf_adulterador(120, 1, 2) - Falha: Perda =120%, argumento inválido"

tabela_roteamento, tr
imprime a tabela de roteamento local, isto é, para cada nó da rede, mostra o correspondente próximo passo e o custo da rota em termos do número de passos a percorrer.
desabilitar_enlace(NóRem), de(...)
desabilita o enlace entre o nó local e o nó remoto NóRem. Exemplos de mensagens de resultado:
" desabilitar_enlace(2) - Sucesso: o enlace com o nó 2 foi desabilitado "
" desabilitar_enlace(7) - Falha: não há enlace com o nó 7 "
" desabilitar_enlace(3) - Falha: o enlace com o nó 3 já está desabilitado "
habilitar_enlace(NóRem), he(...)
habilita o enlace entre o nó local e o nó remoto NóRem. Exemplos de mensagens de resultado:
" habilitar_enlace(2) - Sucesso: enlace com o nó 2 foi habilitado"
" habilitar_enlace(7) - Falha: não há enlace com o nó 7"
" habilitar_enlace(3) - Falha: o enlace com o nó 3 já está habilitado"
depurar, dp
mostrará informações importantes sobre o nó local, tais como, pontos de serviço ativos, conexões abertas, estatísticas diversas etc.
sair, s
terminar o programa.

Relatório de Projeto

Todo programa deve conter uma documentação interna (os comentários no código fonte) e uma documentação externa (um relatório). Há várias questões a respeito do programa que o relatório deve ajudar a responder:

Que problema o programa resolve?
Como usá-lo?
Como ele funciona?
Quão rigorosamente ele foi testado?
Como o programa pode ser modificado para fazer algo similar?

O relatório a ser entregue deve ter as páginas numeradas e incluir as seguintes partes e seções:

Folha de rosto: nome da Universidade, nome do curso, nome da disciplina, professor responsável, identificação da atividade, data, nomes e RAs dos integrantes do grupo

Sumário (índice), logo após a página de rosto: títulos das seções e subseções com os números das respectivas páginas.

1. Introdução: Uma descrição sucinta do problema que se pretende resolver.

2. Especificação dos protocolos: funcionalidade e algoritmos dos protocolos, campos dos cabeçalhos e tipos de mensagens; passos de processamento associados ao envio e recepção das mensagens do protocolo. Especificar formalmente os protocolos usando diagramas de transição de estados (máquinas de estados), como os ilustrados no livro-texto.

· Modificações com relação à versão anterior do relatório: indicar quais foram as modificações realizadas e as respectivas justificativas.

3. Plano de implementação: Informações relevantes sobre como se pretende implementar os protocolos, incluindo, quantas linhas de execução (threads) serão necessárias em cada nó da rede? O que cada linha fará? Que linhas precisam se comunicar, e como? Que linhas precisam compartilhar dados, e que estruturas de dados são essas?

· Modificações com relação à versão anterior do relatório.

4. Plano de integração e teste. Projetos de software de médio e grande porte requerem uma quantidade significativa de teste e depuração durante a integração de seus componentes. É aconselhável reservar pelo menos 20% de todo o tempo a ser despendido no projeto para as atividades de teste e depuração do sistema completo.

· Modificações com relação à versão anterior do relatório.

5. Compilação e execução do programa (apenas na versão final): Fornecer as instruções necessárias à compilação e execução do programa. Não esquecer de informar que recursos deverão estar disponíveis para que se possa gerar e executar o programa.

6. Cronograma e divisão de responsabilidades:

· Cronograma detalhado de implementação, semana a semana.

· Divisão de tarefas entre os membros do grupo. Uma boa abordagem é ter duas pessoas responsáveis por cada componente de código, mesmo que um seja o responsável principal e o outro faça o papel de revisor e consultor.

· Modificações com relação à versão anterior do relatório.

7. Considerações finais (apenas na versão final):

· Apresentar de forma resumida aspectos pedagógicos que os autores consideram importante salientar, incluindo o que foi aprendido, dificuldades encontradas e sugestões que permitam melhor a atividade para turmas futuras.

Referências e Bibliografia

Referenciar as fontes usada para a elaboração do projeto, incluindo livros e recursos obtidos na Internet. Seguir a norma da ABNT (veja página da biblioteca da PUC).

Cronograma Básico

9/2:

· Envio de mensagem indicando a composição dos grupos de projeto. Ver instruções no cronograma detalhado.

8/3 (P2) 15/3 (P1):

· Entrega do relatório de projeto.

~~17/4 (P1) 19/4 (P2):~~ Entrega da implementação básica do programa

24/4 (P1) 26/4 (P2) - Apresentação da versão básica do programa.

· Esta versão do programa deve incluir toda a pilha de protocolos, mas com as seguintes simplificações:

o Não haverá mudanças na topologia.

o Não será usado o adulterador de pacotes.

o Todos os enlaces terão o mesmo MTU.

· Trazer código em disquete, CD, ou cartão de memória USB

23/5 - Entrega da implementação final do programa
30/5 - Entrega da implementação final do programa

Enviar mensagem com o seguinte campo assunto:
REDESII_P<turma>_G<grupo>_PROJ_FINAL
onde o símbolo <turma> deverá ser substituído pelo número da turma prática do grupo (1 ou 2) e <grupo> pelo número do grupo autor do projeto. Exemplo: REDESII_P1_G8_PROJ_FINAL

Anexar arquivo com o mesmo nome do campo assunto e extensão .zip. Por exemplo REDESII_P1_G8_PROJ_FINAL.zip O arquivo deverá conter:

· Relatório de projeto atualizado em arquivo com o nome Relatório no formato doc, pdf ou html

· Diretório de nome código com os fontes necessários à geração do executável (não incluir os executáveis): Os módulos (funções, classes ou pacotes) deve ter comentários que indiquem o nome do respectivo autor

31/5, 5/6, 12/6, 14/6 - Apresentação e modificação do programa.

Entregar cópia impressa da versão final do relatório de projeto.
Trazer código fonte em disquete, CD, ou cartão de memória USB.

Obs. Este cronograma poderá ser ajustado em função do andamento do semestre.

Avaliação

Se Funcionalidade >= 5,0

NotaProjeto = (0,6 * Funcionalidade + 0,2 * Relatórios + 0,2 * Fonte + Andamento) * Apresentação

Senão

NotaProjeto = Funcionalidade

Onde,

· Funcionalidade (0..10): considerará o atendimento aos requisitos funcionais estabelecidos e a confiabilidade do programa (não “trava”), verificados na demonstração do programa e nos testes realizados e documentados.

Fucionalidade = 0,4 * (Func. da implementação básica) * 0,6 (Func. da implementação final)

· Relatórios (0..10): A não ocorrência de mudanças substâncias entre o previsto no relatório de projeto entregue inicialmente e a sua realização contarão positivamente.

Relatórios = 0,7 * (Relatório inicial) + 0,3 * (Relatório final)

· Fonte (0..10): considerará, principalmente, a legibilidade do programa e o uso adequado dos recursos da linguagem, das bibliotecas e do sistema operacional.

· Andamento (-2..0,2): A nota iniciará com o valor 0,2, sendo decrementada de 0,2 ponto a cada reunião em que não for observado progresso no trabalho do grupo.

· Apresentação (0..1): Nota que reflete o conhecimento demonstrado pelos elementos do grupo escolhidos para apresentar o projeto e modificar o programa produzido.

Referências

[1] Adán Coello, J. M. Transferência Confiável de Fluxos de Bytes Sobre uma Rede de Datagramas. Projeto Final da disciplina Laboratório de Redes de Comutadores. Curso de Engenharia de Computação da PUC-Campinas. 2º. Semestre de 2001.

[2] Dovrolis, C. Design and implementation of a reliable transport protocol over an unreliable and dynamic datagram network. Term Project. CS 4251: Computer Networks II. Fall 2004, Spring 2004.
http://www.cc.gatech.edu/classes/AY2005/cs4251_fall/project_1.html

Proj1s2007.html

REDES DE COMPUTADORES II

Esta especificação está baseada em propostas de projetos finais de disciplinas similares oferecidas pela PUC-Campinas e por outras instituições, em especial [1] e [2].

[2] Dovrolis, C. Design and implementation of a reliable transport protocol over an unreliable and dynamic datagram network. Term Project. CS 4251: Computer Networks II. Fall 2004, Spring 2004. http://www.cc.gatech.edu/classes/AY2005/cs4251_fall/project_1.html

[2] Dovrolis, C. Design and implementation of a reliable transport protocol over an unreliable and dynamic datagram network. Term Project. CS 4251: Computer Networks II. Fall 2004, Spring 2004.
http://www.cc.gatech.edu/classes/AY2005/cs4251_fall/project_1.html