GERENCIADOR DE CORREIO ELETRÔNICO (V. 2 26/04/2010)

Transcrição

1 GERENCIADOR DE CORREIO ELETRÔNICO (V. 2 26/04/2010) OBJETIVO GERAL Este trabalho possui o objetivo de exercitar a lógica de programação dos alunos do Terceiro ano do Curso de BSI e também desenvolver aplicações utilizando o paradigma Cliente/Servidor. OBJETIVO ESPECÍFICO. A aplicação a ser desenvolvida será um gerenciador de Correio Eletrônico. Deverá ser desenvolvida em ambiente Linux, Linguagem C e Sockets. O armazenamento de informação deverá ser implementado em BDB (Berkeley DataBase) A aplicação será dividida em duas partes: Cliente e Servidor DESCRIÇÃO DE UMA CONTA DE e mail Uma conta de e mail possui a seguinte estruturação: identificação_abreviada@dominio <identificação por extenso> Exemplo: airton@dominio_a <Airton Kuada> Toda mensagem enviada para qualquer destino deverá possuir a identificação abreviada do emissor e também a identificação por extenso. DESCRIÇÃO DO CLIENTE O cliente é parte do programa que será utilizado pelo usuário final. Ele deve ser amigável o suficiente para facilitar a interação entre o usuário final e a máquina. Através do cliente, o usuário final irá gerenciar a sua caixa postal e o administrador irá cadastrar os usuários. Requisitos do Cliente: Solicitar autenticação para o usuário (identificação abreviada) Mostrar as mensagens que foram recebidas Mostrar as mensagens que foram enviadas Escrever nova mensagem Remover mensagens Ler mensagens recebidas Quando o usuário for admin será mostrado a tela de gerenciamento de contas de Tela de autenticação

2 Gerenciador de Correio Eletrônico User: Senha: > Senha Errada / Usuário não existe Menu Inicial E Ler Caixa de Entrada S Ler Caixa de Saida D Deletar mensagens L Ler Mensagem F Fim de Sessão ==> Entrada Número! Data! De! Assunto! Status 1 12/12/2010 Marina Silva Cuidados com Meio Ambiente Nova 2 12/12/2010 Chico Xavier Cuidados com a Alma Lida 3 12/12/2010 Fenomeno Cuidados com a Gordura Lida 4 12/12/2010 Maradona Tecnicas de gol Nova 5 12/12/2010 Pelé Filhos mal Criados Nova Opção: E Ler Caixa de Entrada S Ler Caixa de Saida D Deletar mensagens L Ler Mensagem F Fim de Sessão ==> Saida Número! Data! Para! Assunto! Status 1 12/12/2010 Carlos@dominio_A Pescaria Não Enviado 2 12/12/2010 Xuxa@dominio_B Festa das crianças Enviado 3 12/12/2010 FHC@dominio_C Palestra Lido em xx/xx/xx 4 12/12/2010 Pelé@dominio_B Futebol arte Removido em xx/xx/xx Opção: Se o usuário teclar uma letra deverá chamar uma função correspondente a ação a ser executado, como por exemplo D irá chamar a função para apagar mensagens. Se for escolhido um número, então deverá ser mostrado o conteúdo correspondente a mensagem selecionado conforme a tela

3 abaixo: ==> Mensagem Recebida De: <Carlos Alberto Parreira> Assunto: Pescaria Corpo da Mensagem: Olá Airton, Vamos pescar no dia 1/5 em Mato Grosso? Abraços Carlos Aberto Parreira ==> Mensagem Enviada Para: Assunto: Pescaria Corpo da Mensagem: Olá Parreira. Confirmo a data da pescaria para o dia dia 7/5. Abraços Airton Kuada Tela do usuário admin

4 Manutenção do Cadastro de Usuário 1. Criar Conta 2. Remover Conta 3. Alterar Senha 4. Consultar Senha 5. Fim DESCRIÇÃO DO SERVIDOR O Servidor é parte do programa que fará o gerenciamento dos usuários e mensagens recebidas. Requisitos do Servidor: Geração de Log de sessão de Cliente, isto é, para cada usuário que se conecta com o Servidor um arquivo de log dever ser criado, Geração de Logs de Sessão entre Servidores, isto é, para conexão de um servidor que está enviado um mensagem, um arquivo de log deverá ser criado Autenticação de conexões de usuários em Banco de Dados BDB Autenticação de conexões de servidor em Banco de Dados BDB Controle do número de conexões de usuário Criação de uma Thread para cada Sessão de usuário que é iniciada, não deve ser utilizado a função fork para a criação de subprocessos Criação de uma Thread para cada Sessão de Servidor que é iniciada, não deve ser utilizado a função fork para a criação de subprocessos Não existe nenhuma interação com usuário na console, isto é, rodará em modo background. O usuário admin deverá ser criado no momento da criação da base de dados O acesso a base de dados será realizado exclusivamente pelo servidor com interação através do cliente CONCEITO DE PEER Um Peer é qualquer vizinho que envie e receba e mail. Cada Peer é responsável por um dominio. No exemplo abaixo temos três Peer que se relacionam. Cada dominio possui o seus usuários cadastrados em uma base de dados independente. Uma mesma identificação de usuário pode pertencer a diferentes dominios. Quando uma mensagem for entregue para um Peer, antes deverá ocorrer a autenticação de quem está entregando a mensagem. Uma mensagem só deve ser aceita de um Peer conhecido e autenticado. A conexão com um Peer é realizada no momento da transferência da mensagem, e desfeita ao final.

