1. UNIVERSIDADE DO MINHO
Sistemas Distribuídos
Trabalho Prático (Fase 2)
Relatório Final
2010/2011
Relatório final do projecto. Está incluído o relatório completo e o código produzido para a
aplicação. Esta última entrega destina-se ao desenvolvimento da aplicação com Sockets e
arquitectura RMI.

2. Sistemas Distribuídos Entrega 2
Elementos da equipa de trabalho
N.º 53760–Manuel Gaspar Moura Martins
a53760@alunos.uminho.pt
N.º 53740–Samuel Armando Oliveira Ribeiro
a53740@alunos.uminho.pt
N.º 56631– Sérgio Miguel Cardoso Castro
a56631@alunos.uminho.pt
Relatório Final 2

3. Sistemas Distribuídos Entrega 2
Índice
Índice figura................................................................................................................................... 3
1. Introdução ............................................................................................................................. 4
1.1. Descrição do problema ................................................................................................. 4
1.2. Objectivos e resultados a atingir ................................................................................... 4
1.3. Ferramentas utilizadas .................................................................................................. 4
2. Esquema de Interface ........................................................................................................... 5
3. Percepção e Compreensão do Sistema ................................................................................. 6
3.1. Diagrama de Classes ...................................................................................................... 6
4. Descrição da aplicação .......................................................................................................... 7
4.1. Sistema de presença e troca de mensagens por Sockets ............................................. 7
4.2. Sistema de presença e troca de mensagens por Sockets e RMI ................................... 8
5. Funcionalidades da Aplicação Sockets e Java RMI .............................................................. 10
6. Questões de estudo ............................................................................................................ 11
5. Conclusão ............................................................................................................................ 12
Anexo .......................................................................................................................................... 13
Índice figura
Figura 1– Esquema de interface .................................................................................................... 5
Figura 2 - Interface da aplicação sockets ...................................................................................... 7
Figura 3 - Caixa que inicia a aplicação com introdução do nome ................................................. 7
Figura 4 - Caixa com resposta à introdução errada de nomes de utilizadores ............................. 8
Figura 5 - Interface da Aplicação Sockets e Java RMI ................................................................... 9
Figura 6 - Selecção do tipo de comunicação ................................................................................. 9
Figura 7 - Aprovação do tipo de comunicação em Java RMI ...................................................... 10
Relatório Final 3

4. Sistemas Distribuídos Entrega 2
1. Introdução
1.1. Descrição do problema
Após o estudo aprofundado do projecto efectuado na entrega 1A para compreensão e
percepção do sistema, é necessário por em prática. Desta forma, apresentamos o sistema de
presença e troca de mensagens, na entrega 1B, assim como, as respostas às questões de
estudo indicadas neste enunciado. Foram usados conceitos como IP, Sockets, TCP, UDP, peer-
to-peer (P2P) e concorrência sincronizada.
Nesta última fase o problema central é a adaptação da arquitectura RMI à aplicação já iniciada.
1.2. Objectivos e resultados a atingir
1. Funcionamento do sistema de presença e troca de mensagens com sockets e RMI
1.1. Troca de mensagens entre utilizadores assim como envio/recepção de poke com a
preferência entre arquitectura sockets e RMI
1.2. Implementação do interface RMI
1.3. Ferramentas utilizadas
Para o desenvolvimento do sistema com implementação em Java foi usada a ferramenta
NetBeans. Usamos também como ferramenta de colaboração para troca de ficheiros entre a
equipa de trabalho o Dropbox.
Relatório Final 4

5. Sistemas Distribuídos Entrega 2
2. Esquema de Interface
Esquema descritivo do relacionamento existente entre os vários tipos de IP e o servidor HTTP.
São indicadas as várias funcionalidades que o sistema terá de executar na interacção com o
utilizador.
Servidor
HTTP Obtém lista de IP activos
Adicionar IP ao servidor
Processo executado de
30 em 30 seg
Fazer POKE,
Enviado atraves de uma mensagem UDP
para a porta
2010 indicando o tipo de poke, se visual,
Sonoro ou ambos.
IP3(Servidor
IP1(Servidor/cliente) /cliente)
Fazer pedido “USER_INFO_REQUEST
nome, estado”,
Mensagem enviada através de uma
ligação
UDP para a porta 2010
CHAT entre o IP2 e IP3, deixando automaticamente
em estado OCUPADO
IP2(Servidor/cliente)
Resposta
“USER_INFO_REQUEST_REPLAY nome,
estado,”
Esta operação deve ser feita a cada IP
conhecido de 60 em 60 segundos
Figura 1– Esquema de interface
Relatório Final 5

