Operações em ambiente de fraca conectividade

Fraca conectividade é o equivalente ao fato do serviço de comunicações oferecido ser caro ou de baixa velocidade. Em tais redes, a conectividade é freqüentemente perdida por curtos períodos de tempo. Fraca conectividade impõe várias limitações que não estão presentes quando a conectividade é normal e força a revisão de vários sistemas de protocolo. Uma característica da fraca conectividade em computação móvel diz respeito à sua variação em intensidade. A conectividade em computação móvel varia em custo, largura de banda fornecida e confiabilidade. O objetivo das principais propostas para fraca conectividade é o uso prudente da largura de banda. Estas propostas procuram negociar “fidelidade” e redução do custo de comunicação.

3.2.2.1 Sistemas de Gerenciamento de Banco de Dados em ambientes de fraca conectividade

Uma estação móvel pode desempenhar diversos papéis num SGBD Distribuído. Ela pode, por exemplo, simplesmente submeter operações para que sejam executadas no servidor. Neste caso, ele pode determinar que as transações sejam executadas uma a uma ou que um conjunto de transações seja uma unidade atômica [JBE95].

O controle de concorrência no caso de transações distribuídas envolvendo estações fixas e móveis é complicado. Transações que acessam dados tanto em estações móveis quanto em estações fixas trazem consigo um grande overhead. Por exemplo, o caso de um protocolo pessimista de concorrência que requer que as transações realizem bloqueios em sites múltiplos. Neste caso, as transações poderiam ficar paradas por longos períodos se requisitassem bloqueio em sites que estivessem desconectados. Técnicas como timestamps podem ocasionar um grande número de transações abortadas já que as operações podem ser propagadas com retardo em redes de baixa velocidade.

Para evitar retardos impostos pela baixa velocidade da rede, modelos de open-nested transactions [Chr93] e esquemas de multiversão são mais apropriados.

Em [Chr93], uma transação móvel envolvendo estações fixas e móveis não são tratadas como uma unidade atômica, mas como um conjunto de componentes de transação relativamente independentes, alguns dos quais rodando unicamente nas estações móveis. Os componentes das transações podem ser confirmados sem aguardar a resposta de outras transações do conjunto. Em particular, como no caso da desconexão, as transações realizadas na estação móvel são visíveis somente para esta e seu resultado são visíveis para as transações locais subseqüentes. Estas transações são certificadas para correção nas estações fixas, posteriormente. As estações fixas podem difundir para as estações móveis informações sobre transações confirmadas antes do evento da certificação [Bar97]. Esta informação pode ser utilizada para reduzir o número de transações abortadas.

As transações que são executadas somente na estação móvel são denominadas fracas [PB95], [Pit96], enquanto que as transações restantes são denominadas estritas. As cópias fracas são apenas tentativas de confirmação e podem armazenar valores obsoletos. Transações fracas atualizam apenas cópias fracas, enquanto que transações estritas acessam cópias estritas localizadas em qualquer site. As cópias fracas são integradas com as cópias estritas quando um limite definido pela aplicação que permite a mudança entre cópias fracas e estritas é alcançado. As aplicações nos sites fracamente conectados podem optar pelo uso de transações estritas quando elas desejarem consistência estritas. As transações estritas são mais lentas que as transações fracas por envolverem o link de comunicação wireless, porém garantem consistência imediata em contrapartida.

Bayou [TDPS91] não suporta transações. Bayou é uma arquitetura peer-to-peer com um conjunto de servidores replicados fracamente e conectados um ao outro. Neste esquema, uma aplicação do usuário pode ler ou escrever qualquer cópia disponível.

Escritas são propagadas para outros servidores durante o contato entre os pares, denominado como anti-entropy sessions. Como na replicação two-tier, cada servidor mantém duas visões do banco de dados: uma cópia que reflete apenas os dados confirmados e outra cópia que também reflete as tentativas de escrita conhecidas pelo servidor. Eventualmente, cada escrita é confirmada utilizando um esquema de commit primário, onde um servidor é designado como primário e toma a responsabilidade de confirmar as atualizações. Em virtude dos servidores poderem receber atualizações

vindas dos usuários e de outros servidores em ordens diferentes, os servidores podem necessitar desfazer o efeito de algumas tentativas anteriores de uma operação de escrita e reaplicá-las. Bayou possibilita checagem de dependência para detecção automática de conflitos e procedures de fusão para resolução. Ao invés de transações, Bayou trabalha com sessões. Uma sessão é uma abstração para uma seqüência de operações de leitura e escrita realizadas durante a execução de uma aplicação.

