UNIVERSIDADE FEDERAL DE MINAS GERAIS INSTITUTO DE CIENCIAS EXATAS DEPARTAMENTO DE CIENCIA DA COMPUTACAO REDES DE COMPUTADORES

Trabalho Pratico 2

Sockets UDP, janela deslizante

Professor: Dorgival Olavo Guedes Neto

Alunos: Raphael O. S. M. de Faria Guilherme Maluf M. Balzana {rapha,guimaluf}@dcc.ufmg.br

2 de outubro de 2010

Sumrio a
1 Introduo ca 2 Implementao ca 2.1 Protocolo . . . . . . . . 2.2 Janela Deslizante . . . . 2.2.1 Enquadramento . 2.2.2 Temporizao . . ca 2.3 Controle de Erros . . . . 2 2 2 2 2 3 3 3 3 3 3 4 4 4 4 5 5 5 7 7 8 8 9 9 9 10 10

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

3 Metodologia 3.1 Mtricas e medidas . . . . . e 3.1.1 Primeira abordagem 3.1.2 Segunda abordagem 3.1.3 Terceira abordagem 3.2 Infraestrutura . . . . . . . . 3.2.1 Ambiente local . . . 3.2.2 Ambiente Wireless . 4 Resultados 4.1 Abordagem I . . . . . . . 4.1.1 Ambiente local . . 4.2 Abordagem 2 . . . . . . . 4.2.1 Ambiente H brido 4.3 Abordagem 3 . . . . . . . 4.3.1 Ambiente Local . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

5 Anlise a 5.1 Abordagem 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Abordagem 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Abordagem 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Concluso a

Introduo ca

Esse segundo trabalho prtico tem como objetivo exercitar a prtica de programao utilizando a a a ca biblioteca sockets ao implementar um par de programas, no modelo cliente-servidor, que se comuniquem sobre o protocolo UDP com o algoritmo de janela deslizante. Para isto foi necessrio a criao de a ca novo protocolo em cima da camada UDP envolvendo controles de temporizao, ordem de chegada e ca tratamento de erros.

2
2.1

Implementao ca
Protocolo

Para a implementao do protocolo, optou-se pela simplicidade, portanto o mesmo pacote seria utica lizado para os trs tipos que seriam necessrios: Pacote de dados, pacote Ack, pacote de Final de arquivo. e a Para se atingir este objetivo,sem perda de desempenho, ou seja sem transmitir informaes desnecessrias co a pelo canal (bitstung). Decidiu-se que o campo contedo do pacote seria alocado dinamicamente. Deste u modo pacotes Ack e nais de arquivo teriam o tamanho m nimo necessrio e o pacote de contedo no a u a precisaria deste artif cio. Tendo isto em mente, o modelo do pacote de nosso protocolo foi denido como: Tipo Pacote char(1B) Num pacote u short(2B) tamanho do conteudo u short(2B) DADOS *char checksum u short(2B)

Deve-se notar, que o protocolo no passa de um modelo abstrato, o que realmente passa pela camada a UDP so bytes, portanto foi criado mdulos separados para tratar esta abstrao (protocolo.[c,h]) que a o ca possuem funes lgicas para nosso modelo. co o

2.2

Janela Deslizante

A escolha do modelo de janela deslizante para ser implementada em nosso protocolo, novamente foi baseada na simplicidade, portanto escolhemos o modelo go-back-N, onde a janela do transmissor dada e por um tamanho varivel e a do receptor sempre 1. a e Este modelo facilita bastante a implementao, pois o receptor aceita somente o pacote que ele espera ca e envia Ack s de conrmao apenas para os pacotes j recebidos que possuem sua numerao menor do ca a ca que a do pacote esperado. Quanto a janela do emissor, ela controlada por um vetor de Quadros, onde cada Quadro contm e e uma struct de pacote e uma varivel de conrmao de envio. Ao enviar os pacotes de dados, estes so a ca a armazenados no vetor de Quadros e sua ag de conrmao marcada como no conrmado. Quando ca e a e chegado uma conrmao sua integridade testada e apos isto vericado se o arquivo todo j foi enviado, ca e e a se no, o quadro responsvel por esse pacote atualizado com novas informaes e reenviado, agora se a a e co no h mais dados para ser enviados, o quadro responsvel simplesmente marcado como conrmado. a a a e Deve-se tomar cuidado, neste ponto, quanto ao problema da perda de quadros, portanto utilizou-se um timeout de 1 segundo para o recebimento de Ack s, caso ele seja estourado, re-enviado o pacote que seria e cronologicamente esperado. 2.2.1 Enquadramento