5 CONTROLE DE STATUS DAS MENSAGENS. Todas mensagens que são enviadas e recebidas possuem um controle de estados que são utilizados pelo usuário emissor/receptor para acompanhar o seu estado. Por exemplo, o usuário carlos@domino_a enviou uma mensagem para o mario@dominio_b, o sistema de correio eletrônico enviou até o seu destino, porém o usuário de destino ainda não leu a correspondencia; neste caso, na caixa posta de entrada do usuário mario@dominio_b apareceria uma mensagem no estado novo, e na caixa postal de saída do usuário carlos@dominio_a a mensagem apareceria no estado enviada. Quando a mensagem fosse lida pelo destinatário, em sua caixa postal de entrada o estado seria Lido enquanto para o emissor também seria Lida. Quando a mensagem fosse apagada no destino, a mensagem não mais aparece na caixa postal do destinatário, porém para o emissor a mensagem na caixa postal de saída, constaria o estado removido. STATUS DE MENSAGENS RECEBIDAS Nova Lida Removida (não aparece mais na tela) STATUS DE MENSAGENS ENVIADAS enviada/não enviada Lida Removida Quando uma mensagem não é enviada as seguintes situações podem ocorrer domínio desconhecido (não existe peer) servidor de destino não está disponível (possívelmente desligado)

6 destinatário não existe (Peer existe, mas usuário não) Falha de autenticação no Peer ARQUIVOS DE CONFIGURAÇÃO Para tornar os programas mais flexíveis, colocaremos alguns parâmetros de controle fora do arquivo fonte e desta forma evitar a recompilação do programa. Arquivo de configuração do Cliente (cliente.conf) server=teste.com.br ou server= port=1300 user=jose passwd=teste123 dominio=dominio_a Onde os parametros são: server: nome do host ou endereço IP onde o servidor está sendo executado port: porta de comunicação onde o servidor está esperando ser contactado user: usuário utilizado para estabelecer a sessão com o servidor passwd: senha da conta user utilizado para estabelecer a sessão com o servidor dominio: identificação do dominio a qual pertence o usuário. Arquivo de configuração do Servidor (server.conf) Port=1300 portpeer=1500 maxsession=5 domino=dominio_a db=database.dbd Onde os parâmetros são: port: porta de comunicação onde o servidor irá ser contactado por um cliente (usuário) portpeer: porta de comunicação onde o servidor irá ser contatado por um cliente (servidor) maxsession: número máximo de Threads que será criado no servidor db: Nome do arquivo criado pelo bdb para armazenar as informação Arquivo de configuração de Peer (peer.conf)

7 ; Isto é um comentário ; Primeiro Peer Peer[1] ipaddress= portpeer=1234 user=teste pwd=teste123 domino=dominio_b ;Segundo Peer Peer[2] ipaddress= portpeer=5678 user=carlos123 pwd=mpb45& domino=dominio_c Onde os parametros são: peer[x] : identifica um determinado peer, onde x é um número qualquer que identifica uma ocorrencia de configuração de Peer. ipaddress: endereço IP do Peer portpeer: corresponde a porta de comunicação que o servidor está esperando a conexão com um Peer user: identificação a ser utilizado no momento da conexão com o Peer pwd: senha de autenticação a ser utilizado no momento da conexão com o Peer dominio: nome do dominio que o Peer é responsável PASSAGEM DE PARAMETROS PARA O CLIENTE O arquivo de configuração deverá ser buscado na pasta corrente onde o programa está sendo executado, porém podemos colocar o arquivo de configuração do cliente em qualquer outra pasta, para indicar a pasta onde se encontra o arquivo de configuração, utilizaremos o parametro c seguindo da localização no sistema de arquivo, como por exemplo:./cliente c /etc/client.conf Outro recurso que podemos utilizar é sobreposição de parametros do arquivo de configuração, utilizando parametros de linha de comando. s nome do servidor p porta de comunicação u usuário de autenticação w senha de autenticação d nome do dominio c local do arquivo de configuração

8 SEGURANÇA NA TRAVESSIA DA SENHA DE CONEXÃO A segurança da informação que transita pela rede é um ítem de muita importância. Para evitar que as informações de abertura de sessão (conta + senha) sejam interceptadas por qualquer software de monitoração, iremos utilizar a proteção de senha utilizando o algoritmo MD5 para cifrar as informações de autenticação. ANEXOS Os anexos que serão enviados através do serão armazenados fora do Banco de Dados, bastando existir somente um ponteiro (no banco de dados) para a sua localização no sistema de arquivos. O Cliente deve estar preparado para enviar mais de um anexo. SITES PARA REFERENCIA EM SOCKETS usr.inf.ufsm.br/~giovani/sockets/sockets.txt ENTREGA DE TRABALHO Data: 06/06/2010 até as 18:00 Penalidades: 2 pontos por minuto de atraso. Número máximo de componentes da equipe: 3 ÍTENS A SEREM AVALIADOS Funcionalidades (4,5 pontos) autenticação com MD5 (0,5) arquivo de configuração (cliente/servidor) (0,25) passagem de parâmetros (cliente) (0,25) implementação de funcionalidades (3,25) Debug (0,25) Codificação (0,5 ponto) Estruturação (0,25) Comentários (0,25) PRÉ REQUISITOS PARA DEFESA DO TRABALHO. O programa deve estar compilando sem erros. Desenvolvimento conforme especificação (cliente/servidor). O módulos de comandos (cliente/servidor) deve estar funcionando integralmente ou parcialmente no cliente e no servidor.

9 Não será aceita nenhuma correção no momento da defesa PRÉ REQUISITOS PARA RECEBIMENTO DA NOTA. Responder a questões que serão elaborados pelo professor, com o objetivo de comprovação da prova de autoria. O aluno que não souber responder as questões ou demonstrar insegurança nos questionamentos não terá direito a nota.