3.2.2.2 Commit distribuído

O processamento do commit em ambientes distribuídos é geralmente implementado através do protocolo Two-Phase Commit (2PC) e suas variações. O modelo proposto nesta dissertação aplica diretamente o Presumed Abort Two-Phase Commit [OV99].

Se o papel das estações móveis é limitado em apenas emitir pedidos, o Two-Phase Commit pode ser aplicado sem modificações, em função do controle da transação está implicitamente designado a um site na rede fixa.

Algumas modificações podem ser implementadas no caso de redes móveis.

Jung em [JBE95] propõe que o fluxo do 2PC seja utilizado para carregar algumas informações extras para suportar o esquema de controle de concorrência. O processo de commit, entretanto permanece inalterado. Durante a desconexão as transações nos sites móveis são apenas tentativas de commit. Na integração, entretanto, estas tentativas fazem parte de uma transação distribuída que necessita ser confirmada.

Se a estação móvel participa ativamente dentro de uma transação móvel como um partner igual com seus dados próprios, então o processamento de commit deve levar em consideração os novos problemas que são impostos pela fraca conectividade. Os Protocolos de Commit deveriam ser estudados e melhorados levando em consideração as longas desconexões, conectividade intermitente, alta latência, largura de banda baixa, comunicação cara e mobilidade.

Limitações ao 2PC clássico, tal como o bloqueio [Ske91],[SBCM95], podem ocorrer mais freqüentemente no ambiente móvel e soluções como o processamento heurístico para estes problemas são necessárias.

O processamento de commit pode tirar vantagem das características de broadcast para otimizar a sua performance. As otimizações de commit podem ser ajustadas para a computação móvel. Enquanto o cliente móvel pode iniciar o processamento de commit, pode ser prudente transferir sempre, através da otimização do ultimo agente de commit, a coordenação de commit a um parceiro mais confiável.

3.2.2.3 Mobilidade

A configuração de um sistema distribuído que inclui elementos móveis é extremamente dinâmica. As unidades móveis comunicam-se diretamente com diferentes estações base enquanto entram e saem de células. Esta mobilidade também compreende o deslocamento de perfil e atividades de leitura e escrita [IB93]. Em função disso, itens ou tarefas deverão estar próximos destes elementos móveis para melhorar a performance. O custo de comunicação na computação móvel é diferente da comunicação fixa. Ela é aumentada pelo custo de busca que é necessário para determinar a localização exata das estações móveis [IB92]. Segundo, ela também pode ser baseada na duração da conexão como oposição ao número de mensagens enviadas.

Em virtude das mudanças de diversos parâmetros em função do tempo num ambiente de computação móvel, a alocação estática de dados, de certo, não é apropriada.

Huang em [HW94] descreve uma distinção entre o custo de replicação em ambientes de computação fixa e móvel, baseada na hipótese de que o custo de I/O torna-se insignificante, devido às taxas de comunicação. Um algoritmo de alocação de dados tem a propriedade de fazer com que um processador ao ter uma cópia, salvá-la em seu banco de dados. Assim, o algoritmo dinâmico é superior, comparado com o esquema estático.

O caso de usuários de computação móvel acessando dados de um banco de dados localizado em uma estação estática é considerado em [HSW94]. O problema discutido é o benefício, em termos de custo de comunicação, em se manter uma cópia local de um item de dados na estação móvel. Intuitivamente, manter uma cópia local é apropriado para itens de dados que são freqüentemente lidos, comparados à taxa com que são atualizados. Haveria então três alternativas para a alocação de cópias: no servidor, no cliente móvel e de servidores geograficamente (ou tecnicamente) localizados para o cliente [IB92]. A principal consideração é o custo de busca para localizar cópias em estações móveis. Assim, além das freqüências relativas das operações de leitura e escrita, a escolha de alocação também dependerá da mobilidade e do esquema de gerenciamento de localização.

Em [BGM94] são sugeridos algoritmos dinâmicos para alocação de dados replicados que podem ser obtidos simplesmente através de transações de atualização nos diretórios. Diretório é uma estrutura de dados que especifica os sites que contém cópias de itens de dados. Diretórios e outros itens de dados são tratados da mesma maneira. Para localizar cópias de dados, as transações primeiro executam bloqueios de leitura nos diretórios. Uma mudança na alocação das cópias é uma transação de atualização no diretório. Atualizações no diretório são serializáveis com transações regulares. Por fim, um diretório “primary-by-row” de gerenciamento é descrito, onde a reconfiguração é inicializada no site que mantém a cópia e deseja repassá-la para um outro site.