Atualizado em 26/09/2008
Atividade 3 (obrigatória): Serviço de eco usando sockets UDP
- Utilize parte do programa talker.c
e o esqueleto da atividade opcional a1.html
de forma a torná-lo um cliente UDP do serviço de eco (chame-o cludp_echo.c).
Use connect() nos dois lados da comunuicação para torná-la mais eficiente.
Sinalize o término da transmissão do arquivo enviando ao servidor um
datagrama extra contendo 0 bytes.
-
Utilize parte do programa
listener.c
e o esqueleto da atividade opcional a1.html
de forma a torná-lo um servidor UDP iterativo do serviço de eco (chame-o
server_echo.c).
V. deve contar o número de datagramas recebidos e o total de bytes recebidos,
mostrando esses valores na saída de erro (stderr) após receber do
cliente um datagrama com 0 bytes (sinalizando assim, o término da transmissão).
O servidor deve então voltar ao laço principal para receber um novo arquivo para ecoar
(possivelmente de um cliente distinto do anterior).
Como datagramas podem ser perdidos com o protocolo UDP
Você deve colocar um temporizador antes do servidor se bloquear à espera de
um datagrama (veja, por exemplo, man alarm). No caso da temporização expirar
o servidor deverá se "desconectar" (*)
do cliente, emitir as estatísticas coletadas até então e voltar ao laço principal
de espera por um novo arquivo .
-
Meça o tempo para ecoar o arquivo /etc/termcap com o cliente e o servidor em subredes distintas.
Verifique que o número de linhas e de bytes enviados e recebidos é igual
ao da saída do comando wc /etc/termcap.
- Teste a recuperação do servidor via temporizador, fazendo o cliente deixar de enviar o
datagrama extra com 0 bytes (ou parando de enviar em qualquer ponto da comunicação com o servidor).
- Modifique o seu programa cludp_echo.c (chame-o agora flood.c)
a fim de mostrar que o protocolo UDP pode perder datagramas, da seguinte forma:
flood.c apenas lê o arquivo da entrada padrão e o envia (linha por linha) para o servidor
srvudp_echo.c e deve ignorar (ou seja, não receber via recv/recvfrom() ) os datagramas
ecoados pelo servidor.
Após enviar um arquivo grande como /etc/termcap o servidor geralmente vai
contabilizar um número de datagramas e de bytes recebidos menor do que o enviado
pelo cliente. Para que o teste funcione é preciso que a CPU do cliente seja mais veloz
que a do servidor. Você pode descobrir a velocidade da cpu com o comando:
less /proc/cpuinfo (a xaveco tem um clock de 3 Ghz).Faça vários testes
verificando o número total de datagramas e de bytes recebidos pelo servidor
(existe a possibilidade do servidor perder o último datagrama com 0 bytes;
por precaução faça o seguinte: (i) dê um atraso de 1 segundo antes de enviar
o datagrama com 0 bytes (sleep(1)),
ou, (ii) faça o cliente enviar vários datagramas com 0 bytes)
Entregue impressões dos programas cludp_echo.c, srvudp_echo.c e flood.c
Não precisa entregar as modificações do item 2.ii acima.
(*)Veja nas notas de aula o uso do parâmetro AF_UNSPEC na função connect().
Após executar esta função o servidor deverá fechar o socket corrente (via close()) e ao
voltar ao laço principal criar um novo socket para receber datagramas de um novo cliente.