Modificada: 29/8/05

Curso de Engenharia de Computação - Redes de Computadores I / 2s2005

Atividade 5# ( 9 pontos)

 

Entrega

·        T1( 4ª) entrega 23/9 (6a.)

·        T2 (2ª) entrega  21/9 (4ª)

·        T3,T4 (6ª) entrega 26/9 (2ª)

 

ObjetivoObter conhecimentos básicos para o desenvolvimento de servidores com conexão concorrentes

 

Para esta atividade você precisará estudar o código de dois servidores para o serviço ECHO:  TCPmtechod e TCPmechod. O primeiro é um servidor concorrente, implementado por um processo e várias linhas de execução (multithread), baseado no algoritmo 4 apresentado no texto Projeto e implementação de servidores. TCPmechod.c, por sua vez, implementa o algoritmo 5 descrito no texto acima mencionado. Observe que este servidor começa abrindo um soquete passivo para uma porta bem-conhecida, da mesma maneira que a linha de execução mestra de uma implementação concorrente. Ele usa a função de sistema gettablesize() para determinar o número máximo de descritores de soquetes (e arquivos) e então usa as macros FD_ZERO e FD_SET para criar um vetor de bits que corresponde aos descritores de soquetes que quer testar.  A seguir, ele entra em um ciclo infinito no qual chama select() para esperar que um ou mais dos descritores fiquem prontos. Como select() limpa todos os descritores que não estão prontos para leitura ou escrita quando retorna, a cada iteração o conjunto de descritores ativos é copiado para rfds. Se o descritor mestre ficar pronto, o servidor chama accept() para obter uma nova conexão. Ele adiciona o descritor da nova conexão ao conjunto de descritores que gerencia, e continua a esperar por mais atividade. Se um descritor escravo ficar pronto, o servidor chama a função echo() que chama read() para obter dados da conexão e write() para enviá-los de volta ao cliente. Se for informada uma condição de fim de arquivo em um dos descritores, o servidor fecha o descritor e usa a macro FD_CLR para removê-lo do conjunto de descritores usados por select().

 

  1. Explique sucintamente para que serve cada função pthread_* usada no servidor TCPmtechod. ( 1 ponto)
  2. Algumas funções de biblioteca não são thread safe. O que isso significa? um exemplo de função que se enquadra nessa categoria. É possível a várias linhas de execução (threads) de um mesmo processo usar esse tipo de funções? Como? (1  ponto)
  3. Apresente vantagens e desvantagens de construir servidores usando um único processo com várias linhas de execução (como, p.ex. TCPmtechod) com relação a usar vários processos, cada um com uma única linha de execução (como, p. ex., TCPechod). (1 ponto)
  4. O servidor TCPmechod implementa concorrência aparente usando uma única linha de execução. Em que circunstâncias essa abordagem é melhor que as duas apresentadas anteriormente (concorrência real com vários processos, cada um  com uma única linha de execução ou concorrência real um único processo com várias linhas de execução) ? (1 ponto)
  5. Um servidor que usa uma única linha de execução pode deixar de atender algum cliente enquanto repetidamente atende a outro cliente?  E servidores que usam vários processos com uma única linha de execução, ou um processo com várias linhas de execução? Justifique. (1 ponto)
  6. Monte experimentos que permitam comparar os 3 servidores concorrentes apresentados (TCPechod, TCPmtechod e TCPmechod) e determine (a) o número máximo de clientes que cada um é capaz de atender até recusar serviço, (b) qual executa mais rapidamente?  (b) Como  o tempo de execução varia em função do número de conexões concorrentes? (4 pontos)

 

Observações:    

  • Veja ao final da mensagem o novo formato para o relatório a ser enviado
  • Faça alguns testes para ilustrar o funcionamento dos clientes e servidores. Os testes devem incluir:
    • Cliente e servidor rodando no mesmo hospedeiro (localhost).
    • Cliente e servidor rodando em hospedeiros diferentes da mesma sub-rede (no sentido TCP/IP)
    • Cliente e servidor rodando em hospedeiros diferentes de sub-rede diferentes.

·        O trabalho poderá ser feito em grupos de até 3 componentes.

·        Tenha sempre à mão todo o código e relatórios entregues.

 

 

Forma de entrega

 

Enviar o relatório em um arquivo compactado (extensão .zip), anexado a uma mensagem, seguindo as instruções abaixo:

·        Destinatário: juan@puc-campinas.edu.br

·        Campo assunto (subject):

REDES-I/ATIVIDADE:<atividade>/Turma:<turma>/<RA do 1º. Autor>/<RA do 2º. Autor>/<RA do 3º. Autor>

Onde <atividade> será substituído pelo número da atividade, neste caso 4,  <turma> será a turma em que os membros do grupo estão matriculados, <RA 1º. Autor> será o RA do primeiro autor etc. Os RAs devem ser colocados em ordem crescente.  Observe que não há espaço após “ATIVIDADE:” e “Turma:”

·        Corpo da mensagem: nomes e RAs dos membros do grupo

·        Nome do arquivo compactado: ATIV5-<RA do 1º. Autor>.zip.

·        Conteúdo do arquivo compactado

·        Relatório com a seguinte estrutura (em formato MS-Word ):

·         Página de rosto: identificar a disciplina, a atividade e os nomes dos integrantes do grupo (incluindo endereço de email).

·         Corpo: respostas ou análises solicitadas, incluindo a citação das fontes usadas para elaborar a resposta

·         Referências: usando a notação ABNT

·        Anexo A: descrição do ambiente em que os testes e as coletas de dados foram feitas, incluindo local e o sistema operacional usado.

·        Anexo B: transcrição das sessões de testes em que o código foi testado e os dados coletados

·        Anexo C: Arquivos com o código fonte dos programas modificados ou desenvolvidos, incluindo o makefile. A primeira linha de cada arquivo deve ser um comentário com o nome do arquivo. A segunda e terceira linhas devem indicar os nomes e RAs dos autores, também na forma de comentários.