Sistemas

Operativos 2014/2015

Trabalho Prtico

Servidor HTTP


1. Objetivos do trabalho

Desenvolver um servidor web na linguagem de programao C com suporte
de multi-threading, acesso a informao esttica e dinmica, gesto de
configuraes e de estatsticas.

Explorar os mecanismos de gesto de processos, comunicao e
sincronizao entre processos no sistema operativo Linux.


2. Viso geral do funcionamento do servidor

A Figura 1 apresenta uma viso geral do funcionamento do servidor a
desenvolver.

Thread #1
HTTP Request

Thread #2
Receiver

HTML Pages

...

Scheduler
Requests
buffer

Child
process

Thread #N

Script

Shared
memory

Message
queue

Configuration
manager

Statistics
manager

Configuration

Statistics

Figura 1 - Viso geral do funcionamento do Servidor

O servidor HTTP a implementar utiliza trs processos, tal como a Figura 1

ilustra. Estes processos so responsveis pelas seguintes funcionalidades:

O processo principal (do ponto de vista das funcionalidades asseguradas)
responsvel pela aceitao de novas ligaes HTTP e pelo escalonamento de
threads ou processos filho para tratamento dos pedidos de acesso a pginas
ou execuo de scripts.

O processo de gesto de configuraes responsvel pela leitura dos
parmetros de configurao do servidor a partir de um ficheiro de
configurao. A informao de configurao determina aspetos de
funcionamento do servidor e ficar acessvel ao processo principal.

O processo de gesto de estatsticas recebe do processo principal informao
estatstica acerca do funcionamento do servidor, em particular sobre as
pginas acedidas ou scripts executados, e atualiza um ficheiro de logs
(registos) com essa informao.

As funcionalidades a implementar encontram-se descritas em maior detalhe nas
seces seguintes deste Enunciado.


3. Funcionalidades a implementar


3.1. Recepo de pedidos

Tal como a Figura 1 ilustra, o processo principal responsvel por receber as
ligaes HTTP e escalonar o tratamento dos pedidos efetuados pelos clientes
(por exemplo browsers). Este processo suporta acessos HTTP dos seguintes
tipos:

Acessos a contedo esttico (pginas HTML armazenadas em ficheiros), que
so assegurados por threads.

Acessos a contedos dinmicos (resultado de execuo de shell scripts), que
so assegurados por processos filho do processo principal.

Aps a recepo de uma nova ligao HTTP, o processo principal assegura as
seguintes funcionalidades:

1. Interpretar o pedido efetuado pelo cliente (browser), para perceber se o
acesso a contedo esttico ou dinmico.

2. Colocar o pedido no buffer de pedidos, onde ir ser identificado pelo tipo de
pedido, pelo ficheiro pretendido e pelo socket de comunicao com o cliente.

3. Um pedido de acesso a contedo esttico (pgina HTML num ficheiro em

disco) ir ser servido por uma das threads disponveis, que tratar de ler o
contedo do respetivo ficheiro e envi-lo na forma de uma resposta HTTP ao
cliente (browser) atravs do respetivo socket.

4. Um pedido de acesso a contedo dinmico (resultado da execuo de um
shell script) dever ser tratado por um processo filho do processo principal
(criado pela thread responsvel pelo pedido). Este processo dever enviar o
resultado da execuo do script na forma de uma resposta HTTP ao cliente
(browser) atravs do respetivo socket.


3.2. Tratamento de pedidos

Tal como descrito anteriormente, os pedidos HTTP so servidos por threads. O
processo principal dever criar no arranque uma thread responsvel pelo
escalonamento, bem como uma pool de threads para servir pedidos. A thread de
escalonamento (identificada por Scheduler na Figura 1) ficar responsvel por
escalonar o atendimento dos pedidos utilizando as threads disponveis na pool. O
nmero de threads a criar (a dimenso dessa pool) definido na configurao do
servidor, sendo que o buffer de pedidos dever ter capacidade para armazenar o
dobro desse nmero. Caso num determinado instante no haja capacidade para
armazenar no buffer um novo pedido o servidor dever devolver ao cliente HTTP
uma mensagem de erro apropriada.

Considera-se que a thread de escalonamento responsvel por validar o pedido,
ou seja, verificar se o ficheiro em causa existe e, no caso de se tratar de um script,
se a execuo do mesmo est autorizada na configurao do servidor. O
tratamento de um novo pedido por uma thread (a pedido da thread de
escalonamento) dever ser efetuado da seguinte forma.

Caso se trate de um acesso a contedo esttico (pgina HTML) a thread
dever abrir o ficheiro em causa, ler o seu contedo e devolv-lo ao cliente
(browser) na forma de uma resposta HTTP.