6. Sistemas Distribuídos Entrega 2
3. Percepção e Compreensão do Sistema
3.1. Diagrama de Classes
Para o desenvolvimento de um sistema de presenças e troca de mensagens criou-se um
diagrama de classes composto com varias classes e um interface. Estas classes permitem gerir
os utilizadores, as mensagens e os POKEs, e a interface permite ao utilizador interagir com a
aplicação em modo socket ou Java RMI.
Foram criadas novas classes em relação à composição estrutural da aplicação da primeira
entrega, devido às necessidades do RMI.
A classe “Main” é a classe central de todo o modelo da aplicação, inclui os métodos Sockets e
Java RMI e interage com grande parte das classes do sistema.
No caso da classe “InterfaceGráfica” define a interacção entre todas as funcionalidades da
aplicação e o utilizador.
A classe “ListarUtilizadores” é responsável pela conexão com o servidor, actualizando a lista de
IPs, na interface.
Para cada utilizador existe uma classe “InformaçãoUtilizador” que guarda o seu IP, nome e
estado. Este objecto pode ser criado das seguintes formas, a primeira corresponde a quando
recebemos USER_INFO_REQUEST ou USER_INFO_REQUEST_REPLY, o outro meio ocorre
quando se adiciona um utilizador manualmente. A terceira ocasião sucede durante a listagem
dos utilizadores dos servidores em que adiciona-se o nosso próprio utilizador juntamente com
a lista atribuída.
O conjunto das restantes classes define todas as funcionalidades pedidas para a execução
deste projecto.
Figura 2 - Diagrama de Classes
Relatório Final 6

7. Sistemas Distribuídos Entrega 2
4. Descrição da aplicação
4.1. Sistema de presença e troca de mensagens por Sockets
A nossa aplicação dispõe de um interface de utilização composto pelas jlists “utilizadores
servidor” e “Utilizador Online”. Estão associados também botões “Iniciar conversa”, “Terminar
conversa”, “Adicionar utilizador”, “Poke Sonoro”, “Poke visual”, “Poke Sonoro e Visual” e
“Enviar”. No centro estão localizadas elementos principais da comunicação entre os
utilizadores, que são compostas por uma jtextarea onde é apresentada a troca de mensagens
e um jtextfield onde é introduzida a mensagem a ser enviada.
Figura 2 - Interface da aplicação sockets
Inicialmente aparece uma caixa de diálogo para introduzir o nome de utilizador, este será
associado à lista utilizadores online juntamente com o seu estado e IP. Posteriormente para
iniciar uma conversa é necessário seleccionar um utilizador com o estado activo e clicar no
botão iniciar conversa.
Figura 3 - Caixa que inicia a aplicação com introdução do nome
Relatório Final 7

8. Sistemas Distribuídos Entrega 2
Foi adicionado também um processo de detecção de erro na introdução do nome de utilizador
ao iniciar aplicação evitando assim possíveis comportamentos incorrectos.
Figura 4 - Caixa com resposta à introdução errada de nomes de utilizadores
4.2. Sistema de presença e troca de mensagens por Sockets e RMI
Neste sistema de presença e troca de mensagens cada utilizador do sistema poderá comunicar
por sockets e Java RMI em qualquer momento. As comunicações que se iniciam são feitas
usando a modalidade de comunicação escolhida pelo utilizador na interface da aplicação. Foi
disponibilizada uma interface SDLTSI para as comunicações feitas em Java RMI.
No chat, quando a comunicação escolhida é Java RMI, a sessão de chat é realizada invocando
os métodos starChat, sendMessage e endChat.
Todos os restantes componentes já pertencentes à aplicação iniciada anteriormente
continuam activos.
Na interface da aplicação temos a opção de seleccionar o modo de aplicação do lado direito ao
centro, o envio dos diferentes tipos de POKEs do lado direito em cima e o botão de enviar a
mensagem também do lado direito em baixo. Do lado esquerdo vemos a lista de utilizadores
denominada por “Utilizadores Online” e o seu estado, e podemos iniciar e encerrar uma
conversa. Ao centro encontramos a zona de conversa onde se pode visualizar e escrever as
mensagens.
Relatório Final 8

9. Sistemas Distribuídos Entrega 2
Figura 5 - Interface da Aplicação Sockets e Java RMI
A escolha do modo de comnunicação é feita num botão definido na interface. Ao seleccionar o
modo Sockets ou RMI, o botão bloqueia automáticamente não sendo possivel alterar o tipo de
comunicação durente a conversa.
Figura 6 - Selecção do tipo de comunicação
Relatório Final 9

