Este projeto visa implementar um Sistema de Arquivos Distribuído (SAD) simples. O SAD é estruturado usando a arquitetura cliente/servidor. A técnica de Remote Procedure Call deve ser utilizada na implementação. As funções de acesso a arquivos devem ser idênticas àquelas oferecidas pelo sistema operacional UNIX, a saber:

1. int open( char *NomeDoArquivo, mode_t ModoDeAcesso, int Flags )
2. int close( int FileDescriptor )
3. int read( int FileDescriptor, void *Buffer, size_t NumeroDeBytes )
4. int write( int FileDescriptor, void *Buffer, size_t NumeroDeBytes )
5. int lseek( int FileDescriptor, off_t Offset, int Referencia )
6. int unlink( char *NomeDoArquivo )

Detalhes dessas funções podem ser obtidos de qualquer manual de programação UNIX. Para a rotina open, basta oferecer a funcionalidade do flag O_CREATE.

Normalmente, a funcionalidade do SAD seria oferecida pelo núcleo do sistema operacional, o que significa que as funções poderiam ser utilizadas com arquivos locais ou arquivos remotos. Entretanto, não estaremos implementando essas funções no núcleo do sistema UNIX mas como processos do usuário (user-level processes). Isto significa que teremos que alterar algumas coisas na especificação:

1. No sentido de não perder o acesso às funções open, etc. oferecidas pelo sistema operacional, teremos que alterar os nomes das funções acima para permitir a link-edição tanto dessas funções como das funções normais oferecidas pelo sistema operacional. Chamemos portanto as funções de ropen, rclose, rread, rwrite, rlseek e runlink (r significa remote).
2. Normalmente, o NomeDoArquivo poderia especificar um arquivo local ou um arquivo remoto. Como não estaremos implementando a funcionalidade de montagem (mounting) no projeto, os nomes dos arquivos das funções não são transparente e seguem a sintaxe: NomeDaMáquina:NomeDoArquivo. Não há conceito de diretório corrente, de forma que o NomeDoArquivo deverá ser um nome absoluto (iniciando com "/").

Depois de uma falha em qualquer uma das funções, a variável errno deve ser setada com o número correto de erro.

Três componentes devem ser desenvolvidos:

1. O servidor;
2. Uma biblioteca com as funções acima destinada a ser link-editada com o cliente. São essas funções que farão as chamadas remotas de procedimentos;
3. Um ou mais clientes, aplicações quaisquer que utilizem as funções da biblioteca do item 2.

Pelo menos dois clientes deverão ser desenvolvidos. O primeiro serve de testador para verificar a completa funcionalidade do serviço. O segundo é um programa de cópia com a sintaxe:

Você tem plena liberdade de escolher os detalhes de implementação (servidor com ou sem estado, técnicas de bufferização, etc.) desde que implemente a especificação acima.

Sugere-se desenvolver o projeto em C ou C++. Java também pode ser utilizado. Caso C ou C++ seja escolhido, utilize o pacote RPC da Sun. Com Java, utilize RMI (Remote Procedure Invocation). O LABCOM poderá ser utilizado para este projeto, inclusive pelos alunos de graduação.

Etapas sugeridas para o desenvolvimento do projeto (usando C):

1. Estudar o pacote RPC da Sun, principalmente rpcgen e XDR.
2. Fazer um pequeno teste de RPC utilizando exemplos dados na documentação da Sun.
3. Escolher a arquitetura básica do serviço (stateless ou statefull).
4. Especificar as RPCs utilizadas com seus parâmetros.
5. Escrever o testador (primeiro cliente) e testá-lo com funções normais do UNIX (open, read, ...).
6. Gerar os stubs do cliente e do servidor usando rpcgen da Sun.
7. Escrever a biblioteca de funções de acesso remoto a arquivos.
8. Escrever o servidor.
9. Link-editar o testador com a biblioteca de funções remotas.
10. Testar o serviço inteiro até que todos os testes do testador sejam bem sucedidos.
11. Escrever o cliente rpc e testá-lo. Se seu testador estiver completo, este programa deve funcionar de primeira!
12. Comparar o desempenho do seu programa rpc com:

• o comando rpc do sistema UNIX;
• o comando cp copiando arquivos remotos;
• o comando cp copiando arquivos locais.

Varie o tamanho dos buffers utilizados nas RPCs do seu programa cliente nestes testes de desempenho.

Entregar o código fonte comentado de tudo (2 clientes, biblioteca cliente, servidor), além dos resultados das comparações de desempenho.

• Projeto: 40%
• Provas: 60%

Para passar na disciplina, deve-se "passar" independentemente no projeto e nas provas.