Segundo Trabalho de Programação em Ambientes Limitados

Segundo Trabalho de Programação em Ambientes Limitados

CI097 - Prof. André Guedes Versão 0.3

Parte 1: Implementação de transferência de dados em taxa fixa e constante.

Conteúdo:

Objetivo: ... 1

Especificações: ... 1

Futuro ... 3

Dicas: ... 3

FAQ – Perguntas Frequentes: NOVO ... 3

Critérios para nota: ... 4

Prazo de Entrega e Outros: ... 4

Dúvidas: ... 5

Revisões a este Documento: ... 5

Objetivo:

Devem ser criados dois programas, um cliente e um servidor, que devem conectar-se por um socket UDP. O objetivo primário é conseguir uma taxa de transferência de dados constante (não superior, não inferior) e fixa, determinada pela parametrização do programa.

Transferências em taxa fixa e constante tem diversas aplicações como QOS em redes, Clusters de computadores e comunicação de aplicativos em tempo real ou próximo de real.

O trabalho será dividido em duas partes, e a segunda será uma modificação no que for feito na primeira parte, portanto não deixe de fazer a primeira, ou terá problemas para fazer a segunda.

Leia a especificação até o final antes de sair programando!

Especificações:

O programa deve utilizar sockets no protocolo UDP para a comunicação entre o cliente e o servidor. Códigos de referência desses programas podem ser encontrados em:

http://www.inf.ufpr.br/elias/redes/servudp.c http://www.inf.ufpr.br/elias/redes/cliudp.c

Servidor

O software “servidor” deve gerar bytes numéricos aleatórios e enviar via UDP ao cliente (byte a byte, diretamente no socket), que pode estar na máquina local ou em uma máquina remota em rede local. O servidor envia este stream de bytes aleatórios pelo socket para o cliente a uma taxa de transferência especificada. Para fins de correção do trabalho será utilizada a taxa de 5 MB/s, ou seja, seu programa deve conseguir trabalhar com esta taxa ou inferior. Se conseguir que o programa trabalhe em taxas superiores, melhor.

O programa servidor deve aceitar como parâmetros: Porta em que vai servir o stream de bytes. Velocidade de transmissão em kb/s. Outros parâmetros que possam surgir... Exemplo de linha de comando:

./servidor –porta 12345 –taxa 5242 ...

Cliente

O “cliente” por sua vez deve receber estes dados pelo socket e mostrar na tela uma vez a cada segundo a taxa de bytes recebidos em kb/s, e a variação em relação ao parâmetro de taxa desejada. A saida do programa cliente deve ser semelhante a seguinte:

Recebido a: 5242 kb/s, variação de 0% sobre 5242 kb/s Recebido a: 4980 kb/s, variação de 5% sobre 5242 kb/s Recebido a: 5085 kb/s, variação de 3% sobre 5242 kb/s

Para fins de correção do trabalho, será admitida uma taxa de variação de envio de no máximo 5%. Lembrando que a variação pode ser superior ou inferior.

O programa cliente deve aceitar como parâmetros:

Endereço da localização do servidor que servirá o stream de bytes. Porta, que deve ser a mesma especificada no momento da execução do servidor.

Taxa desejada de recebimento (usada apenas para fins do cálculo de variação em relação ao que foi enviado) em kb/s

Outros parâmetros que possam surgir... Exemplo de linha de comando:

./cliente –end 192.168.0.1 –porta 12345 – taxa 5242 ...

Transferência de Dados entre Servidor e Cliente

A Transferência de dados não pode depender da velocidade do processador da máquina, ou seja, os programas cliente e servidor devem funcionar na mesma taxa

independentemente da velocidade do processador, apenas com recálculo de timing entre os bytes enviados. Como o programa foi especificado para funcionar apenas na mesma máquina ou em rede local, a velocidade da rede não deve ser um empecilho (supondo rede de 100 mbit ou superior).

É permitido no início da transferência que os programas efetuem algum tipo de handshake, de forma a sincronizar a transferência. O programa deve estar também preparado para lidar com concorrência na rede ao máximo ponto em que consiga manter a taxa, ou seja, o programa deve monitorar o uso dos recursos de rede e adaptar-se a maior ou menor concorrência.

Futuro

Este trabalho é dividido em duas partes. A parte 2 será uma modificação em cima da parte 1. Esta seção dá guias para facilitar a programação do que está por vir. Você não é obrigado a implementar o que está descrito nessa seção, mas se o fizer, será mais fácil fazer a segunda parte do trabalho.

O programa deve ser projetado para que o stream de bytes enviado possa ser substituído no futuro por outro tipo de gerador (ex: montagem de pacotes/checksum). Da mesma forma o código de recebimento dos dados deve ser projetado para no futuro incluir checagens (ex: checksum e/ou desmontagem de pacotes) ou operações com os dados recebidos. A segunda parte do trabalho envolverá adaptações nessas duas áreas, que podem exigir também mudança no recálculo do timing entre o envio dos bytes.

Dicas:

Manter taxas altas pode não ser tarefa simples, Uma resposta do cliente indicando para o servidor mandar mais rápido ou mais devagar pode ajudar a fazer correções de estabilização na taxa de envio em tempo real.

Envio da máquina para ela mesma não passa fisicamente pela placa de rede, apesar de utilizar endereços e ter portas. Uma vez a aplicação estando “estável” faça testes de máquina para máquina no laboratório. Você pode não conseguir taxas de 5 MB/s no laboratório, mas ao menos vai ter idéia da confiabilidade e estabilidade dos seus métodos de estabilização da taxa de transferência.