Quanto ao enquadramento dos dados do pacote, como dito anteriormente, foi adotada a ideia de que o tamanho dos dados seriam dinmicos. Isto nos forou a informar no cabealho o tamanho deste dados, a c c desta maneira a simples lgica de contagem de bytes aps este dado, nos forneceria o contedo exato do o o u pacote. Quanto a questo de informar quando o arquivo acabou, como tambm dito antes, adotamos a a e ideia de criar um pacote sem contedo em que seu tipo seria marcado com um char f. u

2.2.2

Temporizao ca

Novamente pensando em simplicidade, escolheu-se adotar a temporizao pelo prprio socket, desta ca o maneira a temporizao efetiva seria quanto ao ultimo pacote recebido. Isto auxiliou bastante em nossa ca implementao pois o timeout so ocorreria no recv() portanto se o emissor no recebeu um Ack esperado, ca a o tratamento de o Ack ter se perdido ou o prprio pacote de contedo, seria exatamente o mesmo, apenas o u re-enviar o pacote contedo. u O valor escolhido para esta temporizao foi de 1 segundo, primeiramente no acreditamos que este ca a valor seria problemtico, porem como os testes mostraram, este valor se mostrou demasiadamente alto e a comprometeu baste nosso desempenho.

2.3

Controle de Erros

O protocolo base UDP, como dito antes no possui controle de erros, portanto foi necessrio criar um. a a Para atingirmos este objetivo utilizamos o paradigma de checkSum para inteiros de 5 bytes. Com isto a deteco destes erros passou a ser tarefa simples, pois so foi preciso vericar o checkSum vindo no pacote ca com o checkSum calculado para o pacote, se eles diferissem o pacote garantidamente foi corrompido e deveria ser descartado.

3
3.1

Metodologia
Mtricas e medidas e

Sero feitas diversas abordagens experimentais com o intuito de analisar o desempenho tanto da rede a como do sistema proposto, cada teste realizado ser repetido cinco vezes e os dados das duas primeiras a vezes sero descartados na tentativa de excluir o efeito de aquecimentodo processo. Alm disto, estas a e abordagens sero repetidas para dois ambientes de teste diferentes, variando entre redes locais (prpria a o maquina) e redes h bridas com wireless e fast-ethernet. Outra observao importante a ser feita: Cada teste ser realizado com uma instancia do sistema ca a cliente-servidor diferente e a funo de sistema gettimeofday ser utilizada para a contagem de tempo. ca a

3.1.1

Primeira abordagem

O intuito desta primeira abordagem calcular o throughput conseguido variando o tamanho do buer e e o tamanho da janela. Com isto espera-se calcular o tamanho da janela ideia para cada ambiente. Para est analise sera utilizado um arquivo de 4, 6M b, que ser enviado de diferentes formas, variando a a o buer nos valores 100B, 1000B, 4000B e o tamanho da janela para 2, 4, 8, 16e32. Para cada um destes envios ser calculado a mdia do thoughput conseguido, o nmero de mensagens enviadas pelo emissor, o a e u nmero de mensagens recebidas do receptor e o tempo mdio. u e Espera-se com este resultado que o resultado vericado seja prximo do algoritmo Stop-and-Wait pois o em nossa implementao Recv s e Send s no so paralelamente implementados e utilizamos o paradigma ca a a go-back-N. 3.1.2 Segunda abordagem

O intuito desta segunda abordagem analisar o desempenho relacionado com perda de pacotes. Para e isto escolheu-se um arquivo de tamanho xo de 269KB, um buer xo de 100Bytes e uma janela xa de tamanho 10 e vericou-se seu desempenho para potencias de sinal diferente no receptor wireless. Nesta anlise mediu-se a quantidade de pacotes enviados pelo receptor e emissor, o n de sinal do a vel recptor wireless e o tempo mdio gasto para transferncia. e e

Espera-se que quanto pior o sinal, mais perdas e erros nos pacotes acontecero e consequentemente a pior desempenho.

3.1.3

Terceira abordagem

Esta ser a abordagem mais simples, pretende-se provar o desempenho linear para o tamanho do a arquivo enviado. Ser enviado arquivos de tamanhos variados (3.2MB 34MB 176MB 343MB) para buer a e janela de tamanho xo.

3.2
3.2.1

Infraestrutura
Ambiente local

