O objetivo deste projeto lista é desenvolver um pequeno sistema

Sistemas Distribuídos / Tópicos Especiais
Prof. Alexandre Sztajnberg
2011/2
Projeto – Programação usando sockets e middleware para objetos distribuídos (RMI,
CORBA, RPC, etc.)
O objetivo deste projeto lista é desenvolver um pequeno sistema distribuído de servidores
utilizando sockets e algum suporte de middleware (RPC, RMI ou CORBA).
O projeto será composto de algumas etapas, que serão avaliadas separadamente e também
em conjunto.
O sistema/programa a ser implementado pode ser desenvolvido em C, C++ ou Java e deve
executar no Linux, mais especificamente nos nossos servidores clone e snarf.
Os fontes, executáveis e o texto devem ser disponibilizados na conta da snarf através de
uma página Web simples, mas organizada, que você já criou (ou seja, a atividade de criar a
página já foi avaliada. Só verificaremos que o material solicitado foi colocado lá).
O sistema será composto de:





um servidor concorrente principal (front-end) que receberá requisições via socket e
encaminhará as mesmas, via RMI/RPC/CORBA para servidores escravos
servidores escravos que se registrarão no servidor principal e serão encarregados de
realizar as operações
servidores especializados que receberão requisições específicas, delegadas pelos
servidores escravos
clientes que farão requisições para o front-end
cliente para avaliação de desempenho
Cada um destes elementos deve ser desenvolvido, implementado e testado. Observe que os
módulos podem ser implantados em máquinas distribuídas. Portanto, NÃO deixe
referências hardcoded na versão final.
O sistema vai oferecer um serviço de calculadora, “concorrente”. Você vai ter que pensar
nas várias interfaces, formatos de mensagens, tratamento de erros e exceções.
Um arquivo de texto, tipo README deve descrever as decisões de projeto, entre ela as
relacionadas a endereçamento, registro, portas, obtenção destas informações, etc.
A Figura 1 ilustra o sistema geral.
rmiregistry / ns
portmap
Front-end
Tratador
Clientes
+, -, /, *
Principal
*
Tratador
Desempenho
Tratador
/
+, -, /, *
Especializado
Worker
Figura 1 – arquitetura do sistema
Características:
1. Servidor concorrente principal
O servidor principal (front-end) que receberá requisições via socket TCP e encaminhará as
mesmas, via RMI/RPC/CORBA para servidores escravos. O servidor deve ter arquitetura
concorrente.
Antes de delegar o tratamento para o tratador, a linha principal deve decidir qual worker
será utilizado pelo mesmo, num esquema round-robin (circular). Não limite o número de
tratadores, nem o número de workers que poderão ser usados.
O servidor deverá medir o tempo de realização de cada requisição. Para isso, deve manter o
rastro das requisições e monitorar o retorno dado pelo tratador. Isso pode trazer um pouco
de complexidade na implementação, se você não sabe usar variáveis globais, estáticas ou
memória compartilhada. Depende de você fazer esta medição na linha principal ou no
tratador. Mas, de alguma forma o servidor deve ter a informação de quanto tempo leva cada
requisição e fazer um média aritmética, jogando na tela o valor atual do tempo de resposta
médio (o tempo de tratamento de requisição médio).
Observe que os tratadores são clientes dos servidores RMI. De alguma forma, o rodízio tem
que estar associado à um forma de referenciar à réplica de servidor RMI que vai ser usada
(veja a Figura 1).
2. servidores escravos e especializados
Nesteservidor vamos desenvolver um pequeno serviço de operações aritméticas utilizando
um middleware de objetos distribuídos. Pode usar RMI, RPC ou CORBA. O servidor
oferece 4 operações. Só que duas delas (* e /) são “delegadas” a servidores especializados
2
Desenvolva os servidores. Obviamente você deve começar pela interface. Observe também
o tratamento de exceções no caso de falhas e no caso de operações cujos parâmetros estão
errados (divisão por zero, por exemplo). A geração das exceções deve estar no servidor que
faz as operações e não no que pede!
3. Clientes
O cliente deve se conectar ao front-end e fazer umas das operações oferecidas.
4. Cliente para avaliação de desempenho
Este é mais complicadinho.
Queremos avaliar a escalabilidade do sistema. Para isso, vamos desenvolver um cliente
especializado, que vai fazer apenas uma operação, de forma automática. Este cliente vai
disparar uma série de requisições para o servidor, estabelecendo a conexão, fazendo a
requisição e desfazendo a conexão (como faria um servidor Web).
A taxa de requisições deve ser controlada, de forma que X requisições sejam feitas durante
um intervalo de tempo, depois 2 * X requisições, durante o mesmo intervalo, e assim por
diante, até um limite “teórico do servidor”. Enquanto isso, o servidor estará exibindo a
média aritmética do tempo de resposta.
Taxa (requisições/minuto)
A idéia é fazer uma rampa de requisições, como a da Figura 2, porém limitando o teste a 5
minutos. Voce vai ter que pensar como controlar a taxa de requisições, cadenciando as
mesmas durante um intervalo de 10 segundos, aumentando a taxa nos próximos 10, etc.
Sugerimos o uso de temporizadores.
120
110
100
90
80
70
60
50
40
30
20
10
5
10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100 105 110 115
Tempo (minutos)
E o tempo para fazer isso tudo?
Você tem um mês para fazer esse trabalho. Basicamente é um trabalho de integração, já
que você tem os exemplos.
Numa próxima versão do enunciado podemos destacar os itens a serem avaliados.
Obviamente, o funcionamento correto e o atendimento aos requisitos é fundamental.
3