10. Sistemas Distribuídos Entrega 2
Quando o modo de comunicação seleccionado é em Java RMI o utilizador convidado recebe
uma dialog box como demonstra a figura 7 com a opção de aceitar ou não a conversa.
Figura 7 - Aprovação do tipo de comunicação em Java RMI
5. Funcionalidades da Aplicação Sockets e Java RMI
A aplicação é composta pelas principais funcionalidades exigidas pelo projecto em modo
sockets e Java RMI.
Quando queremos comunicar com um utilizador é necessário que o mesmo esteja activo,
seleccionamos o utilizador, clicamos em “Iniciar Conversa”, o utilizador que foi convidado
necessita de aprovar o convite como, demonstra a figura 7, e após essa aprovação os dois
utilizadores em conversação ficam com o seu estado ocupado.
Para terminar a conversa, é só clicar no botão “Terminar Conversa” e os dois utilizadores ficam
novamente com o estado activo.
Existe ainda o estado parado, para o caso de um utilizador estar mais que 60 segundos sem ter
qualquer movimentação na aplicação.
Foi também definida uma forma de atribuir aos utilizadores que estão na lista “Utilizadores
Online” o estado Desligado mantendo o nome, quando estes não estejam localizados no
servidor com respectivo IP.
Independentemente de quem inicia a conversa é possibilitada a opção de terminar a sessão a
cada um dos utilizadores.
Relatório Final 10

11. Sistemas Distribuídos Entrega 2
6. Questões de estudo
1. Sockets TCP e UDP
O protocolo UDP (User Datagram Protocol) é habitualmente usado para fluxos de dados em
tempo real, em especial por aqueles que admitem perda ou alteração da informação contida
na mensagem, como por exemplo, transmissão de vídeos e voz. Este exemplo de protocolo é
usado pela nossa aplicação para obtenção da informação do utilizador e envio/recepção de
pokes. Quanto ao protocolo TCP (Transmission Control Protocol) é orientado a conexão, ou
seja, verifica se os dados são enviados, pela rede, entre dois pontos da forma correcta, na
sequência apropriada e sem erros. É usado para a transmissão de informação que
efectivamente tem de ser entregue no destinatário, ou seja é um protocolo de transmissão
confiável no que a transmissão de informação diz respeito. No nosso caso este protocolo é
utilizado para o preenchimento da lista utilizadores no servidor. É também utilizado para a
comunicação chat.
2. Operações idempotentes
Operações idempotentes são aquelas que podem ser realizadas enumeras vezes fornecendo o
mesmo resultado como tivessem sido executadas uma só vez. Por exemplo no nosso caso a
acção de obter a informação sobre o estado dos utilizadores presentes vai alterar a informação
na lista de utilizadores online, desta forma não de considerando como uma operação
idempotente. No decorrer da aplicação efectuam-se actualizações para o nome e ip do
utilizador usando o respectivo método get, neste referimo-nos a uma operação idempotente.
3. Necessidades que garantem a comunicação entre as aplicações de cada grupo
Para que as aplicações desenvolvidas pelos diferentes grupos funcionem é necessário que
todos os grupos partilhem o mesmo tipo de protocolo de comunicação no envio e na recepção
das mensagens e também a mesma representação de dados. O código para a aplicação
poderia ser desenvolvido em NetBeans ou BlueJ, ou outro IDE. Quanto à linguagem poderia ser
Orientada a Objectos Java, C# ou C++, não implicando a comunicação entre as aplicações.
4. Comportamento incorrecto ou bloqueio por parte das outras aplicações
Na nossa aplicação é accionado uma forma de detecção dos nomes de utilizadores inseridos
para não contenham valores nulos ou o carácter “;”.
Relatório Final 11

12. Sistemas Distribuídos Entrega 2
5. Conclusão
Para o desenvolvimento desta aplicação foram despendidas muitas horas de trabalho,
realçando o tempo que foi dedicado à construção do código. A percepção do relacionamento
entre as aplicações para a sua comunicação, designado por Chat, transpondo-o em código Java
foi também um ponto demoroso no desenrolar da construção da aplicação. Foram tiradas
ideias das fichas fornecidas pelos docentes para o desenvolvimento da aplicação assim como a
informação adquirida pelo professor. A pesquisa intensiva de código a usar para o
desenvolvimento da aplicação foi igualmente relevante para a concretização da aplicação.
Este projecto foi aliciante para o grupo de trabalho devido ao facto de se pôr realmente em
prática os conceitos usados durante as aulas não se ficando pela teoria em si.
Houve um grande esforço por parte de cada elemento do grupo para desenvolver o sistema de
presença e troca de mensagem devido ao desfasamento de horários e compromissos
profissionais de cada um, comprometendo, assim, o prazo de entrega do projecto. No entanto
a entrega foi concretizada dentro do prazo previsto.
Relatório Final 12

13. Anexo