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ª)
Objetivo:
Obter
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().
- Explique
sucintamente para que
serve cada função pthread_* usada no servidor
TCPmtechod. ( 1 ponto)
- Algumas
funções de biblioteca
não são thread
safe. O que isso
significa? Dê 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)
- 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)
- 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)
- 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)
- 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.