________________________________________________________________________________________________

CDRM
________________________________________________________________________________________________

Implementamos o CDRM utilizando uma versão do FreePastry estendida com identificadores virtuais,
descrita na Seção~\ref{sec:virtualimpl}. Nesta seção, descrevemos brevemente os principais
componentes da implementação que realizamos do CDRM.

A classe \texttt{CdrmApp}, que implementa a interface \texttt{Application}, recebe e processa as
mensagens recebidas pelo CDRM provindas de outros nós. As mensagens podem ser de 2 tipos: (1)
requisição do endereço de um ADR para armazenamento de um fragmento e (2) requisição para o
armazenamento de um FFI no CDRM. Em ambos os casos, \texttt{CdrmApp} repassa a mensagens a classes
do sistema responsáveis pelo processamento destas mensagens.

Definimos também uma classe denominada \texttt{AdrManager}, que realiza o gerenciamento dos ADRs
presentes no aglomerado. Esta classe contém uma lista com os ADRs e suas características e é
responsável por realizar a seleção de ADRs que armazenarão fragmentos de arquivos. Para realizar a
seleção, o \texttt{AdrManager} seleciona apenas ADRs que estejam disponíveis no momento da
requisição e contenham espaço livre em disco suficiente para armazenar o fragmento. Uma thread
periodicamente checa por ADRs que não enviam mensagens de atualização por muito tempo, removendo-os
da lista.

Já a classe \texttt{FileFragmentIndexManager} realiza o armazenamento o gerenciamento de FFIs
armazenados naquele CDRM. Os FFIs são armazenados numa tabela de espalhamento utilizando seu
identificador como chave para facilitar sua busca. Finalmente, a classe
\texttt{FragmentLocationManager} mantém uma lista de todos os fragmentos armazenados no aglomerado,
incluindo o endereço do ADR que armazena de cada fragmento.

O CDRM define também duas interfaces CORBA. A primeira é utilizada pelos ADRs e permite que estes se
registrem no CDRM, atualizem seu estado e enviem mensagens periódicas de \emph{keep alive}. A
segunda interface é utilizada pelo \emph{access broker} para submeter requisições para o
armazenamento e recuperação de dados armazenados remotamente. Utilizamos o JacORB, uma implementação
de código aberto em Java da especificação CORBA.

________________________________________________________________________________________________

ADR
________________________________________________________________________________________________

Para implementar o ADR, utilizamos a linguagem C++, uma vez que é importante que este componente
tenha um baixo uso de memória.

Assim que o ADR é iniciado, ele se registra com o CDRM de seu aglomerado, enviando suas
características, como estado atual e espaço livre em disco na máquina. Além disso, uma thread
periodicamente envia atualizações ao CDRM para informar que aquele ADR está ativo. A comunicação com
o CDRM é feita utilizando o OiL, uma implementação código aberto em Lua da especificação
CORBA. Optamos por utilizar o OiL devido ao seu baixo consumo de memória.

O ADR instancia um servidor que espera por conexões para transmissão e recepção de fragmentos a
partir do \emph{access broker}. Para tal, este servidor abre um \emph{socket} TCP/IP numa porta da
máquina e aguarda por conexões provindas do \emph{access broker}. Para cada \emph{access broker} que
se conecta ao ADR, um novo processo é iniciado para tratar desta conexão, de modo que múltiplas
transferências podem ocorrer simultaneamente. A transferência do conteúdo dos fragmentos é realizada
utilizando o protocolo TCP e os dados são armazenados no disco da máquina à medida que são
recebidos.

________________________________________________________________________________________________

Access broker
________________________________________________________________________________________________

Implementamos o \emph{access broker} em C++ como uma biblioteca compartilhada. Definimos uma
interface em C com métodos para realizar o armazenamento e recuperação de dados. Definimos métodos
para realizar o armazenamento de modo síncrono, assíncrono e quasi-síncrono e para realizar a
recuperação de modo síncrono e assíncrono. Utilizamos o C++ na implementação porque, no caso do
\emph{access broker}, nossa principal preocupação é com o desempenho do processo de codificação dos
fragmentos.

O \emph{access broker} precisa se comunicar com o CDRM de seu aglomerado. Esta comunicação é
realizada para submeter requisições para obtenção de uma lista de endereços de ADRs para armazenar
fragmentos, requisições para o armazenamento de FFIs e requisições para a obtenção de FFIs. Neste
caso, o \emph{access broker} invoca métodos da interface CORBA definida no CDRM. O CDRM processa as
requisições de maneira assíncrono, de modo que as respostas são enviadas posteriormente ao
\emph{access broker}. Para tal, o \emph{access broker} instancia um servidor CORBA que permite que o
CDRM lhe envie respostas às requisições feitas. Do mesmo modo que nos ADRs, utilizamos o ORB OiL,
escrito em Lua, para realizar as comunicações em CORBA.

Para realizar a codificação dos dados em fragmentos, utilizamos uma versão otimizada do algoritmo de
dispersão de informação (IDA), proposta por Malluhi e Johnston~\cite{malluhi98}, que reduz a
complexidade computacional do processo de codificação e decodificação. Fizemos uma descrição
detalhada deste algoritmo de codificação na Seção~\ref{sec:strategies:ida}.
