Sistemas distribuidos

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.

Sistemas Distribuídos Entrega 2

Relatório Final

2

Elementos da equipa de trabalho

N.º 53760–Manuel Gaspar Moura Martins

[email protected]

N.º 53740–Samuel Armando Oliveira Ribeiro

[email protected]

N.º 56631– Sérgio Miguel Cardoso Castro

[email protected]


Relatório Final

3

Í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

4

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

5

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.

IP1(Servidor/cliente)IP1(Servidor/cliente)

IP2(Servidor/cliente)IP2(Servidor/cliente)

Servidor

HTTP Obtém lista de IP activos

Resposta

“USER_INFO_REQUEST_REPLAY nome,

estado,”

Esta operação deve ser feita a cada IP

conhecido de 60 em 60 segundos

Fazer pedido “USER_INFO_REQUEST

nome, estado”,

Mensagem enviada através de uma

ligação

UDP para a porta 2010

Fazer POKE,

Enviado atraves de uma mensagem UDP

para a porta

2010 indicando o tipo de poke, se visual,

Sonoro ou ambos.

CHAT entre o IP2 e IP3, deixando automaticamente

em estado OCUPADO

IP3(Servidor

/cliente)

Adicionar IP ao servidor

Processo executado de

30 em 30 seg

Figura 1– Esquema de interface


Relatório Final

6

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

7

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

8

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

9

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

10

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

11

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

12

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.

Sistemas distribuidos

Documents

Transcript of Sistemas distribuidos