O Modelo Cliente/Servidor serve de base para o desenvolvimento de serviços no âmbito dos Sistemas Operacionais de Rede. O papel básico do servidor consiste em atender vários clientes que desejam requisitar serviços sobre um recurso compartilhado gerenciado pelo servidor.
Neste projeto enfatizamos a troca de informações entre dois processos desenvolvido segundo o Modelo Cliente/Servidor para manutenção e gerenciamento de uma base de dados. Tanto o cliente quanto o servidor são instanciados na mesma máquina e devem se comunicar através da API de Sockets TCP/IP.
Dentre os objetivos deste projeto destacamos:
O projeto está dividido em 02 etapas. A primeira consiste em aproveitando parte do que foi desenvolvido no trabalho anterior, mude a pilha de comunicação para que a aplicação possa trocar as informações com o Protocolo TCP e UDP, ou seja, os dois protocolos da camada de transporte deverão ser suportados.
O projeto A Aplicação continua a mesma do trabalho anterior, ou seja, é uma aplicação elementar da base de dados no UNIX. A aplicação consiste de uma agenda eletrônica onde são armazenados nomes e números de telefones. A chave de acesso é o nome. A aplicação apresenta um menu do tipo:
Na opção "Inserir/Atualizar um Registro" o programa pede o nome e o número do telefone. Caso um registro com o nome já esteja armazenado, o programa alerta o usuário solicitando permissão para atualizar o registro. Na opção "Lista Registros da Agenda" todos os registros são listados. Nas opções "Remove um Registro da Agenda" e "Acessa um Registro da Agenda" - apenas o nome é solicitado. A opção de remoção retorna um indicativo de sucesso (registro removido) ou falha (registro não encontrado), enquanto na opção de acesso o programa retorna o número do telefone ou um indicativo de falha (registro não encontrado). A última opção finaliza a aplicação cliente, antes porém informa através de uma mensagem de controle enviada ao servidor o seu término. Isto permite ao servidor controlar quais clientes estão ativos em um dado instante.
A segunda parte consiste em contemplar esta versão com algumas transparências quanto ao nome, localização e persistência do servidor. Assim, um novo servidor deverá ser proposto, "Servidor de Nome". Dentre as tarefas desde servidor, caberá ao mesmo a atribuição de nomes únicos aos servidores (p.e., servidor de base de dados) por ele cadastrados. Este servidor terá "host" e "port" conhecidos na rede, assim, tanto os clientes quanto os servidores de aplicação poderão a qualquer tempo contactá-lo, seja para solicitação obter referência de serviços previamente cadastrados ou para cadastramento de serviços por servidores.
A comunicação do servidor de aplicação e cliente com o "Servidor de Nomes" deverá utilizar o Protocolo TCP. Já a comunicação Cliente e Servidor de Aplicação deverá contemplar duas versões, uma utilizando o Protocolo TCP e outra o UDP. Em tendo mais de um Servidor de Aplicação, cada um se cadastra no Servidor de Nomes, fornecendo "host" e "port" que está utilizando, e recebe a confirmação do nome que lhe foi atribuído pelo Servidor de Nomes. Como sugestão, considere na formação no nome, o "nome do serviço", "host" e "port" do servidor de aplicação. Quando um Cliente contactar o Serviço de Nomes fornecendo o "nome do serviço" que deseja utilizar, o Servidor de Nomes devolve o "host" e "port" onde o servidor da referida aplicação está sendo executado. Caso a aplicação não esteja ativa, o Servidor de Nomes irá instanciá-la no mesmo "host" em que está instanciado, cadastrá-lo e então responder ao Cliente. Desta forma, estaremos de certo modo contemplando parte do conceito de persistência.
Para um melhor entendimento da API de Sockets TCP/IP utilize o Guira de Referência Beej's Guide Network Programming
Adicionalmente, os dois exemplos seguintes devem ser utilizados para um completo entendimento e familiarização da API de Sockets. Para "Sockets sem Conexão" (Protocolo UDP): UDP-Server e UDP-Client. Já para "Sockets com Conexão" (Protocolo TCP): TCP-Server e TCP-Client.