gestão de dados partilhados em ambientes de computação móvel

6.3. CLIENTES 101
A propagação assíncrona é usada quando o cliente não necessita obter uma resposta imediata às
mensagens enviadas — por exemplo, quando propaga as modificações executadas por um utilizador a
um coobjecto. A semântica da propagação assíncrona é exactamente uma vez (exactly-once) (desde
que o cliente não fique definitivamente desconectado do servidor). Para tal, o subsistema de comu-
nicações mantém em memória estável a informação (conteúdo das mensagens, números de sequência
enviados/recebidos/garantidos) sobre as mensagens a enviar para os os diferentes parceiros (servidores e
outros clientes).
O subsistema de replicação antecipada (pre-fetching) é responsável por manter na cache do cliente
as cópias dos coobjectos necessárias para que os utilizadores continuem o seu trabalho em situações de
desconexão. Este subsistema tem acesso à informação de quais os coobjectos/subobjectos acedidos por
cada utilizador. Como se referiu anteriormente, o problema de determinar, de forma eficiente, quais são
os dados que devem ser obtidos para suportar a operação desconectada está fora do âmbito do trabalho
apresentado nesta dissertação. A solução implementada no protótipo DOORS é bastante simples e basei-
a-se numa política de replicação “menos recentemente utilizado” (least recently used) e na actualização
periódica dos coobjectos/subobjectos replicados no cliente.
6.3.5 Comunicação entre clientes
Por vezes, dois clientes que se encontram desconectados dos servidores conseguem comunicar directa-
mente entre si (por exemplo, usando redes de comunicação ad hoc estabelecidas usando dispositivos de
rede Bluetooth [19] ou wireless ethernet [73]). No sistema DOORS permite-se que os clientes explorem
estas comunicações para actualização do estado das suas réplicas secundárias.
Cada cliente implementa uma interface que permite aos outros clientes obter cópias de coobjec-
tos/subobjectos. Esta interface consiste nas operações getCoObject e getAddSubObject, definidas de
forma idêntica à da interface do servidor (e descritas na secção 6.2.4). Quando um cliente, i, recebe uma
operação getCoob ject (ou getAddSubOb ject) de outro cliente, j, podem ocorrer as seguintes situações.
• O cliente i não tem nenhuma cópia do coobjecto/subobjecto pedido. Neste caso a operação aborta
e o cliente j é informado do erro.
• O cliente i possui uma cópia inalterada do coobjecto/subobjecto pedido. Neste caso, o cliente i
actua de forma semelhante a um servidor, enviando para j o estado actual do coobjecto/subobjecto.
• O cliente i possui uma cópia provisória do coobjecto/subobjecto pedido, reflectindo as modifica-
ções efectuadas em i após o coobjecto/subobjecto ter sido obtido a partir de um servidor. Neste
caso, o cliente i responde com base na cópia obtida do servidor ou na versão provisória em função
das opções especificadas pelo cliente j.