Caso se trate de um acesso a contedo dinmico a thread dever criar um
processo filho para execuo do script, receber o resultado atravs de um
pipe (criado para o processo filho em particular) e devolv-lo ao cliente na
forma de uma resposta HTTP. Os scripts passiveis de serem executados so
definidos na configurao do servidor.

A thread de escalonamento dever decidir qual o prximo pedido a atender de
acordo com diferentes polticas de escalonamento, definidas na configurao do
servidor:

Escalonamento FIFO (First in First out), em que o prximo pedido a atender
ser o mais antigo no buffer de pedidos.

Escalonamento com prioridade a contedo esttico, em que o prximo

pedido a atender ser o pedido de contedo esttico mais antigo no buffer
(independentemente da existncia de pedidos para contedo dinmico).
Escalonamento com prioridade a contedo dinmico, em que o prximo
pedido a atender ser o pedido de contedo dinmico mais antigo no buffer
(independentemente da existncia de pedidos para contedo esttico).

3.3. Estatsticas de funcionamento

Pretende-se armazenar, em ficheiro, estatsticas relativas ao funcionamento do
servidor. Tal como a Figura 1 ilustra, o processo de gesto das estatsticas
responsvel por receber a informao sobre os pedidos aceites e processados
pelo servidor atravs de uma fila de mensagens. Cada mensagem conter
informao sobre um pedido HTTP tratado pelo servidor, informao esta que
dever ser escrita no ficheiro de logs na forma de uma linha nica.

Para cada acesso HTTP (a contedo esttico ou dinmico) o processo de gesto
das estatsticas dever armazenar no ficheiro de logs (numa nica linha) a
seguinte informao:

Tipo de pedido (esttico ou dinmico)
Ficheiro HTML lido ou o script executado
Nmero da thread na pool responsvel por atender o pedido
Hora de recepo do pedido pela thread e hora de finalizao (aps ter enviado o
resultado ao cliente)

Para alm das estatsticas anteriores, o processo de gesto das estatsticas
dever ser capaz de enviar para a consola, aps receber um sinal do tipo SIGHUP,
a seguinte informao:

Hora de arranque do servidor e hora atual
Nmero total de acessos a contedo esttico atendidos
Nmero total de acessos a contedo dinmico atendidos
Nmero total de pedidos recusados


3.4. Parmetros de configurao

Pretende-se dispor de uma forma de definir alguns parmetros de configurao
do servidor num ficheiro. Tal como a Figura 1 ilustra, o processo de gesto das
configuraes responsvel pela leitura das configuraes definidos num
ficheiro e pelo seu armazenamento numa zona de memria partilhada. O
processo principal (bem como as vrias threads) podero consultar a informao
de configurao sempre que necessrio atravs dessa zona de memria
partilhada.

4

A configurao lida a partir do ficheiro de configurao para a memria

partilhada durante o arranque do Servidor, ou em alternativa aps a recepo,
por parte do processo de gesto das configuraes, de um sinal do tipo SIGHUP.
Esta funcionalidade permitir alterar a configurao do Servidor com o mesmo
em funcionamento. O ficheiro de configurao dever permitir definir os
seguintes parmetros de configurao do Servidor:

Porto para o servidor
Nmero de threads da pool
Poltica de escalonamento de threads
Lista de shell scripts autorizados, definidos pelo nome do ficheiro


3.5. Arranque e terminao do Servidor

No seu arranque o servidor dever criar os trs processos (principal, gesto de
estatsticas e gesto de configuraes), bem como as threads e os vrios recursos
de comunicao e sincronizao considerados necessrios.

O Servidor dever estar igualmente preparado para terminar, aps a recepo,
por parte do processo principal, de um sinal do tipo SIGINT. Nessa altura todos
os processos devem ser terminados e dever fazer-se a limpeza no sistema de
todos os recursos partilhados.


4. Utilizao do protocolo HTTP e cdigo de exemplo fornecido

Pretende-se que o servidor a implementar assegure apenas algumas
funcionalidades essenciais previstas no protocolo HTTP (HyperText Transfer
Protocol). A programao das funcionalidades necessrias est ilustrada no
cdigo de exemplo fornecido com o Enunciado, em particular:

Ativao de sockets para aceitao de ligaes e comunicao com clientes.

Parsing simples das mensagens HTTP para deteco do tipo de pedido.

Devoluo de cdigos HTTP ao cliente em caso de erro, nomeadamente
relativos inexistncia de ficheiros HTML ou impossibilidade de execuo de
scripts.

Para assegurar o acesso a contedos atravs de uma ligao HTTP necessrio
comear por interpretar o cabealho do pedido recebido pelo Servidor, em
particular o comando GET. Iremos considerar que este comando utilizado
para ambos os tipos de acesso. A Figura 2 ilustra as comunicaes entre um
cliente (browser) e o servidor HTTP para acesso a uma pgina HTML (contedo
esttico). Tal como visvel na figura, a resposta enviado pelo Servidor ao cliente
comea por conter um cabealho HTTP antes do cdigo HTML da pgina pedida.