Streams de bytes são mais fáceis de tratar do que pacotes. Lembre-se que no futuro sua aplicação pode vir a utilizar pacotes...

Teste inicialmente com taxas mais baixas, e vá aumentando a medida que seu algoritmo for ficando mais estável. Uma placa de rede de 100 mbits suporta no máximo uma transferência de 12,5 MB/s, então 5 MB/s não usa nem metade desta capacidade.

FAQ – Perguntas Frequentes:

R: Fica a seu critério. Experimente com uma coisa ou outra e veja o que é melhor. Lembre-se que se usar pacotes, o payload do pacote (informação extra como cabeçalho do pacote, etc) também são dados, mas devem ser desconsiderados na contagem.

P: Você quis dizer 5 Megabytes ou 5 megabits ?

R: 5 Megabytes. “MB” usualmente significa megabyte e “mb” ou “mbit” usualmente significa megabit. Digite no google: “100 megabits in megabytes” para ver a conversão.

P: Tem umas taxas erradas lá em cima, nos exemplos de linha de comando e saída do

programa.

R: Não estão mais erradas. Estavam em Bytes, quando deviam estar em Kbytes. Já foi corrigido nesta versão.

P:Qual a velocidade média de voo de uma andorinha ? R: Africana ou Européia ?

Critérios para nota:

Entrega dentro do prazo estabelecido;

Transferência de dados com sucesso na taxa de 5 MB/s com variação de no máximo 5% para cima ou para baixo.

Aditivos (melhoram ou pioram sua nota):

Menor variação das taxas de recebimento;

Transferências em taxas maiores que 5 MB/s. Se conseguir tranferir em taxas maiores, coloque isso no seu explicativo do trabalho;

Menor memória e menos recursos utilizados pelos dois programas; Soluções mais criativas para manutenção da taxa de transferência;

Caminho mais curto para tirar zero:

Falsificar as medidas de transferência ou recebimento; Copiar partes do trabalho de outros grupos;

Utilizar técnicas POG (http://desciclo.pedia.ws/wiki/POG )

Prazo de Entrega e Outros:

O trabalho deve ser feito em grupos de até três pessoas. Recomenda-se fortemente que ao menos uma pessoa de cada grupo tenha feito as disciplinas de Redes 1 e 2, para que o trabalho com sockets não seja uma dificuldade extra.

O prazo de entrega deste trabalho é o dia

23

subsequente incorrerá em diminuição da nota na razão de 15% ao dia.

Deve ser entregue:

Códigos fonte dos programas cliente e servidor, em arquivos ou pastas separadas, com makefiles para facilitar a compilação para correção. É desnecessário dizer que os fontes devem conter comentários que facilitem o entendimento do que foi feito. Explicativo do que foi feito nos programas, especialmente as técnicas usadas para manter e recalcular a taxa de transferência e demais artifícios (não-POG) utilizados e explicações sobre linhas de comando e como por o software para rodar. É desejável que se o trabalho não for desenvolvido nos sistemas da universidade, coloque sistema operacional e versão usada durante o desenvolvimento (é para o seu bem, e com a finalidade de evitar “no meu Linux XYZ funcionava”). Este explicativo deve estar em

TXT, DOC (word) ou ODF (OpenOffice). Não esqueça de colocar neste explicativo o nome dos integrantes do grupo.

Considerações sobre a entrega:

Todos os arquivos especificados acima devem ser compactados em um arquivo zip chamado ci097-trab2.zip e enviados pela página

http://www.geoffmartin.com/trabalho/ . É considerada apenas a última versão entregue, então se entregar antes do prazo e quiser fazer modificações, sinta-se livre para enviar novamente, contanto que não ultrapasse o prazo. O tamanho máximo do arquivo a ser enviado é de 1mb. O sistema bloqueará arquivos maiores. Não envie binários no arquivo, apenas fontes e o arquivo explicativo. Atenção: não envie o trabalho por e-mail.

O trabalho pode ser feito em C ou outra linguagem. No caso de que seja feito em outra linguagem, ainda assim o makefile deve ser criado. No caso de não poder criar o makefile, deve ser provido outro arquivo semelhante (por exemplo: arquivo csproj para projetos em C#) e o nome desse arquivo e instruções de compilação devem constar no arquivo explicativo. No caso do arquivo ser feito em outra linguagem, os sockets UDP não podem ser radicalmente diferentes dos exemplos em C fornecidos.

Dúvidas:

Dúvidas sobre este trabalho ou qualquer esclarecimento deve ser enviado por e-mail para:

Geoffrey Martin, Aluno de Mestrado (geoff arromba ufpr ponto br) Prof. André Guedes (andre arromba inf ponto ufpr ponto br) E se necessário, pode ser marcado um dia para esclarecimento de dúvidas.

Revisões a este Documento:

Versão 0.3 – 12/04/2007 – Geoffrey Martin

- Alteração da data de entrega, inclusão da área FAQ, e pequenos ajustes no

documento.

Versão 0.2 – 04/04/2007 – Geoffrey Martin - Pequenos Ajustes.

Versão 0.1 – 02/04/2007 – Geoffrey Martin - Especificação inicial.

Atenção: Mudanças a esta especificação podem ser feitas a qualquer momento. Confira a página da disciplina com frequência para não ter surpresas no último dia de entrega!