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

A.2. SINCRONIZAÇÃO EPIDÉMICA 217
i e j conhecem o coobjecto o
(1) i (asksync,...)
−−−−−−→ j
(sync,...)
(2) j ←−−−−− i
i conhece todas as operações conhecidas em j
(3) i (sync,...)
−−−−−→ j
i
j conhece todas as operações conhecidas em
i conhece o coobjecto o e j não conhece
(1) i (asksync,...)
−−−−−−→ j
(askstate,...)
(2) j ←−−−−−−− i
(3) i (newstate,...)
−−−−−−−→ j
j obtém o estado de o conhecido em i
j conhece o coobjecto o e i não conhece
(1) i noop
−−→ j
(asksync,...)
(2) j ←−−−−−− i
(3) i (askstate,...)
−−−−−−−→ j
(newstate,...)
(3) j ←−−−−−−− j
i obtém o estado de o conhecido em j
Figura A.3: Descrição da sincronização de um coobjecto usando o protocolo de sincronização bilateral.
servidor que recebe as mensagens verifica se se encontra na mesma vista do servidor que enviou as men-
sagens (linhas 2-4 da função stepBiE pidemic). Caso se encontrem em vistas diferentes, as mensagens
recebidas são ignoradas e os servidores iniciam um protocolo de sincronização das vistas, enviando para
o outro servidor todas as operações relativas ao coobjecto de filiação desconhecidas pelo outro servidor.
Na figura A.3 apresentam-se as diferentes possibilidades de sincronização de um coobjecto, depen-
dendo de o coobjecto ser já conhecido nos servidores quando o protocolo é iniciado. Assim, verifica-se
que o protocolo de sincronização se pode concluir ao fim da quarta interacção, i.e., quando o servidor
que iniciou o protocolo recebe uma resposta pela segunda vez — nesse momento, cada um dos servido-
res recebeu as operações conhecidas pelo outro servidor no momento em que iniciou a participação no
protocolo. No entanto, como o protocolo pode ser estabelecido usando meios de comunicação assíncro-
nos, a latência da comunicação pode aconselhar a que o protocolo continue por mais alguns passos. No
código apresentado na figura A.2 esta decisão deve ser definida na função lastStep. No último passo do
protocolo, o servidor limita-se a processar as operações recebidas do parceiro sem lhes responder.
O protocolo implementado no sistema DOORS apresenta algumas diferenças de pormenor em rela-
ção ao código das figuras A.1 e A.2. Primeiro, ao conjunto de coobjectos a sincronizar, Ob js, é adicio-
nado o conjunto de coobjectos necessários para os instanciar (i.e., seja o code
i
código para instanciar o coobjecto oi, tem-se Ob js ← Ob js ∪ {o code
i
o coobjecto que contém o
: oi ∈ Ob js}). Adicionalmente, os
coobjectos que contêm código para instanciar outros coobjectos são processados antes desses coobjectos
(i.e., o code
i
é processado antes de oi) — desta forma garante-se que um servidor contém sempre o código
necessário a processar as operações relativas aos coobjectos.
A segunda diferença consiste numa optimização para omitir o envio de informação que se sabe que o
parceiro conhece. Assim, um servidor omite sempre o envio de operações (sync,...) desde que as seguin-
tes condições se verifiquem: (1) não existem operações a enviar; (2) o sumário das operações conhecidas
pelos dois parceiros é igual 8 — o sumário das operações conhecidas no parceiro é o recebido durante o
8 Esta condição não é idêntica à anterior porque é possível sumários diferentes reflectirem o mesmo conjunto de operações
— por exemplo, se l[i] = n e l[i] = n + 1 reflectem o mesmo conjunto de operações se não existir (no presente nem no futuro)
nenhuma operação submetida em i com número de sequência n + 1.