HTTP Request (static content)

Client

GET /index.html HTTP/1.1

Host: 127.0.0.1:5000
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive

Server

HTTP Reply (static content)

HTTP/1.0 200 OK
Server: simpleserver/0.1.0
Content-Type: text/html

Client

Server

<HTML>
...
</HTML>

Figura 2 - Acesso a contedo esttico atravs de HTTP

A Figura 3 ilustra as mesmas comunicaes para execuo remota de um script
(acesso a contedo dinmico).

HTTP Request (dynamic content)

Client

GET /cgi-bin/testscript.sh HTTP/1.1

Host: 127.0.0.1:5001
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive

Server

HTTP Reply (dynamic content)

HTTP/1.0 500 Internal Server Error
Server: simpleserver/0.1.0
Content-type: text/html

Client

<HTML>
...
</HTML>

Figura 3 - Acesso a contedo dinmico atravs de HTTP

Server

No exemplo anterior, estamos a considerar que a execuo do script pedida
utilizando igualmente o comando GET do HTTP, tal como previsto na
especificao CGI (Common Gateway Interface), sem lugar passagem de
parmetros. Neste caso consideramos igualmente que o script no se encontra
autorizado para execuo no servidor.
6

5. Checklist

Processo

Servidor

Tarefa
Utilizar o fork() para criar processos filhos

5%

Criar pipes unnamed/named

2%

Ler informao do(s) pipe corretamente

10%

Lanar shell scripts

5%

Criar, inicializar e gerir a pool de threads

10%

Colocar e retirar pedidos do buffer corretamente com recurso a

semforos, mutexes ou variveis de condio para
sincronizao

15%

Fornecer respostas corretas aos pedidos HTTP

2%

Aplicar as configuraes

5%

Prevenir interrupes indesejada por sinais e fornecer a

resposta adequada ao SIGINT

2%

Criar e mapear a regio de memria partilhada

2%

Ler a configurao a partir da memria partilhada

5%

Criar e inicializar a fila de mensagens

2%

Escrever estatsticas corretamente para a fila de mensagens

5%

Ler ficheiro de configurao

5%

Configurao Escrever informao em memria partilhada

Prevenir interrupes indesejada por sinais e fornecer a
resposta adequada ao SIGHUP

Estatsticas

Geral

Quantidade
de trabalho

5%
2%

Ler dados da fila de mensagens

5%

Criar o ficheiro para guardar as estatsticas

2%

Escrever no ficheiro

5%

Prevenir interrupes indesejada por sinais e fornecer a

resposta adequada ao SIGHUP

2%

Deteco e tratamento de erros.

Terminao dos processos filhos quando o processo Servidor
termina. Libertao de recursos e limpeza ao terminar a
aplicao.

2%
2%

Notas importantes

No ser tolerado plgio ou qualquer outro tipo de fraude. Tentativas
neste sentido resultaro na classificao de ZERO VALORES e na
consequente reprovao na cadeira.
Em vez de comear a programar de imediato pense com tempo no problema
e estruture devidamente a sua soluo.
Inclua na sua soluo o cdigo necessrio deteco e correo de erros.
Evite esperas ativas no cdigo e assegure a terminao limpa do servidor, ou
seja com todos os recursos utilizados a serem removidos.
Utilize um makefile para simplificar o processo de compilao.
Inclua informao de debug que facilite o acompanhamento da execuo do
programa, utilizando por exemplo a seguinte abordagem:


#define DEBUG //remove this line to remove debug messages
(...)
#ifdef DEBUG
printf(Creating shared memory\n);
#endif

6. Metas, entregas e datas

Data
Meta
Semana de Demonstrao
24/11/2014 intermdia
12/12/2014 Entrega final

Semana de Defesa
15/12/2014

Os alunos devero apresentar o seu trabalho nas aulas PL,
preparando uma demostrao do trabalho efetuado at ao
momento, que dever representar aproximadamente 25% do
trabalho global necessrio para terminar o projeto.
O projeto final dever ser submetido no InforEstudante, tendo
em conta o seguinte:
Os nomes e nmeros dos alunos do grupo devem ser
colocados no incio dos ficheiros com o cdigo fonte.
Inclua neste local tambm informao sobre o tempo total
despendido (pelo dois elementos do grupo) no projeto.
Com o cdigo deve ser entregue um relatrio sucinto (no
mximo 2 pginas A4) que explique as opes tomadas na
construo da soluo.
Crie um arquivo no formato ZIP com todos os ficheiros do
trabalho.
Defesas funcionais em grupo nas aulas PL desta semana. As
defesas individuais escritas ocorrero no dia 17/12/2014.