Exercício 3 - Backlog e Processos Zumbis

• Este exercício é em dupla ou individual.
  
• A resolução do exercício deve ser enviada em um arquivo .zip,.rar ou .tar.gz para william@ic.unicamp.br até o dia 01/10/2019. O nome do arquivo deve ser "raXXXXX_e_raXXXXXY_exercicio3", onde XXXXXX e XXXXXY deve ser substituído pelo número do RA dos membros da dupla;
  
• O material a ser entregue no arquivo comprimido será o referente aos passos 1 a 5 deste laboratório assim:
  • todos os códigos implementados (os .c e .h),
  • 1 arquivo .pdf contendo o relatório com os detalhes da implementação do passo 2, respostas dos passos 1, 3 e 4 e detalhes da implementação do passo 5.
• O assunto da mensagem deve ser "[MC833] Exercício 3".
  
• Importante: Não envie código com warnings ;)
  

1. Pesquise como está implementado o backlog (conexões completas + conexões incompletas) de um socket TCP no kernel linux (para versão 2.2 ou mais recentes). O que representa o valor do backlog passado no listen? E o que representa o parâmetro do kernel chamado "tcp_max_syn_backlog"?
   • Dica: use o comando man.
2. Modifique o código do servidor do exercício anterior de modo que o valor do backlog passado para a função listen seja um argumento na linha de comando. Você deve também modificar o código a fim de retardar a remoção dos sockets da fila de conexões completas.
   • Dica: Use a função sleep para isso.
3. Realize experimentos a fim de verificar quantos clientes (de um total de 10) conseguem de imediato conectar-se ao servidor modificado no passo anterior com os seguintes valores de backlog: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 e 10. Elabore algum esquema para tentar conectar os 10 clientes de forma simultânea (Veja as dicas logo abaixo). Relate os experimentos realizados, maquinas usadas para executar o código do servidor, e do(s) cliente(s) e os resultados obtidos (coloque os comando executados junto com suas saídas). Os resultados obtidos condizem com o esperado? Consulte o arquivo /proc/sys/net/ipv4/tcp_max_syn_backlog e verifique o valor de backlog definido na mesma, tente exceder o número de clientes simultâneos definido e verifique o que ocorre.
   • Dica 1: escreva scripts que executam várias instâncias do cliente em um pequeno intervalo de tempo ou utilize algum programa que permita o controle de vários terminais simultaneamente, como o cssh.
   • Dica 2: utilize o netstat para descobrir o número de clientes que conseguem realizar o 3WHS de imediato e estabelecer a conexão (basta contar as linhas da saída do netstat correspondentes a conexões ao servidor que estejam em um estado que comprove a finalização do 3WHS -- lembre-se do diagrama de estados do TCP).
4. Caso seja executado um sniffer no lado do servidor durante os experimentos do passo anterior, quais flags estarão atribuídos nos segmentos TCP capturados para um cliente enquanto ele não conseguir conectar-se ao servidor? Por que isso ocorre?
5. Modifique o código do passo 1 de modo que os processos criados pelo fork sejam corretamente finalizados ao invés de permanecerem no estado zumbi quando um cliente encerra sua conexão.