Neste ambiente, o sistema cliente-servidor ser executado em uma mesma mquina. Neste caso um a a desktop com as seguintes caracter sticas:
Processador: Amd athlon dual core 64x 5200 2.00 Ghz Memoria: DDR2 400Mhz 2.0 GB S.O: Ubuntu 10.04 kernel: 2.6.32-24-generic x86 64 GCC: gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3

3.2.2

Ambiente Wireless

Neste ambiente, os programas client e servidor sero executados em maquinas diferentes da mesma a rede. O servidor ser executado no desktop mencionado acima (Ambiente Local ) que esta conectado ` a a rede atravs de uma interface Fast-Ethernet. O cliente, por sua vez, ser executado em um notebook, e a que esta conectado atravs de uma interface wireless, cuja congurao : e ca e
Processador: Intel(R) Core(TM)2 Duo CPU T5800 @ 2.00GHz Memoria: DDR2 SDRAM - 800.0 MHz 4GB S.O: Gentoo kernel: 2.6.31-gentoo-r3 x86 64 GCC: gcc (Gentoo 4.3.4 p1.0, pie-10.1.5) 4.3.4

4
4.1
4.1.1

Resultados
Abordagem I
Ambiente local

Tamanho Arq (MB) 4.6 4.6 4.6 4.6 4.6

Buer (Bytes) 100 100 100 100 100

Tabela 1: Desempenho abordagem 1 - Local Tam Janela Tmp Mdio Tmp - Janela thoughput e (s) (s) (Mbps) 2 28.43 26.43 1590.50 4 28.89 24.89 1497.54 8 33.43 25.43 1322.54 16 41.43 25.43 1068.43 32 57.43 25.43 763.95

Pct Env 47732 47734 47738 47746 47762

Pct Recv 47732 47734 47738 47746 47762

Tamanho Arq (MB) 4.6 4.6 4.6 4.6 4.6

Buer (Bytes) 1000 1000 1000 1000 1000

Tabela 2: Desempenho abordagem 1 - Local Tam Janela Tmp Mdio Tmp - Janela thoughput e (s) (s) (Mbps) 2 4.74 2.74 7982.25 4 6.30 2.30 6016.77 8 11.43 3.43 3609.79 16 18.54 2.54 2050.12 32 35.43 3.43 1103.34

Pct Env 4775 4777 4777 4789 4805

Pct Recv 4775 4777 4777 4789 4805

Tamanho Arq (MB) 4.6 4.6 4.6 4.6 4.6

Buer (Bytes) 4000 4000 4000 4000 4000

Tabela 3: Desempenho abordagem 1 - Local Tam Janela Tmp Mdio Tmp - Janela thoughput e (s) (s) (Mbps) 2 4.42 2.42 9858.33 4 6.43 2.43 6465.00 8 10.40 2.40 3831.70 16 18.40 2.40 2123.34 32 34.42 2.42 1132.78

Pct Env 1195 1197 1201 1209 1221

Pct Recv 1195 1197 1201 1209 1221

Figura 1: Tempo mdio e

Figura 2: N. Pacotes x Janela

Figura 3: N.Pacotes (media) x buer

4.2
4.2.1

Abordagem 2
Ambiente H brido

Tabela 4: Desempenho abordagem 2 - H brido

Arq Sinal (KB) (%) 269 35 269 70 269 85 269 = 100

Buer Tam Janela Tmp Mdio thoughput Pct Env e (Bytes) (s) (kbps) 100 10 350 8.91 3035 100 10 61 46 2787 100 10 33 100 2768 100 10 25 125 2760

Pct Recv 3019 2754 2763 2760

Figura 4: Desempenho linear

4.3
4.3.1

Abordagem 3
Ambiente Local

Tabela 5: Desempenho abordagem 3 - Local

Tamanho Arq (MegaBytes) Tamanho Buer Tamanho janela Tempo medio (sec) 3.2 1000 2 2.25 34 10000 2 4.02 176 10000 2 13.43 343 10000 2 25.43

Figura 5: Desempenho linear

5
5.1

Anlise a
Abordagem 1

Esta primeira abordagem nos permitiu observar vrios pontos interessantes. O primeiro deles a a e perde de desempenho causada pela temporizao de 1 segundo. Esta perda pode ser sentida nesta aborca dagem, mesmo sendo em ambiente local, pois em nossa implementao quando a janela sai de regime ca (no precisa enviar novos pacotes), o servidor ainda tem que esperar o timeout de cada quadro da janela, a aumentando assim o tempo gasto em 1 segundo para cada quadro. Este o motivo de todos as tabelas e de desempenho mostrarem o campo T empomedio T amanhoJanela. Outra informao que podemos tirar das tabelas, que como esperado em ambiente local no h ca e a a praticamente perda nenhuma, pois o nmero de pacotes enviados igual o nmero de pacotes recebidos u e u que igual ao nmero exato de pacotes necessrios para enviar o arquivo em questo. e u a a Como dito antes, j espervamos que nossa implementao fosse muito prxima da soluo stop-anda a ca o ca wait, pela gura 1, podemos ver que o tamanho da janela no servidor praticamente no fez diferena a c alguma no desempenho.Novamente, este comportamento era j era esperado por dois grandes motivos, a o primeiro deles, porque os recv s e send s foram implementados de forma sequencial e no paralela como a deveria ser em aplicaes otimziadas e o segundo deles, porque escolhemos o modelo mais simples de co janela deslizante, o go-back-N onde a janela do lado do client sempre igual a 1. e Mais dois resultados previstos que foram comprovados, foram o fato de que o nmero de pacotes enu viados independe do tamanho da janela, como mostra a gura 2, mas depende diretamente do tamanho do buer utilizado, como mostra a gura 3. Isto faz pleno sentido pois o tamanho do arquivo ser divido a pelo tamanho do buer especicado, logo quanto maior o buer menor o nmero de pacotes necessrios. u a

5.2

Abordagem 2

Como especicado anteriormente, o intuito desta abordagem era analisar o desempenho do protocolo em um ambiente onde falhas fossem mais comuns. O esperado era que o desempenho ca drasticamente sse com as perdas de pacote, lembrando que a temporizao de 1 segundo, logo cada ack pacote perdido ca e levaria no m nimo 1 segundo para ser notado, isso sem contar o problema mostrado no comeo da anlise c a

da abordagem 1. Ou seja, o esperado neste teste era que os tempos mdios fossem alt e ssimos como mostra a tabela 4. Atravs desta mesma tabela, temos outros ind e cios para mostrar que houve grandes perdas de pacotes, o primeiro deles, obviamente o sinal de radio do receptor, outro seri a disparidade entre os e a pacotes enviados pelo servidor e os pacotes recebidos pelo cliente, temos ainda um outro que o fato do e nmero de pacotes variar de um teste para o outro. Lembrando que se no houvessem perdas, o nmero u a u de pacotes seria xo em um valor minimo, que seria exatamente aquele que suportaria todo o tamanho do arquivo. Podemos olhar para a gura 4 como outro indicio de que nossas expuies esto corretas, pois quanto co a maior o sinal, menor as perdas portanto menos timeouts acontecero e consequentemente maior banda a ser atingida. a Para efeito de comparao, fez o mesmo teste em ambiente local, gerando os seguintes resultados: ca

Tabela 6: Desempenho abordagem 2 - H brido

Arq Buer Tam Janela Tmp Mdio thoughput Pct Env e (KB) (Bytes) (s) (kbps) 269 100 10 12.43 214.02 2760

Pct Recv 2760

Como pode-se notar o desempenho foi ruim, pelos diversos motivos j apresentados, porem o fato a interessante que podemos tirar disto que o desempenho em sinal prximo a 100% foi metade do deseme o penho em ambiente local, e se lembrarmos o fato de que a velocidade de fast-ethernet 100 mbps que e e aproximadamente o dobro da wireless que chega hoje a 54 mbps, no car a amos to surpreso com estes a resultados.

5.3

Abordagem 3

O intuito desta abordagem era o mais simples poss vel, vericar como o desempenho de nossa soluo ca escala com arquivos cada vez maiores. Como pode ser visto na gura 5, o resultado exatamente como e espervamos, o desempenho decresce linearmente com o tamanho do arquivo enviado. a

Concluso a

Este trabalho foi bastante interessante e desaador, pelo fato de ter que programar em sockets e tratar as caracter sticas do protocolo UDP. Este tipo de programao nos fora a ser mais detalhistas e ca c disciplinados pois estamos em um ambiente em que problemas so comuns e devemos trata-los. Os desaos a de programar sobre o protocolo UDP grande pois s h o bsico implementado, no h garantida de e o a a a a ordem, entrega ou integridade. De maneira geral, foi de grande valia lidar com esses problemas pois ao aplicar os algoritmos aprendidos em sala de aula vivenciamos o processo de criao de nosso prprio ca o protocolo, mesmo que bastante simplista. Por m, gostaria de dizer que o trabalho prtico foi bastante a coerente com sua proposta e proporcionou grandes desaos em sua implementao e lgica. ca o

10