Um sistema SMS 1 simplificado

Transcrição

1 1 Introdução Um sistema SMS 1 simplificado Projecto de Redes de Computadores I /2008 LEIC IST, Tagus Park 10 de Setembro de 2007 Pretende-se com este projecto que os alunos implementem um sistema SMS simplificado (cliente e servidor), que permita a cada utilizador enviar e receber mensagens de texto a partir de uma aplicação a correr num pc. O sistema SMS simplificado é um serviço de troca de mensagens de texto entre utilizadores do sistema. Uma mensagem de texto enviada por um utilizador com destino a outro utilizador, é recebida pelo Service Center que procede à sua entrega. O destinatário da mensagem de texto ao recebê-la, notifica essa ocorrência ao Service Center através de uma message delivery report,. De seguida, o Service Center envia ao utilizador que emitiu a mensagem de texto, um relatório sobre o estado da mesma, se este tinha activado a opção de message status report. Os utilizadores podem: enviar (receber) mensagens de texto para (de) outros utilizadores; receber relatórios de submissão de mensagens do Service Center para a notificação de recepção de mensagens de texto que nele transitam; receber relatórios de entrega de mensagens do Service Center; se a opção de message status report estiver activada; receber mensagens de difusão provenientes do Service Center. O Service Center é encarregado de: receber mensagens de texto dos utilizadores e de proceder à sua imediata entrega aos respectivos destinatários se estiverem activos, caso contrário, as mensagens são armazenadas em filas para posterior entrega, logo assim que os seus destinatários estiverem disponíveis para as receber; receber relatórios de entrega dos utilizadores destinatários e enviá-los aos respectivos emissores que tenham activado a opção de message status report. enviar relatórios de submissão de mensagens de texto aos respectivos emissores; enviar mensagens de difusão para todos os utilizadores activos; O trabalho consiste na especificação do protocolo de comunicação a utilizar e na implementação de um sistema funcional. Uma vez que cada grupo define o seu protocolo, não é de esperar que se possa comunicar utilizando clientes realizados por grupos diferentes. 1 Acrónimo de Short Message Service. As especificações completas do SMS podem ser consultadas na página do 3GPP [ 1

2 A aplicação será desenvolvida utilizando a linguagem C e o sistema operativo GNU/Linux. Serão utilizadas como referência as máquinas do laboratório da cadeira, sendo os trabalhos avaliados nestas máquinas. 2 Funcionalidades a implementar O protocolo de comunicação deve ser desenhado de modo a fornecer as funcionalidades pretendidas para o sistema da maneira mais simples. Ao ligar a aplicação, esta comunicará com um servidor, o Service Center, a fim de assinalar a sua presença na rede. Quando um utilizador termina a aplicação, o servidor é notificado da sua saída da rede. Na eventualidade da aplicação não terminar ordeiramente, isto é, não notificou apropriadamente o Service Center, este deverá detectar e interpretar correctamente a situação. O tamanho máximo das mensagens do SMS simplificado encaminhadas entre um cliente (ou utilizador) e o Service Center é de 140 caracteres. No acto de envio, se a dimensão duma mensagem superar o máximo consentido, a mesma deve ser fragmentada em várias mensagens de tamanho adequado. A aplicação do cliente ao receber um conjunto de mensagens que constituem fragmentos, deve reconstruir correctamente a mensagem original. O protocolo e a aplicação devem ser desenvolvidos tendo em conta as seguintes restrições: A rede utilizada não é fiável. Sempre que o utilizador tiver de identificar o servidor com funções de Service Center poderá fazê-lo utilizando o endereço IP ou o nome DNS da máquina. O protocolo deve ser eficiente, evitando a troca de mensagens/informações desnecessárias. 3 Interface com o utilizador A aplicação a desenvolver deverá apresentar uma interface linha de texto comando. O número de argumentos da aplicação e a sua ordem é deixado ao cuidado de cada grupo, devendo estes ser no menor número possível de forma a cumprir os objectivos propostos. Ao ser chamada sem argumentos, a aplicação deve dar uma breve ajuda, indicando quais os argumentos que aceita, e sair. Ao arrancar com sucesso, a aplicação apresenta a linha de comando ao utilizador, na qual este pode inserir quatro comandos: criar_mensagem, caixa_entrada, itens_enviados, pedido_relatório e sair. A execução de cada comando deve resultar numa mensagem que esclareça o utilizador quanto ao sucesso, ou não, do comando emitido. Após a apresentação das mensagens de cada comando, o utilizador passa a poder introduzir o próximo comando. O comando criar_mensagem permite ao utilizador compor uma mensagem de texto. O comando caixa_entrada permite a visualização da lista das mensagens recebidas. 2

3 O comando itens_enviados mostra a lista das mensagens enviadas. O comando pedido_relatório permite a activação/desactivação da opção message status report para a recepção dum relatório que confirma entrega das mensagens de texto aos respectivos destinatários. O comando sair termina a aplicação ordeiramente. 4 Modelo de rede O projecto deve ser implementado considerando a existência de um servidor que implementa o Service Center ao qual todos os clientes se ligam para efectuarem trocas de mensagens de texto. 5 Recomendações O protocolo de comunicações é o ponto de partida para o desenvolvimento da aplicação. Esta não poderá fornecer serviços não suportados pelo protocolo e será tão complexa quanto for o protocolo que implementa. O procedimento recomendado é o de desenhar primeiro o protocolo de comunicação completo, formalizando a máquina de estados e o formato dos PDUs. A aplicação deverá poder ser compilada de forma a funcionar conforme descrito ou emitindo mensagens de debug que permitam acompanhar o seu funcionamento. As mensagens de debug, claras, em Português correcto (passível de ser analisado por terceiros), e em quantidades razoáveis, podem ser muito valiosas durante as apresentações e discussão. Após definir o protocolo que permitirá fornecer as funcionalidades pedidas, deverá começar por desenhar a arquitectura da aplicação, tendo em conta todas as operações que esta deverá desempenhar. O programa deve ser implementado através de um conjunto de módulos independentes, de funcionalidade bem definida, devendo-se evitar as variáveis globais sempre que possível. Também as estruturas de dados utilizadas e os mecanismos de sincronização escolhidos devem ser alvo de reflexão. Recomenda-se a interacção como corpo docente em todas as etapas do desenvolvimento, como forma de garantir que o trabalho desenvolvido corresponde ao que foi pedido. Recomenda-se a utilização de uma Makefile desde o início. Não só é facilitado o processo de desenvolvimento como é necessário entregar uma juntamente com o projecto. O programa ethereal pode ser de grande utilidade na análise das mensagens trocadas entre as várias entidades envolvidas, sendo uma valiosa ferramenta de debug. Para se ligar ao sistema SMS simplificado um cliente necessita de conhecer o servidor. Esta informação pode ser fornecida pelo utilizador ao lançar a aplicação. O teste da aplicação vai requerer a utilização simultânea de vários clientes. Como o número de máquinas disponíveis é reduzido, face ao número de grupos, deverá ser possível correr vários clientes na mesma máquina. Deve no entanto ser possível correr a aplicação em máquinas diferentes. 6 Calendarização De forma a possibilitar um maior acompanhamento do trabalho realizado pelos alunos, algumas das aulas práticas serão dedicadas à ao no projecto. 3

4 Calendarização aconselhada para o desenvolvimento do projecto: Período Etapa de desenvolvimento 24 a 28 de Setembro Identificação dos requisitos funcionais inerentes à gestão dos utilizadores e ao serviço de mensagens) 8 a 12 de Outubro Concepção da arquitectura do software dos componentes cliente e servidor 22 a 26 de Outubro Máquina de estados da gestão de utilizadores 29 de Outubro a 2 de Novembro Máquina de estados do serviço de mensagens Máquina de estado global 5 a 9 de Novembro Implementação da gestão de utilizadores 10 a 23 de Novembro Implementação do serviço de mensagens 3 a 7 de Dezembro Integração das implementações 10 a 14 de Dezembro Entrega do Projecto (código + relatório)-> Obrigatório! As datas para a realização das visualizações e discussões (que englobam toda a componente laboratorial) serão oportunamente comunicadas aos alunos na página da cadeira. Da aplicação será considerada a qualidade e legibilidade do código. A repetição desnecessária de código será registada de forma negativa. O código deverá ser acompanhado de uma Makefile que gere, por omissão, um executável de nome sms. Só serão avaliados projectos acompanhados por uma Makefile correcta. O método de entrega do código e relatório será oportunamente divulgado na página da cadeira. 6.1 Relatório Na entrega final, juntamente com os ficheiros do projecto, deverá ser fornecido um relatório sucinto, com um máximo de 8 páginas em tamanho 12, com a seguinte estrutura: Introdução - Objectivo do trabalho e estrutura do relatório. Protocolo desenvolvido - Especificação final do protocolo mencionando eventuais alterações feitas face à primeira versão. Protocolos de comunicação desenvolvidos (incluindo PDUs) e considerações relevantes: limitações existentes, escalabilidade, desempenho. Arquitectura da solução - O que foi realizado e o que ficou por fazer face ao enunciado. Diagrama de blocos. Implementação - Estruturas de dados e opções de implementação. Estrutura do código e ficheiros entregues. Testes - Descrição do plano de testes realizados para comprovar o correcto funcionamento da aplicação. Conclusões O relatório deve ser entregue em formato PDF. Não são aceites relatórios noutros formatos ou que não satisfaçam as regras de formatação. Na componente de avaliação do relatório será considerado, com igual peso: o conteúdo técnico a estrutura do relatório 4

5 a qualidade da escrita. 7 Referências [1] The Ethereal Network Analyzer - Sniffing the glue that holds the Internet together, [2] GNU C library manual, 5