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

220 APÊNDICE A. DOORS
Para detectar esta situação, para cada volume, mantém-se a informação sobre o momento em que se
realizaram (directa ou transitivamente) as últimas sessões de sincronização com os outros servidores —
esta informação é transmitida e actualizada durante as sessões de sincronização. O facto de um servidor
activo na vista instalada localmente não participar nas sessões de sincronização durante um período
de tempo longo, considerando a frequência esperada das sessões de sincronização, pode indiciar que
o servidor foi removido usando como patrocinador um servidor que é desconhecido (outra hipótese é
tratar-se de um servidor desconectado temporariamente do sistema).
Um servidor, i, que detecte a situação anterior deve tentar estabelecer uma sessão de sincronização
com o servidor, j, que não tem participado nas sessões de sincronização. Se o servidor j responder, duas
hipóteses são possíveis. Primeiro, j ainda pertence ao grupo de replicadores — neste caso a sessão de
sincronização decorre normalmente. Segundo, j já não pertence ao grupo de replicadores e devolve a
lista dos servidores que pertenciam ao grupo de replicadores no momento da sua remoção. No caso de
existir algum elemento que não faça parte da vista instalada localmente, i deve tentar estabelecer uma
sessão de sincronização com esse servidor. Caso todos os elementos da lista devolvida por j pertençam
ao conjunto de replicadores conhecidos em i, i deve aguardar que a informação da remoção de j do
grupo de replicadores seja propagada até si (ou pode, alternativamente, estabelecer uma sessão de sin-
cronização com o patrocinador da remoção de j). Se o servidor j não responder, o servidor i pode usar o
mecanismo de descoberta dos servidores que replicam um dado volume (descrito na secção 6.2.3) para
tentar encontrar novos servidores que pertençam ao grupo de replicadores.
A.2.5 Disseminação de novas operações
Além do mecanismo básico de sincronização usando sessões epidémicas, cada servidor propaga os even-
tos submetidos localmente usando um canal de disseminação não fiável (descrito na secção 6.2.3). O
evento propagado tem a seguinte forma newop(viewid,id,op,nseqold), com viewid o identificador da
vista no servidor que submete o evento, id o identificador do coobjecto no qual a operação foi sub-
metida, op a sequência de operações que o servidor está a disseminar (op.srv e op.nseq identificam a
operação), e nseqold o número de sequência da operação que tinha sido identificada anteriormente em
op.srv.
Um servidor, ao receber um evento newop(viewid,id,op,nseqold), verifica se o identificador da vista
é igual ao identificador da vista instalada localmente e se o coobjecto referido é conhecido localmente.
Em caso afirmativo, a operação op é entregue ao coobjecto com identificador id e o sumário das opera-
ções conhecidas localmente é actualizado se se verificar que não existe nenhuma outra operação iden-
tificada nesse servidor que não seja conhecida, i.e., seja o o coobjecto com identificador id, tem-se que
o.l[op.srv] ≥ nseqold ⇒ o.l[op.srv] ← op.nseq.