gestão de dados partilhados em ambientes de computação móvel
gestão de dados partilhados em ambientes de computação móvel gestão de dados partilhados em ambientes de computação móvel
88 CAPÍTULO 6. NÚCLEO DO SISTEMA DOORS Para garantir estas propriedades, adicionou-se ao coobjecto de filiação uma operação de dissemina- ção e execução, detalhada no apêndice A.1.5. Esta operação permite executar uma acção dada como parâmetro apenas após a réplica do volume num servidor reflectir todas as operações conhecidas num dado conjunto de servidores no momento da submissão da operação de disseminação e execução. O protocolo de eliminação de um identificador, detalhado no apêndice A.1.6, é iniciado pelo patro- cinador da remoção e consiste nos seguintes passos. Primeiro, o patrocinador usa a operação de disse- minação e execução para garantir que nos vários servidores, apenas se inicia o processo de eliminação do servidor após terem sido propagadas todas as operações de todos os coobjectos recebidas do servidor removido. Segundo, cada servidor notifica os outros quando verifica que nenhum coobjecto necessita do identificador do servidor removido. Terceiro, quando num servidor se verifica que nenhum servidor activo necessita do identificador de um servidor, é submetida a operação de eliminação do identificador. Protocolo de saída forçada do grupo de replicadores Em geral, um servidor apenas cessa a repli- cação de um volume por sua iniciativa. No entanto, existem circunstâncias em que pode ser necessário forçar a remoção de um servidor do grupo de replicadores — por exemplo, porque o servidor ficou danificado e a memória estável na qual estava armazenado o estado dos coobjectos é irrecuperável. O protocolo de saída forçada do grupo de replicadores, detalhado no apêndice A.1.7, usa a seguinte aproximação. Primeiro, qualquer servidor pode sugerir a remoção de um (ou mais) servidor(es), mas o processo apenas prosseguirá se todos os outros servidores concordarem com a remoção. Segundo, após eleger um servidor como patrocinador da remoção, é necessário garantir que esse servidor recebe todas as operações conhecidas provenientes do servidor a remover. Terceiro, o servidor informa todos os coobjectos do volume da remoção do servidor e, de seguida, executa a operação de remoção no coobjecto de filiação no âmbito do protocolo local de mudança de vista. Protocolo de sincronização de vistas No sistema DOORS, dois servidores apenas podem comunicar para sincronizar o estado dos coobjectos se se encontrarem na mesma vista. Assim, dois servidores, i e j, que se encontrem em vistas diferentes devem executar previamente um protocolo de sincronização de vistas. Este protocolo consiste na sincronização das operações do coobjecto de filiação conhecidas pelos dois servidores — quando cada um dos servidores recebe o conjunto de operações enviadas pelo parceiro efectua o protocolo local de mudança de vista. No final do protocolo, conhecidas as mesmas operações relativas ao coobjecto de filiação, os dois servidores encontram-se na mesma vista. Durante a sincronização das operações conhecidas, cada servidor envia para o parceiro apenas as operações que sabe que ele não conhece — usando o sumário das operações conhecidas no parceiro (ou à falta deste sumário) o identificador da vista, que é igualmente um sumário das operações de inserção e remoção que o parceiro conhece.
6.2. SERVIDORES 89 6.2.2 Sincronização epidémica dos servidores Os servidores sincronizam as réplicas dos coobjectos de um volume durante sessões de sincronização epidémica [38] estabelecidas entre pares de servidores. Durante estas sessões, os servidores propagam entre si as operações de modificação que conhecem (independentemente do servidor no qual foram rece- bidas pela primeira vez). Desta forma, cada servidor recebe, para cada coobjecto, todas as modificações submetidas em todos os servidores, directa ou indirectamente. No sistema DOORS, considera-se que duas réplicas de um mesmo coobjecto estão sincronizadas quando conhecem o mesmo conjunto de ope- rações (e os sumários das operações conhecidas e executadas localmente e das operações conhecidas nos outros servidores são idênticos). No sistema DOORS, definiram-se dois protocolos de propagação epidémica. O primeiro protocolo é bilateral e durante a sua execução cada um dos servidores propaga as operações que conhece para o parceiro. O segundo protocolo é unilateral e apenas um dos servidores propaga as operações conhecidas para o parceiro. Protocolo de propagação epidémica bilateral O protocolo de propagação epidémica bilateral, de- talhado no apêndice A.2.2, consiste numa sequência de passos executados assincronamente — em cada um dos passos um servidor processa as mensagens recebidas e envia mensagens para o seu parceiro. Em cada um dos passos, e relativamente a cada um dos coobjectos a sincronizar, é possível: (1) solicitar o envio das operações não reflectidas num sumário; (2) enviar um conjunto de operações e solicitar o envio das operações não reflectidas num sumário; (3) solicitar o envio de uma cópia do coobjecto; (4) enviar uma cópia do coobjecto; (5) enviar a informação que o coobjecto foi eliminado. O protocolo de sincronização bilateral é iniciado com o servidor i a pedir que o parceiro lhe envie, para cada um dos coobjectos a sincronizar, as operações não reflectidas no sumário das operações co- nhecidas em i (este processo é optimizado para que não seja trocada informação relativa aos coobjectos estáveis, i.e., que não foram modificados recentemente). O protocolo continua por mais três passos, em que cada um dos parceiros responde aos pedidos recebidos e solicita o envio da informação necessária à sincronização das réplicas dos coobjectos. Protocolo de propagação epidémica unilateral No protocolo de propagação epidémica unilateral, detalhado no apêndice A.2.3, um servidor, i, envia para outro servidor, j, a informação que permite a j sincronizar o estado de j com o estado de i (i.e., o servidor j deve ficar a conhecer todas as operações conhecidas em i). Para tal, o servidor i envia para j todas as operações (e novos coobjectos) que, de acordo com o sumário das operações conhecidos nos outros servidores, não sabe serem conhecidas em j.
- Page 55 and 56: 3.3. FRAMEWORK DE COMPONENTES: COMP
- Page 57 and 58: 3.3. FRAMEWORK DE COMPONENTES: COMP
- Page 59 and 60: 3.3. FRAMEWORK DE COMPONENTES: COMP
- Page 61 and 62: 3.3. FRAMEWORK DE COMPONENTES: COMP
- Page 63 and 64: 3.3. FRAMEWORK DE COMPONENTES: COMP
- Page 65 and 66: 3.4. FRAMEWORK DE COMPONENTES: IMPL
- Page 67 and 68: 3.4. FRAMEWORK DE COMPONENTES: IMPL
- Page 69 and 70: Capítulo 4 Descrição das funcion
- Page 71 and 72: 4.1. RECONCILIAÇÃO 53 Segundo, um
- Page 73 and 74: 4.1. RECONCILIAÇÃO 55 4.1.3 Ordem
- Page 75 and 76: 4.1. RECONCILIAÇÃO 57 4.1.4.2 Ver
- Page 77 and 78: 4.1. RECONCILIAÇÃO 59 No decurso
- Page 79 and 80: 4.3. INVOCAÇÃO CEGA 61 4.3 Invoca
- Page 81 and 82: 4.4. INTEGRAÇÃO DE SESSÕES SÍNC
- Page 83 and 84: 4.4. INTEGRAÇÃO DE SESSÕES SÍNC
- Page 85 and 86: 4.4. INTEGRAÇÃO DE SESSÕES SÍNC
- Page 87 and 88: Capítulo 5 Avaliação do modelo d
- Page 89 and 90: 5.1. EDITOR MULTI-SÍNCRONO DE DOCU
- Page 91 and 92: 5.1. EDITOR MULTI-SÍNCRONO DE DOCU
- Page 93 and 94: 5.1. EDITOR MULTI-SÍNCRONO DE DOCU
- Page 95 and 96: 5.2. AGENDA PARTILHADA 77 Figura 5.
- Page 97 and 98: 5.2. AGENDA PARTILHADA 79 de awaren
- Page 99 and 100: Capítulo 6 Núcleo do sistema DOOR
- Page 101 and 102: 6.1. COOBJECTOS 83 o mesmo estado i
- Page 103 and 104: 6.2. SERVIDORES 85 global a associa
- Page 105: 6.2. SERVIDORES 87 segundo servidor
- Page 109 and 110: 6.2. SERVIDORES 91 6.2.3 Serviço d
- Page 111 and 112: 6.2. SERVIDORES 93 ao cliente compl
- Page 113 and 114: 6.2. SERVIDORES 95 • Emulação d
- Page 115 and 116: 6.3. CLIENTES 97 do coobjecto consi
- Page 117 and 118: 6.3. CLIENTES 99 seguinte informaç
- Page 119 and 120: 6.3. CLIENTES 101 A propagação as
- Page 121 and 122: Capítulo 7 Apresentação do siste
- Page 123 and 124: 7.1. MODELO GERAL 105 encomenda de
- Page 125 and 126: 7.2. ARQUITECTURA 107 BD réplica C
- Page 127 and 128: 7.2. ARQUITECTURA 109 O subsistema
- Page 129 and 130: 7.3. TRANSACÇÕES MÓVEIS 111 7.3
- Page 131 and 132: 7.3. TRANSACÇÕES MÓVEIS 113 abor
- Page 133 and 134: Capítulo 8 Reservas Neste capítul
- Page 135 and 136: 8.1. TIPOS DE RESERVAS 117 8.1.4 Re
- Page 137 and 138: 8.2. CONCESSÃO E GARANTIA DE RESPE
- Page 139 and 140: 8.2. CONCESSÃO E GARANTIA DE RESPE
- Page 141 and 142: 8.3. PROCESSAMENTO DAS TRANSACÇÕE
- Page 143 and 144: 8.4. PROCESSAMENTO DAS TRANSACÇÕE
- Page 145 and 146: 8.5. EXEMPLOS 127 id tipo tabela co
- Page 147 and 148: 8.5. EXEMPLOS 129 1 ------ COMPRA 1
- Page 149 and 150: Capítulo 9 Avaliação do modelo b
- Page 151 and 152: 9.1. APLICAÇÕES 133 1 ------ REMO
- Page 153 and 154: 9.2. RESERVAS 135 dentemente em dif
- Page 155 and 156: 9.2. RESERVAS 137 seguinte forma. P
6.2. SERVIDORES 89<br />
6.2.2 Sincronização epidémica dos servidores<br />
Os servidores sincronizam as réplicas dos coobjectos <strong>de</strong> um volume durante sessões <strong>de</strong> sincronização<br />
epidémica [38] estabelecidas entre pares <strong>de</strong> servidores. Durante estas sessões, os servidores propagam<br />
entre si as operações <strong>de</strong> modificação que conhec<strong>em</strong> (in<strong>de</strong>pen<strong>de</strong>nt<strong>em</strong>ente do servidor no qual foram rece-<br />
bidas pela primeira vez). Desta forma, cada servidor recebe, para cada coobjecto, todas as modificações<br />
submetidas <strong>em</strong> todos os servidores, directa ou indirectamente. No sist<strong>em</strong>a DOORS, consi<strong>de</strong>ra-se que<br />
duas réplicas <strong>de</strong> um mesmo coobjecto estão sincronizadas quando conhec<strong>em</strong> o mesmo conjunto <strong>de</strong> ope-<br />
rações (e os sumários das operações conhecidas e executadas localmente e das operações conhecidas nos<br />
outros servidores são idênticos).<br />
No sist<strong>em</strong>a DOORS, <strong>de</strong>finiram-se dois protocolos <strong>de</strong> propagação epidémica. O primeiro protocolo<br />
é bilateral e durante a sua execução cada um dos servidores propaga as operações que conhece para o<br />
parceiro. O segundo protocolo é unilateral e apenas um dos servidores propaga as operações conhecidas<br />
para o parceiro.<br />
Protocolo <strong>de</strong> propagação epidémica bilateral O protocolo <strong>de</strong> propagação epidémica bilateral, <strong>de</strong>-<br />
talhado no apêndice A.2.2, consiste numa sequência <strong>de</strong> passos executados assincronamente — <strong>em</strong> cada<br />
um dos passos um servidor processa as mensagens recebidas e envia mensagens para o seu parceiro. Em<br />
cada um dos passos, e relativamente a cada um dos coobjectos a sincronizar, é possível: (1) solicitar o<br />
envio das operações não reflectidas num sumário; (2) enviar um conjunto <strong>de</strong> operações e solicitar o envio<br />
das operações não reflectidas num sumário; (3) solicitar o envio <strong>de</strong> uma cópia do coobjecto; (4) enviar<br />
uma cópia do coobjecto; (5) enviar a informação que o coobjecto foi eliminado.<br />
O protocolo <strong>de</strong> sincronização bilateral é iniciado com o servidor i a pedir que o parceiro lhe envie,<br />
para cada um dos coobjectos a sincronizar, as operações não reflectidas no sumário das operações co-<br />
nhecidas <strong>em</strong> i (este processo é optimizado para que não seja trocada informação relativa aos coobjectos<br />
estáveis, i.e., que não foram modificados recent<strong>em</strong>ente). O protocolo continua por mais três passos, <strong>em</strong><br />
que cada um dos parceiros respon<strong>de</strong> aos pedidos recebidos e solicita o envio da informação necessária à<br />
sincronização das réplicas dos coobjectos.<br />
Protocolo <strong>de</strong> propagação epidémica unilateral No protocolo <strong>de</strong> propagação epidémica unilateral,<br />
<strong>de</strong>talhado no apêndice A.2.3, um servidor, i, envia para outro servidor, j, a informação que permite a j<br />
sincronizar o estado <strong>de</strong> j com o estado <strong>de</strong> i (i.e., o servidor j <strong>de</strong>ve ficar a conhecer todas as operações<br />
conhecidas <strong>em</strong> i). Para tal, o servidor i envia para j todas as operações (e novos coobjectos) que, <strong>de</strong><br />
acordo com o sumário das operações conhecidos nos outros servidores, não sabe ser<strong>em</strong> conhecidas <strong>em</strong><br />
j.