BR112020020799A2 - Sincronização de banco de dados ponto a ponto sobre um protocolo de transporte - Google Patents

Abstract

um mecanismo inclui receber, em um nó local, uma mensagem de olá incluindo um identificador de aplicativo (appid) e um enlace de destino entre uma porta de destino para um nó local e uma porta de destino para um nó vizinho. o nó local determina que appid está associado a um aplicativo para realizar a sincronização de banco de dados. o nó local configura um banco de dados local na memória no nó local como parte de um par de banco de dados para uso pelo aplicativo, o par de banco de dados incluindo um banco de dados vizinho no nó vizinho. o nó local associa o par de banco de dados ao enlace de destino. o nó local controla a sincronização de banco de dados local com o banco de dados vizinho por meio do enlace de destino.

Description

SINCRONIZAÇÃO DE BANCO DE DADOS PONTO A PONTO SOBRE UM PROTOCOLO DE TRANSPORTE REFERÊNCIA CRUZADA A PEDIDOS RELACIONADOS

[0001] Este pedido de patente reivindica o benefício do Pedido de Patente Provisório US nº 62/655,625, depositado em 10 de abril de 2018 por Dean Cheng, et al., E intitulado "Sincronização de Banco de Dados Ponto a Ponto sobre um Protocolo de Transporte" e Pedido Patente Provisório US nº 62/782,993, depositado em 20 de dezembro de 2018 por Dean Cheng, et al., E intitulado “Sincronização de Banco de Dados Ponto a Ponto sobre um Protocolo de Transporte” que são aqui incorporados por referência.

CAMPO TÉCNICO

[0002] A presente divulgação está geralmente relacionada ao gerenciamento de banco de dados e está especificamente relacionada a protocolos de comunicação para gerenciar a sincronização de banco de dados ponto a ponto.

ANTECEDENTES

[0003] A sincronização de banco de dados é o processo de estabelecer consistência entre vários sistemas de banco de dados. O objetivo da sincronização de banco de dados é garantir que as alterações em um primeiro banco de dados sejam propagadas para um ou mais sistemas de banco de dados correspondentes. A sincronização de banco de dados pode envolver a criação de implementações específicas de aplicativos complicadas que podem não ser interoperáveis com outras implementações. Pode ser necessário que tais aplicativos implementem mecanismos de gerenciamento de recursos de comunicação para garantir consistência e verificar se as informações são realmente recebidas por outros sistemas de banco de dados. Além disso, manter a sincronização de banco de dados pode se tornar problemático no caso de perda de conectividade. Por exemplo, retransmitir todos os arquivos de banco de dados ao restabelecer a conectividade pode ser um uso ineficiente dos recursos de comunicação em alguns casos.

SUMÁRIO

[0004] Em uma modalidade, a divulgação inclui um método implementado em um nó local, o método compreendendo: receber, em um receptor no nó local, uma mensagem de olá incluindo um identificador de aplicativo (AppId) e um enlace de destino entre uma porta de destino para um nó local e porta de destino para um nó vizinho; determinar, por um processador no nó local, que o AppId está associado a um aplicativo para realizar sincronização de banco de dados; configurar um banco de dados local na memória no nó local como parte de um par de banco de dados para uso pelo aplicativo, o par de banco de dados incluindo um banco de dados vizinho no nó vizinho; associar, pelo processador, o par de banco de dados ao enlace de destino; e controlar a sincronização de banco de dados local com o banco de dados vizinho por meio do enlace de destino. Essa abordagem permite que um protocolo de comunicação configure automaticamente um ou mais pares de banco de dados para sincronização em uma rede. O protocolo obtém um enlace de destino e o AppId das mensagens de olá. O protocolo pode então correlacionar o aplicativo com o enlace de destino e configurar bancos de dados para sincronização em nome do aplicativo. Dessa forma, a configuração do banco de dados pode ser descarregada do aplicativo, o que permite que a sincronização de banco de dados seja configurada e mantida sem gerenciamento direto pelo aplicativo. Isso, por sua vez, permite que o aplicativo execute a sincronização de banco de dados sem estar diretamente ciente das mensagens de rede subjacentes para realizar essa sincronização.

[0005] Opcionalmente, em qualquer um dos aspectos anteriores, outra implementação do aspecto inclui, em que controlar a sincronização de banco de dados local com o banco de dados vizinho inclui a transmissão, por um transmissor no nó local, de informações de registro para o banco de dados vizinho através do enlace de destino nas Mensagens de Unidade de Dados de Protocolo de Registro Local (LRPDU) de Enlace. As informações do banco de dados são armazenadas em registros. As informações de versão do registro (por exemplo, informações de controle) são trocadas por meio de LRPDUs enviados pelo enlace de destino. Portanto, as mensagens LRPDU podem atuar como um mecanismo para indicar a um nó vizinho que os registros de banco de dados foram atualizados e vice- versa. Como tal, as mensagens LRPDU podem ser empregadas para gerenciar a sincronização de banco de dados.

[0006] Opcionalmente, em qualquer dos aspectos anteriores, outra implementação do aspecto inclui, em que o banco de dados local inclui um banco de dados de solicitante para armazenar registros locais para transmissão a um banco de dados de registro no banco de dados vizinho.

[0007] Opcionalmente, em qualquer um dos aspectos anteriores, outra implementação do aspecto inclui, em que o banco de dados local inclui um banco de dados de registro para receber registros vizinhos de um banco de dados de solicitante no banco de dados vizinho. Os pares de banco de dados incluem um solicitante, que contém os registros a serem carregados, e um registro que recebe cópias dos registros do solicitante. Um nó local e um nó vizinho podem incluir um banco de dados de solicitante e um banco de dados de registro para sincronização bidirecional. Além disso, um banco de dados de solicitante pode ser posicionado em um nó local e um banco de dados de registro pode ser posicionado em um nó vizinho, ou vice-versa, para sincronização unilateral.

[0008] Opcionalmente, em qualquer um dos aspectos anteriores, outra implementação do aspecto inclui, em que a mensagem de olá é um LRPDU de olá, e em que o LRPDU de olá representa o enlace de destino como um identificador (ID) de Meu Chassi identificando o nó local, um ID de Minha Porta que identifica uma porta de destino no nó local, um ID de Chassi Vizinho que identifica o nó vizinho, e um ID de Porta Vizinha que identifica uma porta de destino no nó vizinho. O enlace de destino pode ser especificado pelo ID de chassi e ID de porta, que representa uma porta de destino em cada extremidade do enlace de destino. Essa abordagem permite a identificação única do enlace de destino e, portanto, uma indicação para cada um do nó local e do nó vizinho, onde o nó correspondente pode ser localizado para fins de comunicação LRPDU.

[0009] Em uma modalidade, a divulgação inclui um método implementado em um nó local, o método compreendendo: transmitir, por um transmissor no nó local, uma ou mais mensagens LRPDU de registro em direção a um banco de dados de registro em um nó vizinho, as mensagens LRPDU de registro indicando atualizações para registros armazenados em um banco de dados de solicitante no nó local; receber, por um receptor no nó local, uma ou mais mensagens LRPDU reconhecendo as mensagens LRPDU de registro; marcar, em uma memória no nó local, pelo menos um registro atualizado no banco de dados de solicitante, conforme reconhecido pelo banco de dados de registro; e notificar, por meio do processador, um aplicativo de que o banco de dados de solicitante está sincronizado com o banco de dados de registro. Esse mecanismo permite que um protocolo de comunicação de rede monitore as comunicações do banco de dados e determine quando os bancos de dados são sincronizados. O protocolo de rede pode então alertar o aplicativo que a sincronização foi concluída. Dessa maneira, o aplicativo não precisa estar ciente de cada troca de registro e comunicações associadas. O aplicativo pode fazer alterações no banco de dados local do solicitante e permitir que o protocolo de rede gerencie a sincronização e alerte o aplicativo quando a sincronização for concluída.

[0010] Opcionalmente, em qualquer um dos aspectos anteriores, outra implementação do aspecto inclui, compreendendo ainda determinar, por um processador no nó local, que todos os registros atualizados no banco de dados de solicitante são reconhecidos pelo banco de dados de registro por meio de mensagens LRPDU, em que a notificação da solicitação de que o banco de dados de solicitante seja sincronizado com o banco de dados de registro é iniciada com base na determinação de que todos os registros atualizados no banco de dados de solicitante são reconhecidos pelo banco de dados de registro por meio de mensagens LRPDU. O solicitante pode determinar quando cada registro é reconhecido e notificar o aplicativo quando todos os registros são reconhecidos e, portanto, a sincronização entre o banco de dados de solicitante e o banco de dados de registro está completa.

[0011] Opcionalmente, em qualquer dos aspectos anteriores, outra implementação do aspecto inclui, em que as mensagens LRPDU reconhecendo as mensagens LRPDU de registro incluem uma mensagem LRPDU de lista parcial, a mensagem LRPDU de lista parcial incluindo pelo menos um cabeçalho de registro reconhecendo pelo menos um registro atualizado. A mensagem LRPDU de lista parcial atua como uma mensagem de reconhecimento. A mensagem LRPDU de lista parcial é enviada do registro e indica ao solicitante que o registro fez a atualização solicitada pela mensagem LRPDU de registro.

[0012] Opcionalmente, em qualquer um dos aspectos anteriores, outra implementação do aspecto inclui, em que o cabeçalho de registro inclui um número de registro que indica o registro atualizado e um número de sequência que identifica uma atualização incluída no registro atualizado. Essas informações podem indicar as atualizações de registro específicas que foram recebidas pelo registro.

[0013] Opcionalmente, em qualquer um dos aspectos anteriores, outra implementação do aspecto inclui, ainda, a geração de uma notificação de falha para o aplicativo quando um temporizador de mensagem LRPDU de registro expira sem receber uma mensagem LRPDU de lista parcial correspondente. Esse mecanismo permite que o aplicativo seja notificado sobre possíveis falhas de comunicação de registro. A mensagem LRPDU de registro pode não ser reenviada automaticamente, pois grandes volumes de comunicações podem sobrecarregar os buffers de recepção no registro (por exemplo, potencialmente causando mais falhas de sincronização de registro).

[0014] Opcionalmente, em qualquer um dos aspectos anteriores, outra implementação do aspecto inclui, em que as mensagens LRPDU reconhecendo as mensagens LRPDU de registro incluem uma mensagem LRPDU de lista completa, a mensagem LRPDU de lista completa incluindo cabeçalhos de registro para todos os registros no banco de dados de registro. A mensagem LRPDU de lista completa pode ser enviada pelo registro em um intervalo predeterminado. A mensagem LRPDU de lista completa inclui o estado atual do banco de dados de registro. Portanto, o solicitante pode utilizar a mensagem LRPDU de lista completa para determinar quando os registros foram recebidos pelo registro e a mensagem de reconhecimento foi descartada e quando as atualizações dos registros não foram recebidas pelo registro. O solicitante pode então se recuperar de erros de sincronização enviando mensagens LRPDU de registro adicionais com base no conteúdo da mensagem LRPDU de lista completa.

[0015] Opcionalmente, em qualquer um dos aspectos anteriores, outra implementação do aspecto inclui, em que a mensagens LRPDU de lista completa inclui um primeiro campo de número de registro indicando o primeiro registro armazenado no banco de dados de registro e um último campo de número de registro indicando o último registro armazenado no banco de dados de registro, e em que os cabeçalhos de registro incluem números de registro indicando os registros armazenados no banco de dados de registro e números de sequência que identificam as atualizações incluídas nos registros armazenados no banco de dados de registro.

[0016] Opcionalmente, em qualquer um dos aspectos anteriores, outra implementação do aspecto inclui, em que as mensagens LRPDU de registro incluem um ou mais números de registro indicando registros atualizados no banco de dados de solicitante e um ou mais números de sequência identificando atualizações incluídas nos registros atualizados na base de dados de solicitante.

[0017] Opcionalmente, em qualquer um dos aspectos anteriores, outra implementação do aspecto inclui, compreendendo ainda: transmitir, pelo transmissor, uma mensagem LRPDU de lista completa de solicitação para o banco de dados de registro; e receber, pelo receptor, uma mensagem LRPDU de lista completa do banco de dados de registro em resposta à mensagem LRPDU de lista completa de solicitação. Ao empregar esse mecanismo, o solicitante pode solicitar uma mensagem LRPDU de lista completa sob demanda, em vez de esperar por uma mensagem LRPDU de lista completa periódica.

[0018] Em uma modalidade, a divulgação inclui um método implementado em um nó local, o método compreendendo: gerar, por um processador no nó local, um código desconectado para um aplicativo, o código desconectado indicando que uma troca de mensagens de olá de unidade de dados de protocolo de registro local (LRPDU) de enlace falhou; receber, no processador, um comando do aplicativo para manter um banco de dados de solicitante na memória no nó local, apesar do código desconectado; receber, por um receptor no nó local, uma mensagem LRPDU de lista completa de um banco de dados de registro em um nó vizinho após uma troca bem-sucedida de mensagens LRPDU de olá, a mensagens LRPDU de lista completa incluindo cabeçalhos de registro para todos os registros no banco de dados de registro; e comparar, pelo processador, os cabeçalhos de registro da mensagem LRPDU de lista completa com os cabeçalhos de registro no banco de dados de solicitante para ressincronizar o banco de dados de solicitante com o banco de dados de registro. Este mecanismo permite manter um par de banco de dados, apesar de uma perda de conexão. Quando ocorre uma perda de conexão, o solicitante é notificado e tem permissão para escolher se deseja redefinir a sincronização no restabelecimento de conexão (por exemplo, reenviando todos os registros) ou recuperar a sincronização no restabelecimento de conexão. O par de banco de dados pode ser mantido enviando uma mensagem de lista completa do registro ao se reconectar por meio da troca de olá. O banco de dados de solicitante pode então comparar os cabeçalhos de registro do banco de dados de registro com os cabeçalhos de registro do banco de dados de solicitante para determinar quais atualizações, se houver, foram perdidas devido à perda de conexão. O banco de dados de solicitante pode então reenviar apenas as atualizações perdidas, em vez de reenviar toda a lista de registros de banco de dados de solicitante ao registro. Tal abordagem pode diminuir o uso de recursos de rede e o tempo de recuperação de sincronização quando ocorre uma conexão de rede entre o solicitante e o registro.

[0019] Opcionalmente, em qualquer um dos aspectos anteriores, outra implementação do aspecto inclui, compreendendo ainda redefinir temporizadores de notificação no banco de dados de solicitante após uma troca malsucedida de mensagens de olá para evitar a transmissão de mensagens LRPDU de registro até que a mensagem LRPDU de lista completa seja recebida. Isso faz com que o banco de dados de solicitante pare de tentar sincronizar os bancos de dados até que a conexão seja restaurada e, portanto, economiza recursos de rede e de processamento.

[0020] Opcionalmente, em qualquer dos aspectos anteriores, outra implementação do aspecto inclui,

compreendendo ainda: determinar, pelo processador, uma incompatibilidade entre um ou mais cabeçalhos de registro no banco de dados de solicitante e um ou mais cabeçalhos de registro da mensagens LRPDU de lista completa; e transmitir uma mensagem LRPDU de registro para o banco de dados de registro, a mensagem LRPDU de registro contendo cabeçalhos de registro atualizados que tratam da incompatibilidade. Em caso de incompatibilidade, os registros atualizados podem ser enviados do solicitante para o registro. Isso pode ocorrer porque uma mensagem anterior do LRPDU do Registro foi perdida na perda de conexão.

[0021] Opcionalmente, em qualquer dos aspectos anteriores, outra implementação do aspecto inclui, compreendendo ainda: determinar, pelo processador, não incompatibilidade entre os cabeçalhos de registro no banco de dados de solicitante e os cabeçalhos de registro do banco de dados de registro; e com base na determinação de não incompatibilidade, notificar, por meio do processador, o aplicativo que o banco de dados de solicitante está sincronizado com o banco de dados de registro. Isso permite que o protocolo de rede gerencie a sincronização em nome do aplicativo e, portanto, permite que o aplicativo desconheça as especificações de comunicação relacionadas à sincronização de banco de dados.

[0022] Em uma modalidade, a divulgação inclui um nó local que compreende uma memória, um transmissor, um receptor e um processador acoplado à memória, o transmissor, o receptor, o nó local configurado para realizar o método dos aspectos anteriores.

[0023] Em uma modalidade, a divulgação inclui um meio legível por computador não transitório compreendendo um produto de programa de computador para uso por um nó local, o produto de programa de computador compreendendo instruções executáveis por computador armazenadas no meio legível por computador não transitório de modo que quando executado por um processador fazer com que o nó local realize o método dos aspectos anteriores.

[0024] Em uma modalidade, a divulgação inclui nó local que compreende: um módulo de recepção para receber uma mensagem de olá incluindo um identificador de aplicativo (AppId) e um enlace de destino entre um nó local e um nó vizinho; um módulo de determinação para determinar o AppId está associado a um aplicativo para realizar a sincronização de banco de dados; um módulo de configuração de par de banco de dados para configurar um banco de dados local no nó local como parte de um par de banco de dados para uso pelo aplicativo, o par de banco de dados incluindo um banco de dados vizinho no nó vizinho; um módulo de associação para associar o par de banco de dados ao enlace de destino; e um módulo de controle de sincronização para controlar a sincronização de banco de dados local com o banco de dados vizinho através do enlace de destino.

[0025] Em uma modalidade, a divulgação inclui um nó local que compreende: um módulo de transmissão para transmitir uma ou mais mensagens de unidade de dados de protocolo de registro local (LRPDU) de enlace de registro para um banco de dados de registro em um nó vizinho, as mensagens LRPDU de registro indicando atualizações de registros armazenados em um banco de dados de solicitante no nó local; um módulo de recepção para receber uma ou mais mensagens LRPDU reconhecendo as mensagens LRPDU de registro; um módulo de memória para marcar pelo menos um registro atualizado no banco de dados de solicitante, como reconhecido pelo banco de dados de registro; um módulo de determinação para determinar se todos os registros atualizados no banco de dados de solicitante são reconhecidos pelo banco de dados de registro por meio de mensagens LRPDU; e um módulo de notificação para notificar um aplicativo de que o banco de dados de solicitante está sincronizado com o banco de dados de registro com base na determinação de que todos os registros atualizados no banco de dados de solicitante são reconhecidos pelo banco de dados de registro por meio de mensagens LRPDU.

[0026] Em uma modalidade, a divulgação inclui um nó local que compreende: um módulo de desconexão para gerar um código desconectado para um aplicativo, o código desconectado indicando que uma troca de mensagens de olá de unidade de dados de protocolo de registro local (LRPDU) de enlace falhou; um módulo de comando para receber um comando do aplicativo para manter um banco de dados de solicitante na memória no nó local, apesar do código desconectado; um módulo de recepção para receber uma mensagem LRPDU de lista completa de um banco de dados de registro em um nó vizinho após uma troca bem- sucedida de mensagens de olá, a mensagem LRPDU de lista completa incluindo cabeçalhos de todos os registros no banco de dados de registro; e um módulo de comparação de registros para comparar os cabeçalhos de registro da mensagem LRPDU de lista completa com os cabeçalhos de registro no banco de dados de solicitante para ressincronizar o banco de dados de solicitante com o banco de dados de registro.

[0027] Opcionalmente, em qualquer um dos nós locais anteriores, outra implementação do nó local inclui, compreendendo ainda módulos para realizar o método de qualquer um dos aspectos anteriores.

[0028] Para fins de clareza, qualquer uma das modalidades anteriores pode ser combinada com qualquer uma ou mais das outras modalidades anteriores para criar uma nova modalidade dentro do escopo da presente divulgação.

[0029] Estas e outras características serão mais claramente compreendidas a partir da seguinte descrição detalhada tomada em conjunto com os desenhos e reivindicações anexos.

BREVE DESCRIÇÃO DOS DESENHOS

[0030] Para uma compreensão mais completa desta divulgação, é feita agora referência à seguinte breve descrição, tomada em conexão com os desenhos anexos e a descrição detalhada, em que numerais de referência semelhantes representam peças semelhantes.

[0031] A FIG. 1 é um diagrama esquemático de um exemplo de implementação de sistema nativo de uma rede de sincronização de banco de dados.

[0032] A FIG. 2 é um diagrama esquemático de um exemplo de implementação de sistema proxy de uma rede de sincronização de banco de dados.

[0033] A FIG. 3 é um diagrama esquemático de um sistema de banco de dados de exemplo para sincronização de banco de dados.

[0034] A FIG. 4 é um diagrama de protocolo de um método de exemplo de gerenciamento de sincronização de banco de dados.

[0035] A FIG. 5 ilustra um exemplo de codificação de uma mensagem de olá de Unidade de Dados de Protocolo de Registro Local (LRPDU) de Enlace.

[0036] A FIG. 6 ilustra um exemplo de codificação de uma mensagem LRPDU de registro.

[0037] A FIG. 7 ilustra um exemplo de codificação de uma mensagem LRPDU de lista parcial.

[0038] A FIG. 8 ilustra um exemplo de codificação de uma mensagem LRPDU de lista completa.

[0039] A FIG. 9 é um fluxograma de um método de exemplo para estabelecer um par de banco de dados.

[0040] A FIG. 10 é um fluxograma de um método de exemplo de gerenciamento de sincronização de par de banco de dados.

[0041] A FIG. 11 é um fluxograma de um método de exemplo para manter a sincronização de banco de dados, apesar da interrupção de conexão.

[0042] A FIG. 12 é um diagrama esquemático de um exemplo de elemento de rede para gerenciar a sincronização de banco de dados.

[0043] A FIG. 13 é um diagrama esquemático de um dispositivo de exemplo para estabelecer um par de banco de dados.

[0044] A FIG. 14 é um diagrama esquemático de um dispositivo de exemplo para gerenciar a sincronização de pares de banco de dados.

[0045] A FIG. 15 é um diagrama esquemático de um dispositivo de exemplo para manter a sincronização de banco de dados, apesar da interrupção de conexão.

DESCRIÇÃO DETALHADA

[0046] Deve ser entendido desde o início que, embora uma implementação ilustrativa de uma ou mais modalidades seja fornecida abaixo, os sistemas e/ou métodos divulgados podem ser implementados usando qualquer número de técnicas, sejam atualmente conhecidas ou existentes. A divulgação não deve de forma alguma ser limitada às implementações ilustrativas, desenhos e técnicas ilustradas abaixo, incluindo os projetos e implementações exemplares ilustrados e descritos neste documento, mas pode ser modificada dentro do escopo das reivindicações anexas, juntamente com seu escopo completo de equivalentes.

[0047] Protocolos de comunicação padronizados podem ser empregados para suportar a sincronização de banco de dados. Esses protocolos de comunicação podem ser configurados para manter a consistência do banco de dados de maneira padronizada. Por exemplo, Protocolo de Registro Local (LRP) de Enlace é um padrão que especifica protocolos, procedimentos e objetos gerenciados para replicar um banco de dados de registro de uma extremidade a outra extremidade de um enlace ponto a ponto e para replicar alterações em partes desse banco de dados. O LRP pode ser otimizado para bancos de dados da ordem de um megabyte. A Sincronização de Banco de Dados LRP (LRP-DS) pode ser empregada para configurar comunicações entre bancos de dados. O LRP-DS emprega mensagens de olá, de maneira semelhante ao protocolo de Sistema Intermediário para Sistema Intermediário (IS-IS), para estabelecer adjacências de nós. O Transporte de Banco de Dados LRP (LRP-DT) pode então ser empregado para transportar dados, transportados em mensagens de Registro fornecidas por LRP-DS, de uma maneira semelhante às mensagens de Aviso de Estado de Enlace (LSA) transportadas por IS-IS.

O LRP-DS, portanto, gerencia a sincronização de banco de dados em nome de aplicativos relacionados.

[0048] São divulgados aqui mecanismos para melhorar a funcionalidade do LRP-DS. Por exemplo, o LRP-DS pode ser aprimorado para configurar automaticamente pares de banco de dados para sincronização. O par de banco de dados inclui um banco de dados de solicitante em um primeiro nó e um banco de dados de registro em um segundo nó. Esses nós também podem ser referidos como um nó local e um nó vizinho, respectivamente, para clareza de discussão. Quando atualizações são feitas no banco de dados de solicitante, o protocolo LRP-DS comunica essas atualizações ao banco de dados de registro para manter a sincronização. Para comunicação unilateral, o nó local contém um banco de dados de solicitante e o nó vizinho contém um banco de dados de registros. Para comunicação bidirecional, o nó local contém um banco de dados de solicitante para sincronização com um banco de dados de registros no nó vizinho e o nó vizinho contém um banco de dados de solicitante para sincronização com um banco de dados de registros no nó local. Em qualquer um dos casos, o(s) par(es) de banco de dados podem ser configurados automaticamente na troca de mensagens de olá de unidade de dados de protocolo de registro local (LRPDU) de enlace. As mensagens LRPDU de olá contêm um identificador de aplicativo (AppId) do aplicativo correspondente e um enlace de destino denotado em termos de um identificador (ID) de Meu Chassi que identifica o nó local, um ID de Minha Porta que identifica uma porta de destino no nó local, um ID de Chassi Vizinho que identifica o nó vizinho e um ID de Porta Vizinha que identifica uma porta de destino no nó vizinho. Após a troca de mensagens de olá, o nó local e o nó vizinho podem criar automaticamente pares de banco de dados de solicitante e registro para o aplicativo identificado e correlacionar tais pares de banco de dados com base no enlace de destino.

[0049] O LRP-DS, que opera em um componente denominado portal, também pode ser empregado para informar automaticamente ao aplicativo quando os bancos de dados são sincronizados após uma ou mais atualizações. Por exemplo, quando uma atualização é feita em um banco de dados de solicitante, uma mensagem LRPDU de registro é enviada ao banco de dados de registro para indicar os registros de banco de dados que foram atualizados e o(s) número(s) de sequência (por exemplo, números de versão) de tais registros atualizados. O banco de dados de registro responde com uma mensagem LRPDU de lista parcial que reconhece os registros atualizados, que podem ser comunicados via LRP-DT. Quando a mensagem LRPDU de lista parcial é recebida, o portal faz com que os registros indicados na base de dados de solicitantes sejam marcados como reconhecidos. Vários LRPDUs de registro e LRPDUs de lista parcial podem ser trocados. Quando todos os registros na base de dados do solicitante forem marcados como reconhecidos, o portal pode enviar uma indicação ao aplicativo de que as bases de dados estão sincronizadas.

[0050] Em outro exemplo, o LRP-DS pode ser empregado para manter a sincronização entre os bancos de dados, apesar de uma interrupção de conexão. As mensagens LRPDU de olá podem ser trocadas periodicamente. Quando uma troca de mensagens LRPDU de olá falha, o portal pode notificar o aplicativo. O solicitante pode optar por excluir o emparelhamento e criar um novo par de banco de dados na reconexão, recarregando os registros de banco de dados para o novo banco de dados de registro. O solicitante também pode optar por atualizar o par de banco de dados atual. Quando o portal recebe uma indicação de que o emparelhamento do banco de dados deve ser mantido, o portal interrompe outras mensagens LRPDU de registro. Ao restabelecer uma troca de mensagens LRPDU de olá, o registro envia uma mensagem LRPDU de lista completa ao solicitante. A mensagem LRPDU de lista completa contém cabeçalhos de registro para todos os registros no banco de dados de registro. O banco de dados de solicitante pode comparar os cabeçalhos de registro na mensagem LRPDU de lista completa com os cabeçalhos de registros armazenados no banco de dados de solicitante para determinar qualquer incompatibilidade de registro. Isso pode acontecer quando as mensagens LRPDU de registro são perdidas devido à perda de conexão. O banco de dados de solicitante pode então enviar mensagens LRPDU de registro contendo quaisquer atualizações de registro feitas desde o estado do registro contido na mensagem LRPDU de lista completa. Normalmente, o resultado é a transmissão de menos LRPDUs de registro do que seria o caso sem a transmissão rápida de LRPDU de lista completa. O portal também pode notificar o aplicativo assim que os bancos de dados forem sincronizados. Estas e outras modalidades de exemplo são discutidas em mais detalhes em relação às seguintes FIGS.

[0051] A FIG. 1 é um diagrama esquemático de um exemplo de implementação de sistema nativo de uma rede de sincronização de banco de dados 100. A rede de sincronização de banco de dados 100 inclui um sistema nativo 110 e um sistema nativo 130 acoplado por uma rede de Protocolo de

Internet (IP) 171. O sistema nativo 110 e o sistema nativo 130 incluem um ou mais bancos de dados 120 e 122, respectivamente, para sincronização. Para clareza de discussão, um sistema nativo 110 ou 130 é referido neste documento como local quando discutido com respeito às operações de origem que ocorrem em um primeiro sistema e como um vizinho quando discutido com respeito a operações de destino que ocorrem em um segundo sistema. Portanto, os sistemas nativos 110 e 130 podem ser locais, vizinhos ou ambos, dependendo do contexto. Deve-se notar também que os termos local e vizinho, como usados neste documento, são relativos, são empregados para distinguir claramente entre um primeiro nó e um segundo nó e podem ser usados indistintamente quando se discute a mesma rede de uma perspectiva diferente.

[0052] O sistema nativo 110 é um componente de computação que inclui um aplicativo 111, um portal 113, uma porta de destino 141 e bancos de dados 120. Um aplicativo 111 é um programa de computador operável para distribuir informações entre pelo menos o sistema nativo 110 e/ou sistema proxy e um sistema nativo 130 e/ou um sistema proxy. Os sistemas proxy são discutidos em relação à FIG. 2 abaixo. Por exemplo, o aplicativo 111 pode incluir um programa operável pelo usuário com um arquivo salvo que é sincronizado com um sistema de armazenamento em nuvem. O aplicativo 111 carrega dados para um aplicativo 131 e/ou baixa dados de um aplicativo

131. Para fins de simplicidade, apenas dois aplicativos 111 e 131 são mostrados, mas o aplicativo 111 pode sincronizar com qualquer número de outros aplicativos.

[0053] Um portal 113 é uma instanciação de uma interface de portal, junto com instâncias de máquinas de estado de solicitante e/ou registro e bancos de dados 120 associados a um único aplicativo 111. Por exemplo, o portal 113 opera LRP (por exemplo, LRP-DS e LRP-DT) em nome do aplicativo 111. O portal 113 recebe notificações do aplicativo 111 e/ou bancos de dados 120, realiza operações LRP correspondentes e fornece notificações responsivas ao aplicativo 111 e/ou bancos de dados 120. Por exemplo, o portal 113 opera LRP-DS gerenciando a comunicação de mensagens LRPDU. O portal 113 opera LRP-DT comunicando dados, como registros de banco de dados 120, com um portal 133 correspondente, por exemplo, por meio de uma conexão de protocolo de controle de transmissão (TCP) 170. Em alguns exemplos, um aplicativo 111 em um sistema nativo 110 mantém um portal separado 113 e bancos de dados correspondentes 120 em cada uma das muitas portas de destino 141 no sistema nativo

110.

[0054] O sistema nativo 110 também pode operar um Protocolo de Descoberta de Camada de Enlace (LLDP) 161 sobre a porta de destino 141. Alternativamente, o sistema nativo 110 mantém um repositório de informações, controlado por um administrador de sistema, contendo dados equivalentes aos gerados pelo LLDP 161.

[0055] Os bancos de dados 120 incluem um ou mais repositórios de armazenamento de arquivos para um aplicativo

111. Os arquivos em bancos de dados 120 são armazenados como registros. Um registro é um subconjunto de um banco de dados 120 que é transferido como uma unidade única de um solicitante para um registro pelo LRP operando no portal 113. Cada registro inclui dados, um número de registro que identifica os dados e um número de sequência. O número de sequência identifica a versão atual do registro. Por exemplo, o número de sequência pode ser implementado como um contador que indica o número de vezes que um registro foi atualizado. Os bancos de dados 120 podem incluir um banco de dados de solicitante, um banco de dados de registro ou ambos. Um solicitante é uma das duas funções (com o registro) que um aplicativo 111 pode ter em relação a um portal 113. O solicitante controla um banco de dados 120 que o LRP replica para um registro em um portal vizinho 133. Um registro é uma das duas funções (com o solicitante) que um aplicativo 111 pode ter em relação a um portal 113. O registro recebe a cópia do banco de dados 122 que o LRP replica do solicitante no portal vizinho 133. Como tal, os bancos de dados 120 podem incluir um banco de dados de solicitante para carregar registros para o banco de dados 122, um banco de dados de registro para baixar registros de banco de dados 122 ou ambos para comunicação bidirecional de registros com bancos de dados 122.

[0056] Uma porta de destino 141 é uma porta de comunicação em um sistema nativo 110. Um portal 113 e bancos de dados de solicitante e registro associados 120 estão associados a uma única porta de destino 141. Uma porta de destino 141 pode ser associada a mais de um portal 113 se tais portais 113 servirem a diferentes aplicativos 111. Uma porta de destino 141 fornece acesso a um enlace que se conecta a uma ou mais portas 151 de destino (por exemplo, em outros sistemas).

[0057] O sistema nativo 130 é substancialmente semelhante ao sistema nativo 110. O sistema nativo 130 contém um portal 133, um aplicativo 131, um banco de dados 122 e uma porta de destino 151, que pode ser substancialmente semelhante ao portal 113, um aplicativo 111, um banco de dados 120 e uma porta de destino 141, respectivamente.

[0058] Os sistemas nativos 110 e 130 descobrem um ao outro para configurar o pares de banco de dados 120 e 122 via LLDP 161. O LLDP 161 é um protocolo de camada de enlace, descrito pelo documento padrão 802.1AB do Instituto de Engenheiros Elétricos e Eletrônicos (IEEE), usado por dispositivos de rede para anunciar sua identidade, recursos e vizinhos em uma rede. Em particular, os sistemas nativos 110 e 130 podem anunciar seus aplicativos 111 e 131, LRP-DS e capacidades LRPDT entre si, por meio das portas de destino 141 e 151 empregando LLDP 161. Os endereços para uso pelo LRP-DT ao transportar mensagens LRPDU podem ser determinados por meio do LLDP 161, junto com uma preferência para usar o Protocolo de Controle de Borda (ECP) 160 ou o Protocolo de Controle de Transmissão (TCP) para transportar essas mensagens LRPDU. ECP 160 é um protocolo de rede definido pelo padrão IEEE 802.1Q-2014. O TCP 170 é definido pela Solicitação para Comentário (RFC) de documento de Força Tarefa de Engenharia de Internet (IETF) 793. Qualquer um pode ser usado para transportar mensagens LRPDU. Se o ECP 160 for usado, os pacotes do ECP passarão pelas portas 141 e 151 de destino. Se TCP 170 for usado, os pacotes LRPDU podem passar pelas portas de destino 141, 151 ou por qualquer outra porta nos dois sistemas nativos 110 e 130.

[0059] As mensagens LRPDU atuam como mensagens de controle que indicam atualizações de registros nos bancos de dados 120 e/ou 122, reconhecimentos e outras informações de gerenciamento relacionadas à sincronização de banco de dados. As mensagens LRPDU aqui discutidas incluem mensagens

LRPDU de olá, mensagens LRPDU de registro, mensagens LRPDU de lista parcial, mensagens LRPDU de lista completa e mensagens LRPDU de lista completa de solicitação. No entanto, outras mensagens LRPDU podem ser empregadas conforme desejado para impor a sincronização de banco de dados 120 e

122. Usando as mensagens LRPDU, os portais 113 e 133 podem trocar registros de banco de dados 120 e 122 para sincronizar os bancos de dados 120 e 122. Por exemplo, os LRPDUs de registro de banco de dados 120 e 122 podem ser trocados por meio de uma conexão TCP 170. A conexão TCP 170 é uma sessão de comunicação ponto a ponto utilizada para a troca de dados. A conexão TCP 170 pode ser roteada entre as portas de destino 141 e 151 ou entre outras portas, dependendo do exemplo. A conexão TCP 170 pode atravessar uma ou mais redes IP 171, que são redes de três camadas de modelo de Interconexão de Sistemas Abertos (OSI) que suportam comunicações ponto a ponto. Conforme discutido em relação às FIGS. abaixo, os componentes anteriores podem ser empregados pelos portais 113 e/ou 133 para gerenciar a sincronização de banco de dados 120 e 122 em nome dos aplicativos 111 e/ou 131, em parte através das portas de destino 141 e 151.

[0060] A FIG. 2 é um diagrama esquemático de um exemplo de implementação de sistema proxy de uma rede de sincronização de banco de dados 200. A rede de sincronização de banco de dados 200 inclui um proxy 210, um proxy 230, um escravo 240 e um escravo 250. A rede de sincronização de banco de dados 200 é semelhante à rede de sincronização de banco de dados 100, mas as portas de destino 241 e 251 foram movidas de sistemas nativos para escravos 240 e 250, respectivamente. Conforme usado neste documento, um proxy 210 e/ou 230 é um componente de computação que contém pelo menos um aplicativo 211, que é substancialmente semelhante ao aplicativo 111. Por exemplo, um proxy 210 contém pelo menos um aplicativo 211 operável para distribuir informações entre o proxy 210 e um sistema nativo e/ou um sistema proxy 230. O proxy 210 também pode conter um portal 213 e/ou bancos de dados 220, que são substancialmente semelhantes ao portal 113 e bancos de dados 120, respectivamente.

[0061] Um escravo 240 pode ser um componente de comunicação, como um roteador, switch, etc., ou pode ser uma estação final, como uma câmera, atuador mecânico ou computador pessoal. O escravo 240 é acoplado ao proxy 210 por uma conexão de rede. O escravo contém pelo menos uma porta de destino 241, que é substancialmente semelhante à porta de destino 141. Um componente de comunicação contém várias portas de destino 241. O proxy 210 e o escravo 240 funcionam juntos de uma maneira que é substancialmente semelhante ao sistema nativo 110. Ao posicionar a porta de destino 241 no escravo 240 em vez do proxy 210, o aplicativo 211, portal 213 e/ou bancos de dados 220 podem ser descarregados para um dispositivo (o proxy 210) que pode estar em uma rede separada do escravo 240. Isso fornece flexibilidade de implementação enquanto fornece substancialmente a mesma funcionalidade.

[0062] O proxy 230 é substancialmente semelhante ao proxy 210 e contém um portal 233, aplicativo 231 e bancos de dados 222, que podem ser substancialmente semelhantes ao portal 213, aplicativo 211 e bancos de dados 220, respectivamente. O escravo 250 é acoplado ao proxy 230 e contém uma porta de destino 251, que pode ser substancialmente semelhante à porta de destino 241. Os escravos 240 e 250 empregam LLDP 261 para trocar mensagens LLDP entre as portas de destino 241 e 251 de uma maneira semelhante ao LLDP 161. Os escravos 250 e 240 podem encaminhar tais mensagens para os portais 233 e 213, respectivamente. As informações de registro das mensagens LLDP podem ser empregadas para configurar a comunicação do banco de dados 220 e/ou registros 222 para sincronização através de uma rede IP 271. A rede IP 271 pode ser substancialmente semelhante à rede IP 171. Esses registros podem ser comunicados por meio de uma conexão TCP 270, que é substancialmente semelhante à conexão TCP 170.

[0063] Deve-se notar que várias combinações de redes de sincronização de banco de dados 100 e 200 também podem ser empregadas dentro do escopo desta divulgação. Por exemplo, um sistema nativo 110 pode ser empregado para sincronizar bancos de dados 120 com um proxy 230 e um escravo

250. Além disso, um sistema nativo 130 pode ser empregado para sincronizar bancos de dados 122 com um proxy 210 e um escravo 240. Vários sistemas de retransmissão (por exemplo, roteadores e/ou pontes) podem ser empregados para rotear as comunicações entre os sistemas nativos, proxies e/ou escravos. Esses componentes podem incluir vários recursos, conforme discutido abaixo. Em qualquer dispositivo de comunicação, o aplicativo 111, 131, 211 e/ou 231 pode trocar informações entre o solicitante e o registro nos bancos de dados 120, 122, 220 e 222 em diferentes portas de destino 141, 151, 241 e 251 pertencentes ao mesmo sistema.

[0064] A FIG. 3 é um diagrama esquemático de um sistema de banco de dados de exemplo 300 para sincronização de banco de dados. O sistema de banco de dados 300 pode ser usado para implementar um sistema nativo 110, um sistema nativo 130, um proxy 210 e/ou um proxy 230. O sistema de banco de dados 300 inclui um aplicativo 311, que é substancialmente semelhante ao aplicativo 111, 131, 211 e/ou 231. Especificamente, o aplicativo 311 é um programa que emprega dados para sincronização com um sistema remoto, como um banco de dados vizinho. O aplicativo instancia um portal 313, que é substancialmente semelhante ao portal 113, 133, 213 e/ou

233. O portal 313 opera LRP (por exemplo, LRP-DS e LRP-DT) em nome do aplicativo 311. Assim, o portal 313, entre outros processos, gerencia a comunicação de mensagens e registros LRPDU para fins de sincronização. O portal 313 interage com o aplicativo 311 e bancos de dados 320, que são substancialmente semelhantes aos bancos de dados 120, 122, 220 e/ou 222. Os bancos de dados 320 podem incluir um solicitante 321 e/ou um registro 325.

[0065] Um solicitante 321 é uma máquina de estado e espaço de memória correspondente configurado para fazer carregamento de cópias de dados armazenados localmente para um registro em um banco de dados vizinho. Um registro 325 é uma máquina de estado e um espaço de memória correspondente configurado para receber cópias de dados armazenados remotamente de um solicitante em um banco de dados vizinho. Portanto, um banco de dados 320 pode conter um solicitante 321 para fazer carregamento de dados para sincronização, um registro 325 para baixar dados para sincronização ou ambos para sincronização bidirecional. O solicitante 321 e o registro 325 são associados ao portal 313 para garantir que as mensagens de controle e os dados cheguem aos destinos pretendidos. O portal 313 é ainda associado a uma porta de destino para garantir que as mensagens sejam recebidas em seus portais pretendidos (por exemplo, portal 313).

[0066] Os dados nos bancos de dados 320 são armazenados em registros. Um registro é a menor unidade de dados que pode ser comunicada para sincronização. Tamanhos de registro podem ser configurados pelo aplicativo 311. Registros menores criam complexidade, mas registros maiores resultam na transferência de mais dados quando uma parte de um registro é atualizada.

[0067] O solicitante 321 contém registros locais 323 e cabeçalhos de registros locais 324. Os registros locais 323 são registros que contêm dados usados localmente pelo aplicativo 311. Cabeçalhos de registro são um grupo predefinido de informações de estado relacionadas aos registros correspondentes. Por exemplo, os cabeçalhos de registro local 324 contêm um número de registro, um número de sequência e/ou uma soma de verificação para os registros locais correspondentes 323. Um número de registro indica o registro correspondente. Um número de sequência inclui informações de versão. Por exemplo, um número de sequência pode incluir um contador indicando um número de vezes que o registro correspondente foi modificado. Uma soma de verificação é uma informação de verificação de erro e pode incluir um dígito que representa a soma de um número correto de dígitos em um conjunto correspondente de dados para transmissão. Por exemplo, a soma de verificação pode indicar a soma do número correto de dígitos no número do registro e no número da sequência. Como tal, quando um registro local 323 é atualizado, o cabeçalho de registro local correspondente 324 pode ser sinalizado para indicar o registro que foi atualizado e a versão (por exemplo, número de sequência) da atualização.

[0068] O registro 325 contém registros vizinhos 326 e cabeçalhos de registros vizinhos 327. Os registros vizinhos 326 e os cabeçalhos de registros vizinhos 327 são semelhantes aos registros locais 323 e aos cabeçalhos de registros locais 324, respectivamente, mas estão relacionados aos dados usados por um aplicativo em um nó/sistema vizinho.

[0069] Consequentemente, um banco de dados local 320 pode incluir um banco de dados de solicitante 321 para armazenar registros locais 323 para transmissão para um banco de dados de registro em um banco de dados vizinho. O banco de dados local 320 também pode incluir um banco de dados de registro 325 para receber registros vizinhos 326 de um banco de dados de solicitante no banco de dados de vizinhos. Esta transferência de registros pode ser realizada empregando mensagens LRPDU. Por exemplo, uma mensagem LRPDU de registro pode ser transmitida do portal 313 quando os registros locais 323 são modificados. A mensagem LRPDU de registro contém os cabeçalhos de registro local correspondentes 324 para notificar o registro no banco de dados vizinho sobre os registros locais 323 que foram atualizados e o número de sequência atual da atualização. O portal 313 pode receber uma Lista de Registro Parcial responsiva do vizinho que reconhece as atualizações dos registros locais. O portal 313 também pode configurar uma transferência de dados com o portal no nó vizinho para transferir os registros locais atualizados 323. Da mesma forma, um solicitante em um vizinho pode enviar uma mensagem LRPDU de registro para o portal 313, por meio do portal vizinho, para indicar alterações nos registros vizinhos 326. A mensagem LRPDU de registro do vizinho contém os cabeçalhos de registro vizinho atualizados

327. O registro 325 pode então responder por meio do portal 313 com uma mensagem LRPDU de lista parcial contendo os cabeçalhos de registro vizinho atualizados 327 para indicar o conhecimento das atualizações no banco de dados vizinho. O portal 313 também pode gerenciar uma transferência de dados dos registros vizinhos atualizados 326 do vizinho para o registro 325. Estes e outros esquemas de mensagens para troca de registros e cabeçalhos de registro entre os solicitantes 321 e os registros 325 para sincronização são discutidos em relação às FIGS abaixo.

[0070] A FIG. 4 é um diagrama de protocolo de um método de exemplo 400 de gerenciamento de sincronização de banco de dados. O método 400 pode ser implementado por um sistema nativo 110 e/ou 130, um proxy 210 e/ou 230 em conjunto com um escravo 240 e/ou 250 e/ou um sistema de banco de dados

300. O método 400 fornece mecanismos para criar e manter um par de banco de dados, incluindo um solicitante e um registro. O gerenciamento de um par de banco de dados inclui a manutenção da sincronização entre o banco de dados de solicitante e o banco de dados de registro. O método 400 é implementado por um aplicativo, um portal local que controla um banco de dados de solicitante em um nó local e um portal vizinho que controla um banco de dados de registro em um nó vizinho.

[0071] Em alguns exemplos, o portal local e o portal vizinho são pré-configurados com portas e endereços de nó(s) vizinho(s) relacionados ao aplicativo. Em outros exemplos, o portal local e o portal vizinho descobrem portas e endereços de nós vizinhos relacionados ao aplicativo por meio de outros protocolos de descoberta. Em ambos os casos, o portal local encaminha uma mensagem LRPDU de olá 401 para o portal vizinho, e o portal vizinho encaminha uma mensagem LRPDU de olá 403 para o portal local. Isso também pode ser referido como uma troca de mensagens LRPDU de olá. As mensagens LRPDU de olá 401 e 403 incluem um identificador de aplicativo (AppId) e identificam um enlace de destino entre uma porta de destino para um nó local e a porta de destino para um nó vizinho. O AppId indica o aplicativo e, portanto, indica que o remetente está associado a um aplicativo que deseja sincronizar dados. O enlace de destino nas mensagens LRPDU de olá 401 e 403 indica que a tentativa de comunicação foi bem-sucedida e a sincronização pode começar.

[0072] Da mesma forma, quando o portal local recebe as mensagens LRPDU de olá 403, o portal local determina que o AppId está associado a um aplicativo para realizar a sincronização de banco de dados. O portal local então configura um banco de dados local na memória no nó local como parte de um par de banco de dados para uso pelo aplicativo. Neste exemplo, o banco de dados local inclui um solicitante. Além disso, quando o portal vizinho recebe as mensagens LRPDU de olá 401, o portal vizinho determina que o AppId está associado a um aplicativo para realizar a sincronização de banco de dados. O portal vizinho então configura um banco de dados vizinho na memória no nó vizinho como parte do par de banco de dados. Neste exemplo, o banco de dados vizinho inclui um registro. O portal local e o portal vizinho associam cada um o par de banco de dados ao enlace de destino. O portal local pode então controlar a sincronização de banco de dados de solicitante local com o banco de dados de registro vizinho por meio do enlace de destino. O controle da sincronização do banco de dados de solicitante local com o banco de dados de registro vizinho inclui a transmissão de informações de registro ao banco de dados vizinho por meio do enlace de destino nas mensagens LRPDU, conforme discutido abaixo. Deve-se observar que as mensagens LRPDU podem sempre ser encaminhadas por meio do enlace de destino para garantir que essas mensagens cheguem ao portal apropriado.

[0073] Uma vez que a troca de mensagens LRPDU de olá ocorreu e os bancos de dados foram configurados, o aplicativo pode fazer uma alteração de registro 405 no banco de dados de solicitante através do portal local. A mudança de registro 405 inclui a atualização de pelo menos um bit de dados em um registro correspondente. Quando um registro é atualizado, um número de sequência é alterado (por exemplo, incrementado) em um cabeçalho de registro correspondente para denotar a alteração. O registro afetado pela mudança de registro 405 também pode ser marcado como não reconhecido empregando um sinalizador no banco de dados de solicitante para indicar que o registro não está ciente da mudança.

[0074] O portal local pode transmitir uma mensagem LRPDU de registro 407 para um banco de dados de registro em um nó vizinho através do portal vizinho. A mensagem LRPDU de registro 407 indica as atualizações do registro armazenado em um banco de dados de solicitante. Especificamente, a mensagem LRPDU de registro 407 contém os cabeçalhos de registro para os registros atualizados no banco de dados de solicitante pela mudança de registro 405. Esses cabeçalhos de registro incluem um número de registro e um número de sequência para cada registro atualizado. Em alguns exemplos, a mensagem LRPDU de registro 407 também contém os registros atualizados. Em outros exemplos, os registros atualizados são transferidos do solicitante para o registro por meio de uma comunicação separada e/ou por meio de um protocolo separado, como TCP e/ou LRP-DT. Deve-se observar que o portal local pode continuar a enviar mensagens LRPDU de registro adicionais à medida que os registros são atualizados sem aguardar reconhecimentos.

[0075] O portal vizinho e, portanto, o registro, recebe a mensagem LRPDU de registro 407 e atualiza o banco de dados de registro com os cabeçalhos e/ou registros incluídos. O portal vizinho pode então gerar uma mensagem LRPDU de lista parcial 409 em nome do registro. A mensagem LRPDU de lista parcial 409 serve como um reconhecimento da mensagem LRPDU de registro 407. A mensagem LRPDU de lista parcial 409 contém os cabeçalhos de registro contidos na mensagem LRPDU de registro 407 e, portanto, indica que o registro está ciente e/ou recebeu as atualizações desses registros, dependendo do exemplo. O portal vizinho transmite a mensagem LRPDU de lista parcial 409 para o banco de dados de solicitante. A mensagem LRPDU de lista parcial 409, reconhecendo a mensagem LRPDU de registro 407, é recebida no portal local. O portal local pode então marcar os registros atualizados no banco de dados de solicitante como reconhecidos pelo banco de dados de registro, empregando um sinalizador.

[0076] Conforme observado acima, um portal local pode enviar mais mensagens LRPDU de registro 407 sem aguardar as mensagens LRPDU de lista parcial correspondentes 409.

Portanto, várias atualizações de registro podem permanecer não reconhecidas, mesmo quando mensagens LRPDU de lista parcial específicas 409 foram recebidas. No entanto, em alguns casos, todas as mensagens LRPDU de lista parcial 409 podem ser recebidas para todas as mensagens LRPDU de registro 407 correspondentes, por exemplo, devido a uma pausa nas atualizações para o solicitante. Quando isso ocorre, o banco de dados de solicitante e o banco de dados de registro são sincronizados. O portal local pode verificar o estado de reconhecimento dos registros no banco de dados de solicitante cada vez que uma mensagem LRPDU de lista parcial 409 for recebida. Portanto, quando os bancos de dados são sincronizados, o portal local pode determinar que todos os registros atualizados no banco de dados de solicitante foram reconhecidos pelo banco de dados de registro por meio das mensagens LRPDU. Com base na determinação de que todos os registros atualizados no banco de dados de solicitante são reconhecidos pelo banco de dados de registro por meio de mensagens LRPDU, o portal local pode enviar um reconhecimento de todos os registros 411 para notificar o aplicativo de que o banco de dados de solicitante está sincronizado com o banco de dados de registro. O reconhecimento de todos os registros 411 pode ser uma indicação na forma de um código predeterminado enviado ao aplicativo para verificar a sincronização.

[0077] Opcionalmente, o portal local pode ser configurado para manter um temporizador para cada mensagem LRPDU de registro 407. Nesse caso, o portal local pode gerar uma notificação de falha 412 para o aplicativo quando um temporizador de mensagem LRPDU de registro 407 expira sem receber uma mensagem LRPDU de lista parcial correspondente

409. A mensagem LRPDU de registro 407 não reconhecida não pode ser reenviada automaticamente pelo portal local. O portal vizinho e/ou a porta de destino correspondente podem incluir um buffer de recepção limitado. A retransmissão automática pode resultar em saturações de buffer devido a outras mensagem LRPDU de registro 407. Consequentemente, o aplicativo pode determinar como proceder, por exemplo, reenviando a mensagem LRPDU de registro 407 não reconhecida, aguardando mais, revertendo a atualização de registro correspondente para o banco de dados de solicitante, etc.

[0078] O portal vizinho transmite mensagens LRPDU de lista completa 413 em nome do registro. As mensagens LRPDU de lista completa 413 incluem cabeçalhos de registro para todos os registros no banco de dados de registro (mas não os próprios registros). As mensagens LRPDU de lista completa 413 podem ser transmitidas periodicamente e recebidas pelo solicitante através do portal local. Uma mensagem LRPDU de lista completa 413 pode servir como um reconhecimento de uma ou mais mensagens LRPDU de registro enviadas anteriormente 407, por exemplo, no caso de uma mensagem de LRPDU de Lista Parcial 409 não ser recebida pelo solicitante/portal local. Além disso, uma mensagem LRPDU de lista completa 413 também pode ser usada pelo solicitante para determinar quando uma mensagem LRPDU de registro 407 não foi recebida pelo registro. Por exemplo, o solicitante pode comparar os cabeçalhos de registro na mensagens LRPDU de lista completa 413 com os cabeçalhos de registro no banco de dados de solicitante. Quando os cabeçalhos de registro no banco de dados de solicitante correspondem aos cabeçalhos de registro na mensagens LRPDU de lista completa 413, o solicitante pode determinar que todas as atualizações de registro foram recebidas pelo registro e enviar um reconhecimento de todos os registros 411. Quando os cabeçalhos de registro no banco de dados de solicitante não correspondem aos cabeçalhos de registro na mensagens LRPDU de lista completa 413, o solicitante pode determinar que determinadas atualizações de registros não foram recebidas no registro e retransmiti-las.

[0079] O método 400 também gerencia outros casos. Por exemplo, uma interrupção de conexão 415 pode ocorrer. Uma interrupção de conexão 415 pode resultar da falha de um nó ou enlace entre as portas de destino para o portal local e portal vizinho. Uma interrupção de conexão 415 também pode ocorrer devido ao congestionamento de tráfego de dados. As mensagens LRPDU de olá, como as mensagens LRPDU de olá 401 e 403, são trocadas periodicamente e os portais ficam cientes da interrupção de conexão 415 quando essa troca falha. Quando a troca de mensagens de olá falha, o portal local gera um código desconectado 416 para o aplicativo. O código desconectado 416 indica ao aplicativo que uma troca de mensagens LRPDU de olá falhou e uma interrupção de conexão 415 ocorreu. O solicitante pode então determinar uma ação a ser tomada em resposta à interrupção de conexão 415. Por exemplo, o aplicativo pode decidir redefinir o par de banco de dados ao restabelecer a conexão; nesse caso, o método 400 é reiniciado assim que as mensagens LRPDU de olá 401 e 403 são trocadas.

[0080] Como outro exemplo, o aplicativo pode decidir manter o par de banco de dados e restabelecer a conexão. Quando bem-sucedida, essa abordagem evita a necessidade de reenviar todos os registros de banco de dados de solicitante ao banco de dados de registro. O aplicativo pode enviar um comando de manutenção de banco de dados 417 para o portal local. Portanto, o portal local pode receber o comando de manutenção do banco de dados 417 do aplicativo para manter o banco de dados de solicitante na memória no nó local, apesar do código desconectado 416. Quando o portal local recebe um comando para manter o par de banco de dados, o portal local cessa de enviar mensagens LRPDU de registro 407 até que uma mensagem LRPDU de lista completa 418 seja recebida do banco de dados de registro por meio do portal vizinho. Por exemplo, o portal local pode redefinir temporizadores de notificação no banco de dados de solicitante após uma troca malsucedida de mensagens LRPDU de olá (por exemplo, uma interrupção de conexão 415) para evitar a transmissão de mensagens LRPDU de registro até que a mensagem LRPDU de lista completa 418 seja recebida.

[0081] O portal vizinho realiza um processo semelhante com um aplicativo no nó vizinho. Após uma troca bem-sucedida de mensagens LRPDU de olá, o registro, por meio do portal vizinho, envia a mensagem LRPDU de lista completa

418. A mensagem LRPDU de lista completa 418 é substancialmente semelhante às mensagens LRPDU de lista completa 413 e, portanto, contém todos os cabeçalhos de registro do banco de dados de registro. Se qualquer um dos aplicativos no nó local ou no nó remoto optar por redefinir o par de banco de dados, o método 400 será reiniciado. Por exemplo, se o portal vizinho zera o banco de dados de registro e o portal local não zera o banco de dados de solicitante, a mensagem LRPDU de lista completa 418 está vazia e o solicitante reenvia todos os registros. Como outro exemplo, se o portal vizinho não redefinir o banco de dados de registro e o portal local redefinir o banco de dados de solicitante, a mensagem LRPDU de lista completa 418 contém cabeçalhos de registro que não correspondem ao banco de dados de solicitante e o par de banco de dados é redefinido. No entanto, se ambos os aplicativos optarem por manter o par de banco de dados, a mensagem LRPDU de lista completa 418 contém cabeçalhos de registro que são iguais ou semelhantes (por exemplo, devido a mensagens LRPDU de registro perdidas 407) aos cabeçalhos de registro no banco de dados de solicitante. Nesse caso, o solicitante pode determinar as etapas necessárias para recuperar a sincronização entre o par de banco de dados.

[0082] Consequentemente, o portal local pode receber a mensagem LRPDU de lista completa 418 do banco de dados de registro no nó vizinho após uma troca bem-sucedida de mensagens de olá. A mensagem LRPDU de lista completa 418 inclui cabeçalhos de registro para todos os registros no banco de dados de registro. O portal local e/ou banco de dados de solicitante pode então comparar os cabeçalhos de registro da mensagem LRPDU de lista completa 418 com os cabeçalhos de registro no banco de dados de solicitante para ressincronizar o banco de dados de solicitante com o banco de dados de registro. Em um primeiro caso, o portal local pode determinar que não há incompatibilidade entre os cabeçalhos de registro no banco de dados de solicitante e os cabeçalhos de registro do banco de dados de registro, conforme incluído na mensagem LRPDU de lista completa 418. Nesse caso, o par de banco de dados é sincronizado. Como tal, com base na determinação de não incompatibilidade, o portal pode notificar o aplicativo que o banco de dados de solicitante está sincronizado com o banco de dados de registro, por exemplo, enviando um reconhecimento de todos os registros 411. Em um segundo caso, o portal local pode determinar uma incompatibilidade entre um ou mais cabeçalhos de registro no banco de dados de solicitante e um ou mais cabeçalhos de registro da mensagem LRPDU de lista completa

418. Isso pode ocorrer se uma mensagem LRPDU de registro 407 for perdida durante a interrupção de conexão 415. O portal pode comparar os cabeçalhos de registro para determinar quais registros não foram enviados ao banco de dados de registro. O portal local pode então transmitir uma mensagem LRPDU de registro 407 para o banco de dados de registro por meio do portal vizinho. A mensagem LRPDU de registro 407 contém cabeçalhos de registro atualizados conforme desejado para resolver a incompatibilidade. Em qualquer caso, o par de banco de dados é sincronizado sem redefinir o par de banco de dados e reenviar todos os registros no banco de dados de solicitante.

[0083] Opcionalmente, o portal local também pode solicitar, em nome do solicitante, uma mensagem LRPDU de lista completa 421. Isso permite que o solicitante verifique a sincronização de banco de dados sob demanda. Nesse caso, o portal local transmite uma mensagem LRPDU de lista completa de solicitação 419 para o banco de dados de registro por meio do portal vizinho. O portal vizinho e/ou registro recebe a mensagem LRPDU de lista completa de solicitação 419 e transmite a mensagem LRPDU de lista completa 421 para o solicitante através do portal local. A mensagem LRPDU de lista completa 421 é substancialmente semelhante à mensagem LRPDU de lista completa 418 e 413. O portal local e, portanto, o solicitante, podem receber a mensagem LRPDU de lista completa 421 do banco de dados de registro em resposta à mensagem LRPDU de lista completa de solicitação 419. Como tal, o solicitante pode comparar os cabeçalhos de registro da mensagem LRPDU de lista completa 421 com os cabeçalhos de registro no banco de dados de solicitante para determinar se o par de banco de dados está sincronizado e/ou determinar quais registros devem ser enviados ao registro para sincronizar o par de banco de dados.

[0084] Deve-se notar que as mensagens e notificações de LRPDU do método 400 são ilustradas a fim de descrever várias funcionalidades de exemplo da presente divulgação. Essas mensagens/notificações podem ser usadas em várias combinações. Por exemplo, a troca olá de mensagens LRPDU de olá 401 e 403, bem como as mensagens LRPDU de lista completa 413, 418 e 421 podem ocorrer periodicamente com base em temporizadores predefinidos, bem como com base em eventos de disparo, conforme discutido acima. Além disso, a Mudança de Registro 405 com a mensagem LRPDU de registro 407 resultante e a mensagem de LRPDU de Lista Parcial 409 podem ocorrer repetidamente durante a operação normal de um banco de dados de solicitante com ou sem ações intermediárias. Além disso, o reconhecimento de todos os registros 411, notificação de falha 412, código desconectado 416 e comando de manutenção de banco de dados 417 podem ser acionados sempre que ocorrer uma circunstância correspondente. Como tal, a ordem das mensagens e notificações LRPDU na FIG. 4 é exemplar e não deve ser considerado limitante, a menos que especificado de outra forma neste documento.

[0085] Além disso, qualquer número de LRPDUs pode ser agrupado sucessivamente em uma única Unidade de Dados de Protocolo de Controle de Borda (ECPDU) LRP-DT, até o tamanho máximo do quadro de duas camadas. Um único LRPDU não pode ser dividido em vários ECPDUs LRP-DT ECP. Ao usar TCP, o tamanho de um LRPDU pode ser limitado por um campo de comprimento de dezesseis bits.

[0086] A FIG. 5 ilustra um exemplo de codificação de uma mensagem LRPDU de olá 500, que pode implementar uma mensagem LRPDU de olá 401 e/ou 403. Como tal, a mensagem LRPDU de olá 500 pode ser empregada para manter a sincronização do par de banco de dados em um sistema nativo 110 e/ou 130, um proxy 210 e/ou 230, um escravo 240 e/ou 250 e/ou um sistema de banco de dados 300.

[0087] A mensagem LRPDU de olá 500 é codificada em um formato TLV. Por exemplo, o formato TLV empregado neste documento pode suportar campos de dados de até sessenta e cinco mil quinhentos e trinta e cinco octetos. A mensagem LRPDU de olá 500 contém um campo Tipo 501. O campo Tipo 501 inclui um comprimento de um octeto e um deslocamento de octeto zero. O campo Tipo 501 pode ser definido para um valor de um para indicar uma mensagem LRPDU de olá 500. A mensagem LRPDU de olá 500 também contém um campo Comprimento 503. O campo Comprimento 503 inclui um comprimento de dois octetos e um deslocamento de um octeto. O campo Comprimento 503 pode conter um número inteiro de dois octetos, com os oito bits mais significativos no primeiro octeto (deslocamento 1), que contém o comprimento do campo de dados (por exemplo, o restante da mensagem). Assim, um campo Comprimento TLV 503 de zero indica que nenhum campo de dados está presente. O campo Comprimento 503 da mensagem LRPDU de olá 500, (octetos um e dois, seguindo o campo tipo) contém o comprimento de todos os campos de comprimento fixo mais todos os TLVs no campo de dados.

[0088] Os dados restantes incluem um comprimento de zero a sessenta e cinco mil quinhentos e trinta e cinco octetos com um deslocamento de três octetos no primeiro campo de dados. O campo de dados da mensagem LRPDU de olá 500 contém informações transmitidas por uma única instância de uma máquina de estado Enviar olá em um solicitante, registro e/ou portal correspondente. A mensagem LRPDU de olá 500 contém alguns campos de tamanho fixo, seguidos por uma série de TLVs dentro do campo de dados. Ou seja, o décimo octeto após o campo Comprimento TLV 503 pode ser outro campo tipo LRPDU.

[0089] A mensagem LRPDU de olá 500 também contém um campo AppId 505. O campo AppId 505 inclui um AppId que identifica o aplicativo associado ao Portal de transmissão. O campo AppId 505 inclui um Identificador Organizacionalmente Único (OUI) ou Identificador de Empresa (CID) com um comprimento de três octetos e um Sub-ID de aplicativo com um comprimento de um octeto e um deslocamento de três octetos para um total de quatro octetos. Deve-se observar que o proprietário do OUI ou CID é responsável por gerenciar o uso do Sub-ID de Aplicativo. Também deve ser observado que o AppId é usado em vários contextos, incluindo em variáveis de máquina de estado, e não apenas em uma mensagem LRPDU de olá 500.

[0090] A mensagem LRPDU de olá 500 também contém um campo estado de olá 507. O campo estado de olá 507 é um campo enumerado de quatro bits, nos bits mais significativos do octeto, contendo um dos seguintes valores: verificando estado de olá (hsLooking), conectando estado de olá (hsConnecting) e estado de olá conectado (hsConnected). Um valor hsLooking pode ser definido para indicar que um portal correspondente ainda não recebeu uma solicitação de criação de portal completa com êxito. Um valor hsConnecting pode ser definido para indicar que um portal correspondente recebeu uma solicitação de criação de Portal Completa bem-sucedida e uma mensagem LRPDU de olá 500 com o estado hsLooking. Nesse caso, o Portal está pronto para receber todos os LRPDUs. Um valor hsConnected pode ser definido para indicar que um portal correspondente está ativo e pronto para transferir dados do aplicativo. Nesse caso, o Portal tem permissão para transmitir todos os LRPDUs. O campo estado de olá 507 também pode conter um campo Estado de Erro 508. O campo Estado de Erro 508 pode incluir quatro bits de informação nos bits menos significativos do octeto e pode indicar erros, como um excesso de banco de dados.

[0091] A mensagem LRPDU de olá 500 também contém um campo Meu Número de Portal 509. O campo Meu Número de Portal 509 contém um número de quatro octetos que identifica o Portal de transmissão. O número de identificação é único em todos os Portais que compartilham a mesma instância LRP-DT. Este campo tem quatro octetos de comprimento porque um sistema proxy pode ser proxy para qualquer número de sistemas escravos, cada um dos quais pode ter um grande número de portas de destino. Além disso, um sistema proxy pode fazer uma conexão TCP com outro sistema proxy semelhante. Cada sistema proxy emprega um valor de Meu Número de Portal para cada uma das portas de destino para as quais o sistema proxy está fazendo proxy. O campo Meu Número de Portal 509 é usado em outras mensagens LRPDU para identificar com qual par de portas de destino 141, 151, 241 e 251 e, portanto, portal 113, 133, 213 e 233 e, finalmente, com qual banco de dados 120, 122, 220 e 222, um determinado LRPDU de registro, LRPDU de Lista Parcial, LRPDU de lista completa ou LRPDU de lista completa de solicitação está associado.

[0092] A mensagem LRPDU de olá 500 também contém um campo tempo de olá 511. O campo tempo de olá 511 inclui dois octetos que representam o tempo de vida da mensagem LRPDU de olá 500. O primeiro octeto do campo tempo de olá 511 é o octeto mais significativo de um número de segundos de dezesseis bits (zero a sessenta e cinco mil quinhentos e trinta e cinco ou trinta a sessenta e cinco mil quinhentos e trinta e cinco) que a mensagem LRPDU de olá 500 é válido. Este campo não pode ser transmitido com um valor entre um e vinte e nove, inclusive.

[0093] Os primeiros quatro TLVs na mensagem LRPDU de olá 500 são um de cada ID de Meu Chassi TLV 513, ID de Minha Porta TLV 515, ID de Chassi Vizinho TLV 517 e ID de Porta Vizinha TLV 519, em qualquer ordem. Em seguida, vem zero ou um TLV de Informações de Aplicação 521.

[0094] O campo tipo de ID de Meu Chassi TLV 513 é definido com um valor para typeMyChassisId. O campo de dados do Meu Chassi ID TLV 513 contém um valor especificado para transmissão no ID de Chassi LLDP TLV pela instância LLDP nomeada na solicitação de criação do Portal Completo que criou o Portal transmitindo o ID de Meu Chassi TLV 513.

Especificamente, o ID de Meu Chassi TLV 513 contém um valor que identifica o nó local (por exemplo, a máquina) agindo como um remetente para a mensagem LRPDU de olá 500. Esse nó local contém o sistema nativo ou um sistema escravo usado para configurar e/ou manter um par de banco de dados (por exemplo, contendo ou acoplado a um registro local, um solicitante local ou ambos).

[0095] O campo tipo de ID de Minha Porta TLV 515 é definido como um valor para typeMyPortId. O campo de dados do ID de Minha Porta TLV 515 contém o mesmo valor que foi especificado para transmissão no ID de Porta LLDP TLV pela instância LLDP nomeada na solicitação de criação de portal completo que criou o portal transmitindo o ID de Minha Porta TLV 515. Especificamente, o ID de Minha Porta TLV 515 contém um valor que identifica uma porta de destino no nó local que tenta configurar e/ou manter um par de banco de dados (por exemplo, o sistema nativo ou escravo). O ID de Minha Porta e o ID de porta juntos representam exclusivamente a metade local do enlace de destino para a comunicação de mensagens LRPDU.

[0096] O campo tipo do ID de Chassi Vizinho TLV 517 é definido com um valor para typeNeighborChassisId. O campo de dados do ID de Chassi Vizinho TLV 517 está no mesmo formato que a ID de meu chassi TLV 513 e contém a ID de chassi do portal vizinho ao qual o portal local está associado. Especificamente, o ID de Chassi Vizinho TLV 517 contém um valor que identifica o nó vizinho (por exemplo, a máquina) atuando como um destino para a mensagem LRPDU de olá 500. O nó vizinho contém o sistema nativo ou um sistema escravo usado para configurar e/ou manter um par de banco de dados (por exemplo, contendo ou acoplado a um registro vizinho, um solicitante vizinho ou ambos).

[0097] O campo tipo do ID de Porta Vizinha TLV 519 é definido com um valor para typeNeighborPortId. O campo de dados do ID de Porta Vizinha TLV 519 está no mesmo formato que o ID de Minha Porta TLV 515 e contém o ID de Porta do portal vizinho ao qual o portal local está associado. Especificamente, a porta do vizinho ID TLV 519 contém um valor que identifica uma porta de destino no nó vizinho usado para configurar e/ou manter um par de banco de dados (por exemplo, o sistema nativo ou escravo). O ID de Chassi Vizinho e o ID de Porta Vizinha juntos representam de maneira exclusiva a metade vizinha do enlace de destino para comunicação de mensagens LRPDU. Portanto, o LRPDU de olá 500 representa o enlace de destino como um ID de Meu Chassi identificando o nó local, um ID de Minha Porta que identifica uma porta de destino no nó local, um ID de Chassi Vizinho que identifica o nó vizinho e um ID de Porta Vizinha que identifica uma porta de destino no nó vizinho.

[0098] O TLV de Informação de Aplicativo 521 é definido com um valor para typeAppInfo. O campo de dados da Informação de Aplicação TLV 521 contém informações fornecidas por uma solicitação de ativação de criação de portal. Os dados são apresentados ao aplicativo no destino por meio de uma indicação de estado do portal na extremidade de destino de uma conexão LRP-DT. Os dados podem ser opacos e não interpretados pelo LRP. As Informações de Aplicação TLV 521 são opcionais.

[0099] Consequentemente, o campo tipo 501 é um octeto com um deslocamento de octeto zero, o campo comprimento 503 é dois octetos com um deslocamento de um octeto, o campo AppId 505 é quatro octetos com um deslocamento de três octetos, o campo estado de olá 507 é um octeto com um deslocamento de sete octetos, o campo Meu Número de Portal 509 é quatro octetos com um deslocamento de oito octetos, o campo tempo de olá 511 é dois octetos com um deslocamento de doze octetos e os restantes TLVs 513-521 são de comprimentos variáveis com um deslocamento inicial de quatorze octetos.

[00100] A FIG. 6 ilustra um exemplo de codificação de uma mensagem LRPDU de registro 600, que pode implementar uma mensagem LRPDU de registro 407. Como tal, a mensagem LRPDU de registro 600 pode ser empregada para manter a sincronização do par de banco de dados em um sistema nativo 110 e/ou 130, um proxy 210 e/ou 230, um escravo 240 e/ou 250 e/ou um sistema de banco de dados 300. A mensagem LRPDU de registro 600 contém um campo Tipo 601 e um campo Comprimento 603, que são semelhantes ao campo Tipo 501 e campo Comprimento 503, respectivamente. O campo Tipo 601 pode conter um valor de dois para indicar uma mensagem LRPDU de registro 600 (por exemplo, typeRecordLRPDU), e o campo Comprimento 603 contém o comprimento da mensagem LRPDU de registro 600. Os primeiros dois octetos de um campo de dados da mensagem LRPDU de registro 600 é um campo Meu Número de Portal 609 que codifica o ID de Minha Porta, ID de porta e appId do Portal de transmissão. Este é o mesmo valor transmitido na mensagem LRPDU de olá 500 para o mesmo portal. Em seguida, estão zero ou mais registros em um campo Registro 630.

[00101] Cada registro inclui um campo Número de Registro 631, um campo Número de Sequência 633, um campo Soma de Verificação 635 e, opcionalmente, um campo Comprimento de

Dados 637 e um campo Dados de Aplicativo 639. O campo Número de Registro 631 contém dados que indicam um registro em um banco de dados de solicitante que foi atualizado. O campo Número de Sequência 633 contém dados que indicam um número de versão e/ou número de alterações associadas ao registro correspondente. O campo Soma de Verificação 635 inclui dados de correção de erro, como um valor de dois octetos calculado com base nos valores incluídos no registro correspondente (por exemplo, valores no campo Número de Registro 631, campo Número de Sequência 633, campo Comprimento de Dados 637 e/ou Campo de Dados de Aplicativo 639). O campo Comprimento de Dados 637, quando presente, indica o comprimento dos dados no registro correspondente e/ou o comprimento do Campo Dados de Aplicativo 639. O Campo Dados de Aplicativo 639, quando presente, contém o registro atualizado em transmissão do banco de dados de solicitante para o banco de dados de registro.

[00102] Por conseguinte, a mensagem LRPDU de registro 600 pode incluir um ou mais números de registro indicando registros atualizados no banco de dados de solicitante e um ou mais números de sequência que identificam as atualizações incluídas nos registros atualizados no banco de dados de solicitante. Além disso, o campo Tipo 601 é um octeto com um deslocamento de zero octeto, o campo Comprimento 603 é dois octetos com um deslocamento de um octeto, o campo Meu Número de Portal 609 é quatro octetos com um deslocamento de três octetos, e o campo Registro 630 é de comprimento variável com um deslocamento de sete octetos. Além disso, cada registro contém um campo Número de Registro 631 de quatro octetos com um deslocamento de zero octetos, um campo Número de Sequência

633 de quatro octetos com um deslocamento de quatro octetos, um campo Soma de Verificação 635 de dois octetos com um deslocamento de oito octetos, um campo Comprimento de Dados 637 de dois octetos com um deslocamento de dez octetos e um campo Dados de Aplicativos 639 de zero a sessenta e cinco mil quinhentos e vinte octetos com um deslocamento de doze octetos, onde os deslocamentos de registro são medidos a partir do início do registro.

[00103] A FIG. 7 ilustra um exemplo de codificação de uma mensagem LRPDU de lista parcial 700, que pode implementar uma mensagem LRPDU de lista parcial 409. Como tal, a mensagem LRPDU de lista parcial 700 pode ser empregada para manter a sincronização do par de banco de dados em um sistema nativo 110 e/ou 130, um proxy 210 e/ou 230, um escravo 240 e/ou 250 e/ou um sistema de banco de dados 300. A mensagem LRPDU de lista parcial 700 contém um campo Tipo 701 e um campo Comprimento 703, que são semelhantes ao campo Tipo 501 e campo Comprimento 503, respectivamente. O campo Tipo 701 pode conter um valor de três para indicar uma mensagem LRPDU de lista parcial 700 (por exemplo, typePartialListLRPDU), e o campo Comprimento 703 contém o comprimento da mensagem LRPDU de lista parcial 700.

[00104] Os primeiros dois octetos de um campo de dados da mensagem LRPDU de lista parcial 700 é um campo Meu Número de Portal 709 que codifica o ID de Chassi, ID de porta e appId do Portal de transmissão. Este é o mesmo valor transmitido na mensagem LRPDU de olá 500 para o mesmo Portal. Depois disso, há zero ou mais Cabeçalhos de Registro 730, que são substancialmente semelhantes aos Registros 630, mas não contêm dados de registro. Especificamente, cada Cabeçalho de

Registro 730 contém um campo Número de Registro 731, um campo Número de Sequência 733 e um campo Soma de Verificação 735, que são substancialmente semelhantes ao campo Número de Registro 631, o campo Número de Sequência 633 e o campo Soma de Verificação 635, respectivamente. Além disso, o campo Número do Registro 731 e o campo Número de Sequência 733 incluem valores que são adicionados pelo registro que combina os valores correspondentes dos Registros 630 correspondentes na mensagem LRPDU de registro 600 (por exemplo, conforme incluído na mensagem LRPDU de registro 600 pelo solicitante). Portanto, os Cabeçalhos de Registro 730 reconhecem o recebimento dos registros 630.

[00105] Portanto, a mensagem LRPDU de lista parcial 700 reconhecendo a mensagem LRPDU de registro 600 e a mensagem LRPDU de lista parcial 700 inclui pelo menos um Cabeçalho de Registro 730 reconhecendo pelo menos um registro atualizado 630. Além disso, o Cabeçalho do Registro 730 inclui um número de registro em um campo Número de Registro 731 indicando o registro atualizado (por exemplo, Registro 630) e um número de sequência em um campo Número de Sequência 733 identificando uma atualização incluída no registro atualizado (por exemplo, Registro 630).

[00106] A FIG. 8 ilustra um exemplo de codificação de uma mensagem LRPDU de lista completa 800, que pode implementar uma mensagem LRPDU de lista completa 413, 418 e/ou 421. Como tal, a mensagem LRPDU de lista completa 800 pode ser empregada para manter a sincronização do par de banco de dados em um sistema nativo 110 e/ou 130, um proxy 210 e/ou 230, um escravo 240 e/ou 250 e/ou um sistema de banco de dados 300. A mensagem LRPDU de lista completa 800 contém um campo Tipo 801 e um campo Comprimento 803, que são semelhantes ao campo Tipo 501 e campo Comprimento 503, respectivamente. O campo Tipo 801 pode conter um valor de quatro para indicar uma mensagem LRPDU de lista completa 800 (por exemplo, typeCompleteListLRPDU), e o campo Comprimento 803 contém o comprimento da mensagem LRPDU de lista completa 800.

[00107] Os primeiros dois octetos de um campo de dados de mensagem LRPDU de lista completa 800 são um campo Meu número de Portal 809 que codifica o ID de Minha Porta, ID de porta e appId do Portal de transmissão. Este é o mesmo valor transmitido na mensagem LRPDU de olá 500s para o mesmo Portal. Em seguida estão um campo Primeiro Número de Registro 823 e um campo Último Número de Registro 825, cada um com quatro octetos de comprimento e inclui o valor de número de registro mais baixo e o valor de número de registro mais alto, respectivamente, que são abrangidos por esta mensagem LRPDU de lista completa 800. Por exemplo, o campo Primeiro Número de Registro 823 e o campo Último Número de Registro 825 contêm o primeiro e o último registro, respectivamente, armazenados no registro.

[00108] Em seguida, estão zero ou mais Cabeçalhos de Registro 830, que são substancialmente semelhantes aos Cabeçalhos de Registro 730. No entanto, os Cabeçalhos de Registro 830 contêm todos os cabeçalhos de registro no banco de dados de registro, em oposição a apenas os cabeçalhos de registro dos registros atualizados reconhecidos. Cada Cabeçalho de Registro 830 contém um campo Número de Registro 831, um campo Número de Sequência 833 e um campo Soma de Verificação 835, que são substancialmente semelhantes ao campo Número de Registro 731, campo Número de Sequência 733 e campo Soma de Verificação 735, respectivamente.

[00109] Cada Número de Registro 831 transmitido em uma mensagem LRPDU de lista completa 800 contém um valor maior ou igual ao valor no campo Primeiro Número de Registro 823 e menor ou igual ao valor no campo Último Número de Registro 825. O campo Primeiro Número de Registro 823 e o campo Último Número de Registro 825 permitem que a lista completa de registros conhecidos por um registro seja dividida entre mais de uma mensagem LRPDU de lista completa

800. Os pares do primeiro e do último número de registro em todas as mensagens LRPDU de lista completa 800 compreendem uma lista completa de registros que pode abranger todos os números de registro possíveis de zero a quatro bilhões duzentos e noventa e quatro milhões novecentos e sessenta sete mil duzentos e noventa e cinco.

[00110] A FIG. 9 é um fluxograma de um método de exemplo 900 de estabelecimento de um par de banco de dados, por exemplo, em um sistema nativo 110 e/ou 130, um proxy 210 e/ou 230, um escravo 240 e/ou 250 e/ou um sistema de banco de dados 300. O método 900 emprega sinalização do método 400, como mensagens LRPDU de olá 401, 403 e/ou 500. O método 900 é discutido da perspectiva de um nó local operando um banco de dados de solicitantes para maior clareza da discussão, mas também pode ser operado no todo ou em parte em um nó operando um registro (por exemplo, nó local ou nó vizinho).

[00111] O método 900 começa quando um nó local deseja estabelecer um par de banco de dados para sincronização com um nó vizinho. No bloco 901, uma mensagem de olá é recebida no nó local. A mensagem de olá inclui um AppId e um enlace de destino entre uma porta de destino para o nó local e a porta de destino para um nó vizinho. Quando o nó local é um sistema nativo, a porta de destino é posicionada no nó local. Quando o nó local é um proxy, a porta de destino é posicionada em um escravo. A mensagem de olá pode ser uma mensagem LRPDU de olá, como as mensagens LRPDU de olá 401, 403 e/ou 500. Além disso, a mensagem LRPDU de olá pode representar o enlace de destino como um ID de Meu Chassi identificando o nó local ou um nó escravo correspondente, um ID de Minha Porta identificando uma porta de destino no nó local ou um nó escravo correspondente, um ID de Vizinho Chassi identificando o nó vizinho ou um nó escravo correspondente e um ID de Porta Vizinha que identifica uma porta de destino no nó vizinho ou um nó escravo correspondente. Para concluir uma troca de olá, uma mensagem de olá correspondente também é enviada do nó local para o nó vizinho. Essa mensagem de olá pode ser substancialmente semelhante à mensagem de olá recebida no nó local com um Meu Número Portal diferente. Por exemplo, a mensagem de olá enviada do nó local contém um Meu Número de Portal associado ao nó local e a mensagem de olá recebida no nó local contém um Meu Número de Portal associado ao nó vizinho. Essas mensagens podem ser enviadas em qualquer ordem.

[00112] No bloco 903, o nó local e/ou um portal correspondente determina que o AppId está associado a um aplicativo para realizar a sincronização de banco de dados. Com base na determinação de que o AppId está associado à sincronização de banco de dados, um banco de dados local é configurado na memória no nó local no bloco 905. O banco de dados local faz parte de um par de bancos de dados para uso do aplicativo. O par de banco de dados inclui uma configuração de banco de dados vizinho no nó vizinho (por exemplo, por um portal no nó vizinho). Em alguns exemplos, o banco de dados local pode incluir um banco de dados de solicitante para armazenar registros locais para transmissão a um banco de dados de registro no banco de dados vizinho. Em alguns exemplos, o banco de dados local inclui um banco de dados de registros para receber registros vizinhos de um banco de dados de solicitante no banco de dados vizinho. Em alguns exemplos, o banco de dados local inclui um banco de dados de solicitante e um banco de dados de registros.

[00113] No bloco 907, o par de banco de dados está associado ao enlace de destino (por exemplo, em um sistema nativo e/ou em um escravo de um proxy). Tal associação garante que as mensagens LRPDU encaminhadas para o solicitante/registro cheguem ao portal correto, seja porque o portal está no nó local com a porta de destino ou porque a porta de destino está em um escravo configurado para encaminhar tais mensagens para um proxy que contém o portal e operando no nó local.

[00114] No bloco 909, o nó local/portal começa a controlar/gerenciar a sincronização de banco de dados local com o banco de dados vizinho através do enlace de destino. Esse controle pode ocorrer pela transmissão de informações de registro para o banco de dados vizinho por meio do enlace de destino em mensagens LRPDU. Essas informações de registro podem incluir registros, cabeçalhos de registro ou combinações dos mesmos. Por exemplo, essas mensagens LRPDU podem incluir outras mensagens LRPDU de olá 500, mensagens LRPDU de registro 600, mensagens LRPDU de lista parcial 700, mensagens LRPDU de lista completa 800 e/ou qualquer mensagem

LRPDU do método 400.

[00115] A FIG. 10 é um fluxograma de um método de exemplo 1000 de gerenciamento de sincronização de par de banco de dados, por exemplo, após a conclusão do método 900. O método 1000 pode ser operado em um sistema nativo 110 e/ou 130, um proxy 210 e/ou 230, um escravo 240 e/ou 250 e/ou um sistema de banco de dados 300. O método 1000 emprega sinalização do método 400. Além disso, o método 1000 pode empregar mensagens LRPDU, tais como mensagens LRPDU de olá 500, mensagens LRPDU de registro 600, mensagens LRPDU de lista parcial 700, mensagens LRPDU de lista completa 800 e/ou combinações das mesmas. O método 1000 é discutido da perspectiva de um nó local operando um banco de dados de solicitantes para maior clareza da discussão, mas também pode ser operado no todo ou em parte em um nó operando um registro (por exemplo, nó local ou nó vizinho).

[00116] No bloco 1001, um aplicativo altera um ou mais registros em um banco de dados de solicitante. Consequentemente, um portal no nó local transmite uma ou mais mensagens LRPDU de registro para um banco de dados de registro em um nó vizinho, por exemplo, por meio de um portal vizinho. As mensagens LRPDU de registro indicam atualizações para registros armazenados em um banco de dados de solicitante no nó local e também podem incluir tais registros atualizados. Por exemplo, as mensagens LRPDU de registro pode incluir um ou mais números de registro indicando registros atualizados no banco de dados de solicitante e um ou mais números de sequência que identificam as atualizações incluídas nos registros atualizados no banco de dados de solicitante. Os registros atualizados também podem ser marcados como não reconhecidos no banco de dados de solicitante.

[00117] No bloco 1003, o portal recebe uma ou mais mensagens LRPDU reconhecendo as mensagens LRPDU de registro do bloco 1001. Em alguns exemplos, as mensagens LRPDU que reconhecem as mensagens LRPDU de registro incluem uma mensagem de LRPDU de Lista Parcial. A mensagem LRPDU de lista parcial inclui pelo menos um cabeçalho de registro reconhecendo o pelo menos um registro atualizado do bloco

1001. O pelo menos um cabeçalho de registro inclui um número de registro que indica o(s) registro(s) atualizado(s) do bloco 1001 e um número de sequência que identifica a(s) atualização(ões) incluída(s) no registro atualizado do bloco

1001. Em alguns exemplos, as mensagens LRPDU que reconhecem as mensagens LRPDU de registro podem incluir uma mensagem LRPDU de lista completa. A mensagem LRPDU de lista completa inclui cabeçalhos de registro para todos os registros no banco de dados de registro. Além disso, a mensagem LRPDU de lista completa inclui um primeiro campo de número de registro indicando o primeiro registro armazenado no banco de dados de registro e um campo de último número de registro indicando o último registro armazenado no banco de dados de registro. Além disso, os cabeçalhos de registro incluem números de registro indicando os registros armazenados no banco de dados de registro e números de sequência que identificam as atualizações incluídas nos registros armazenados no banco de dados de registro.

[00118] No bloco 1005, pelo menos um registro atualizado é marcado no banco de dados de solicitante como reconhecido pelo banco de dados de registro com base nos cabeçalhos de registro na(s) mensagem(ns) LRPDU de Lista

Parcial e/ou de Lista Completa do bloco 1003.

[00119] No bloco 1007, o portal/solicitante pode determinar que todos os registros atualizados no banco de dados de solicitante sejam reconhecidos pelo banco de dados de registro por meio de mensagens LRPDU. Com base na determinação do bloco 1007 de que todos os registros atualizados no banco de dados de solicitante são reconhecidos pelo banco de dados de registro por meio de mensagens LRPDU, o portal/solicitante notifica o aplicativo que o banco de dados de solicitante está sincronizado com o banco de dados de registro no bloco 1009.

[00120] Em alguns casos, uma mensagem LRPDU de registro pode não chegar ao registro e/ou uma mensagem LRPDU de lista parcial pode ser descartada no caminho de volta para o solicitante. Nesses casos, no bloco opcional 1011, o portal gera uma notificação de falha para o aplicativo quando um temporizador de mensagem LRPDU de registro expira sem receber uma mensagem de LRPDU de Lista Parcial correspondente.

[00121] O bloco 1013 também é opcional. Em alguns exemplos, o portal/solicitante pode ser configurado para transmitir uma mensagem LRPDU de lista completa de solicitação para o banco de dados de registro. O portal do registro/vizinho responde com uma mensagem LRPDU de lista completa. Assim, o portal/solicitante no nó local recebe uma mensagem LRPDU de lista completa do banco de dados de registro em resposta à mensagem LRPDU de lista completa de solicitação.

[00122] A FIG. 11 é um fluxograma de um método de exemplo 1100 de manutenção da sincronização de banco de dados apesar da interrupção de conexão, por exemplo, após o método 900 e durante/após o método 1000. O método 1100 pode ser operado em um sistema nativo 110 e/ou 130, um proxy 210 e/ou 230, um escravo 240 e/ou 250 e/ou um sistema de banco de dados

300. O método 1100 emprega sinalização do método 400. Além disso, o método 1100 pode empregar mensagens LRPDU, tais como mensagens LRPDU de olá 500, mensagens LRPDU de registro 600, mensagens LRPDU de lista parcial 700, mensagens LRPDU de lista completa 800 e/ou combinações das mesmas. O método 1100 é discutido da perspectiva de um nó local operando um banco de dados de solicitantes para maior clareza da discussão, mas também pode ser operado no todo ou em parte em um nó operando um registro (por exemplo, nó local ou nó vizinho).

[00123] O método 1100 começa quando uma troca de mensagens LRPDU de olá falha, o que indica uma interrupção de conexão. No bloco 1101, um código desconectado é gerado para o aplicativo. O código desconectado indica que a troca de mensagens LRPDU de olá falhou. Isso também indica que é improvável que outras mensagens para o nó/registro vizinho sejam recebidas e que as mensagens não reconhecidas anteriores podem não ter chegado ao registro.

[00124] O solicitante pode determinar redefinir o par de banco de dados após o restabelecimento de conexão. Nesse caso, o método 900 é empregado. No entanto, o solicitante também pode determinar a ressincronização de banco de dados de solicitantes atual com o banco de dados de registro quando a conexão for restabelecida. Nesse caso, no bloco 1103, o portal recebe um comando do aplicativo para manter o banco de dados de solicitante na memória no nó local, apesar do código desconectado.

[00125] No bloco 1105, o portal redefine os temporizadores de notificação no banco de dados de solicitante após a troca malsucedida de mensagens de olá. Isso evita a transmissão de mensagens LRPDU de registro até que uma mensagem LRPDU de lista completa seja recebida após o restabelecimento de conexão.

[00126] As mensagens LRPDU de olá podem ser enviadas periodicamente na tentativa de restabelecer a conexão. Quando o banco de dados de registro recebe uma mensagem LRPDU de olá após uma desconexão, o registro responde com uma mensagem LRPDU de lista completa. Consequentemente, no bloco 1107, uma mensagem LRPDU de lista completa de um banco de dados de registro no nó vizinho é recebida pelo solicitante/portal após uma troca bem-sucedida de mensagens LRPDU de olá. A mensagem LRPDU de lista completa inclui cabeçalhos de registro para todos os registros no banco de dados de registro.

[00127] No bloco 1109, o portal/solicitante compara os cabeçalhos de registro da mensagens LRPDU de lista completa com os cabeçalhos de registro armazenados no banco de dados de solicitante para ressincronizar o banco de dados de solicitante com o banco de dados de registro. Especificamente, no bloco 1111, o portal/aplicativo determina se há uma incompatibilidade de registro entre os cabeçalhos de registro na mensagem LRPDU de lista completa e os cabeçalhos de registro no banco de dados de solicitante.

[00128] Quando o portal/solicitante determina uma incompatibilidade entre um ou mais cabeçalhos de registro no banco de dados de solicitante e um ou mais cabeçalhos de registro da mensagem LRPDU de lista completa, o método 1100 segue para o bloco 1113. Uma incompatibilidade indica que pelo menos uma mensagem LLRPDU de registro anterior foi perdida. Portanto, o solicitante determina quais atualizações de registro não estão representadas na mensagem LRPDU de lista completa. No bloco 1113, o solicitante/portal transmite uma ou mais mensagens LRPDU de registro para o banco de dados de registro. As mensagens LRPDU de registro contêm cabeçalhos de registro atualizados conforme desejado para resolver a incompatibilidade e sincronizar o par de banco de dados.

[00129] Quando o portal/solicitante determina que não há incompatibilidade entre os cabeçalhos de registro no banco de dados de solicitante e os cabeçalhos de registro do banco de dados de registro, o método 1100 segue para o bloco 1115. Com base na determinação de não incompatibilidade, no bloco 1115 o portal/solicitante pode notificar a aplicação que a base de dados de solicitantes está sincronizada com a base de dados do registro.

[00130] A FIG. 12 é um diagrama esquemático de um nó de rede de exemplo 1200 para gerenciar a sincronização de banco de dados de acordo com uma modalidade da divulgação. O nó de rede 1200 é adequado para implementar os exemplos/modalidades divulgados conforme descrito neste documento. Por exemplo, o nó de rede 1200 pode ser empregado para implementar um sistema nativo 110/130, um proxy 210/230, um escravo 240/250, combinações dos mesmos e/ou qualquer nó local e/ou nó vizinho aqui descrito. Por exemplo, o nó de rede 1200 pode implementar um sistema de banco de dados 300.

[00131] O nó de rede 1200 compreende portas a jusante 1220, portas a montante 1250 e/ou unidades de transceptor

(Tx/Rx) 1210, incluindo transmissores e/ou receptores para comunicação de dados a montante e/ou a jusante em uma rede. O nó de rede 1200 também inclui um processador 1230 incluindo uma unidade lógica e/ou unidade de processamento central (CPU) para processar os dados e uma memória 1232 para armazenar os dados. O nó de rede 1200 também pode compreender componentes ópticos para elétricos (OE), componentes elétricos para ópticos (EO) e/ou componentes de comunicação sem fio acoplados às portas a montante 1250 e/ou portas a jusante 1220 para comunicação de dados via redes de comunicação óptica ou sem fio. O nó de rede 1200 também pode incluir dispositivos de entrada e/ou saída (I/O) para comunicar dados para e de um usuário. Tais dispositivos de I/O podem incluir dispositivos de saída, como uma tela para exibir dados de vídeo, alto-falantes para saída de dados de áudio, etc. Os dispositivos de I/O também podem incluir dispositivos de entrada, como um teclado, mouse, trackball, etc. e/ou interfaces correspondentes para interagir com tais dispositivos de saída.

[00132] O processador 1230 é implementado por hardware e software. O processador 1230 pode ser implementado como um ou mais chips de CPU, núcleos (por exemplo, como um processador multi-núcleos), matrizes de portas programáveis em campo (FPGAs), circuitos integrados específicos de aplicação (ASICs) e processadores de sinais digitais (DSPs). O processador 1230 está em comunicação com as portas a jusante 1220, Tx/Rx 1210, portas a montante 1250 e memória 1232. O processador 1230 compreende um módulo LRP-DS 1214. O módulo LRP-DS 1214 implementa as modalidades divulgadas descritas acima, como os métodos 400, 900, 1000, 1100 e/ou qualquer outro método/mecanismo aqui descrito. Além disso, o módulo LRP-DS 1214 pode transmitir, receber e/ou processar mensagens LLPDU, como mensagens LRPDU de olá 500, mensagens LRPDU de registro 600, mensagens LRPDU de lista parcial 700, mensagens LRPDU de lista completa 800 e/ou combinações das mesmas. Por exemplo, o módulo LRP-DS 1214 pode ser empregado para estabelecer uma conexão via mensagens LRPDU de olá e configurar um par de banco de dados para sincronização. Como outro exemplo, o módulo LRP-DS 1214 pode ser empregado para notificar um aplicativo quando todos os registros de um solicitante forem reconhecidos por um registro e/ou notificar o aplicativo quando o registro deixar de reconhecer uma atualização de registro. Ainda como outro exemplo, o módulo LRP-DS 1214 pode ser empregado para ressincronizar um par de banco de dados após uma desconexão sem reenviar todos os registros do solicitante ao registro. Portanto, o módulo LRP- DS 1214 melhora a funcionalidade do nó de rede 1200. Além disso, o módulo LRP-DS 1214 resolve problemas de gerenciamento de memória que são específicos para as artes da computação. Além disso, o módulo LRP-DS 1214 efetua uma transformação do nó de rede 1200 em um estado diferente. O módulo LRP-DS 1214 pode ser implementado como instruções armazenadas na memória 1232 e executadas pelo processador 1230 (por exemplo, como um produto de programa de computador armazenado em um meio não transitório).

[00133] A memória 1232 compreende um ou mais tipos de memória, como discos, unidades de fita, unidades de estado sólido, memória somente leitura (ROM), memória de acesso aleatório (RAM), memória flash, memória endereçável por conteúdo ternário (TCAM), memória de acesso aleatório estática (SRAM), etc. A memória 1232 pode ser usada como um dispositivo de armazenamento de dados de excesso, para armazenar programas quando tais programas são selecionados para execução e para armazenar instruções e dados que são lidos durante a execução do programa.

[00134] A FIG. 13 é um diagrama esquemático de um dispositivo de exemplo 1300 para estabelecer um par de banco de dados. O dispositivo 1300 pode ser empregado para implementar o método 400 e/ou o método 900. O dispositivo 1300 inclui um módulo de recepção 1301 para receber uma mensagem de olá incluindo um AppId e um enlace de destino entre um nó local e um nó vizinho. O dispositivo 1300 também inclui um módulo de determinação 1303 para determinar se o AppId está associado a um aplicativo para realizar a sincronização de banco de dados. O dispositivo 1300 também inclui um módulo de configuração de par de banco de dados 1305 para configurar um banco de dados local no nó local como parte de um par de banco de dados para uso pelo aplicativo, o par de banco de dados incluindo um banco de dados vizinho no nó vizinho. O dispositivo 1300 também inclui um módulo de associação 1307 para associar o par de banco de dados ao enlace de destino. O dispositivo também inclui um módulo de controle de sincronização 1309 para controlar a sincronização de banco de dados local com o banco de dados vizinho através do enlace de destino.

[00135] A FIG. 14 é um diagrama esquemático de um dispositivo de exemplo 1400 para gerenciar a sincronização de pares de banco de dados. O dispositivo 1400 pode ser empregado para implementar o método 400 e/ou o método 1000. O dispositivo 1400 inclui um módulo de transmissão 1401 para transmitir uma ou mais mensagens LRPDU de registro para um banco de dados de registro em um nó vizinho, as mensagens LRPDU de registro indicando atualizações de registros armazenados em um banco de dados de solicitante no nó local. O dispositivo 1400 também inclui um módulo de recepção 1403 para receber uma ou mais mensagens LRPDU reconhecendo as mensagens LRPDU de registro. O dispositivo 1400 também inclui um módulo de memória 1405 para marcar pelo menos um registro atualizado no banco de dados de solicitante como reconhecido pelo banco de dados de registro. O dispositivo 1400 também inclui um módulo de determinação 1407 para determinar que todos os registros atualizados no banco de dados de solicitante são reconhecidos pelo banco de dados de registro por meio de mensagens LRPDU. O dispositivo 1400 também inclui um módulo de notificação 1409 para notificar um aplicativo de que o banco de dados de solicitante está sincronizado com o banco de dados de registro com base na determinação de que todos os registros atualizados no banco de dados de solicitante são reconhecidos pelo banco de dados de registro através de mensagens LRPDU.

[00136] A FIG. 15 é um diagrama esquemático de um dispositivo de exemplo 1500 para manter a sincronização de banco de dados, apesar da interrupção de conexão. O dispositivo 1500 pode ser empregado para implementar o método 400 e/ou método 1100. O dispositivo 1500 inclui um módulo de desconexão 1501 para gerar um código desconectado para um aplicativo, o código desconectado indicando que uma troca de mensagens LRPDU de olá falhou. O dispositivo 1500 também inclui um módulo de comando 1503 para receber um comando do aplicativo para manter um banco de dados de solicitante na memória no nó local, apesar do código desconectado. O dispositivo 1500 também inclui um módulo de recepção 1505 para receber uma mensagem LRPDU de lista completa de um banco de dados de registro em um nó vizinho após uma troca bem- sucedida de mensagens de olá, a mensagem LRPDU de lista completa incluindo cabeçalhos de registro para todos os registros no banco de dados de registro. O dispositivo 1500 também inclui um módulo de comparação de registro 1507 para comparar os cabeçalhos de registro da mensagem LRPDU de lista completa com cabeçalhos de registro no banco de dados de solicitante para ressincronizar o banco de dados de solicitante com o banco de dados de registro.

[00137] Em uma modalidade, um nó ou elemento compreende um meio de transmissão para transmitir uma ou mais mensagens de unidade de dados de protocolo de registro local (LRPDU) de enlace de registro em direção a um banco de dados de registro em um nó vizinho, as mensagens LRPDU de registro indicando atualizações de registros armazenados em um solicitante banco de dados no nó local, bem como um meio de recepção para receber uma ou mais mensagens LRPDU reconhecendo as mensagens LRPDU de registro. O nó ou elemento inclui ainda um meio de memória para marcar pelo menos um registro atualizado no banco de dados de solicitante como reconhecido pelo banco de dados de registro. O nó ou elemento também inclui um meio de determinação para determinar que todos os registros atualizados no banco de dados de solicitante são reconhecidos pelo banco de dados de registro por meio de mensagens LRPDU e um meio de notificação para notificar um aplicativo que o banco de dados de solicitante está sincronizado com o banco de dados de registro com base na determinação que todos os registros atualizados no banco de dados de solicitante são reconhecidos pelo banco de dados de registro por meio de mensagens LRPDU.

[00138] Um primeiro componente é acoplado diretamente a um segundo componente quando não há componentes intervenientes, exceto por uma linha, um traço ou outro meio entre o primeiro componente e o segundo componente. O primeiro componente é indiretamente acoplado ao segundo componente quando há componentes intervenientes diferentes de uma linha, um traço ou outro meio entre o primeiro componente e o segundo componente. O termo "acoplado" e suas variantes incluem acoplado diretamente e indiretamente acoplado. O uso do termo "cerca de" significa uma faixa incluindo ± 10% do número subsequente, a menos que indicado de outra forma.

[00139] Embora várias modalidades tenham sido fornecidas na presente divulgação, pode ser entendido que os sistemas e métodos divulgados podem ser incorporados em muitas outras formas específicas sem se afastar do espírito ou escopo da presente divulgação. Os presentes exemplos devem ser considerados ilustrativos e não restritivos, e a intenção não deve ser limitada aos detalhes aqui fornecidos. Por exemplo, os vários elementos ou componentes podem ser combinados ou integrados em outro sistema ou certos recursos podem ser omitidos ou não implementados.

[00140] Além disso, técnicas, sistemas, subsistemas e métodos descritos e ilustrados nas várias modalidades como discretos ou separados podem ser combinados ou integrados com outros sistemas, componentes, técnicas ou métodos sem se afastar do escopo da presente divulgação. Outros exemplos de mudanças, substituições e alterações são verificáveis por um técnico no assunto e podem ser feitos sem se afastar do espírito e do escopo divulgados neste documento.

Claims (26)

REIVINDICAÇÕES

1. Método implementado em um nó local, o método caracterizado pelo fato de que compreende: receber, em um receptor no nó local, uma mensagem de olá incluindo um identificador de aplicativo (AppId) e um enlace de destino entre uma porta de destino para um nó local e a porta de destino para um nó vizinho; determinar, por um processador no nó local, que o AppId está associado a um aplicativo para realizar sincronização de banco de dados; configurar um banco de dados local na memória no nó local como parte de um par de banco de dados para uso pelo aplicativo, o par de banco de dados incluindo um banco de dados vizinho no nó vizinho; associar, pelo processador, o par de banco de dados ao enlace de destino; e controlar a sincronização do banco de dados local com o banco de dados vizinho por meio do enlace de destino.

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que controlar a sincronização de banco de dados local com o banco de dados vizinho inclui a transmissão, por um transmissor no nó local, de informações de registro para o banco de dados vizinho através do enlace de destino em mensagens de unidade de dados de protocolo de registro local (LRPDU) de enlace.

3. Método, de acordo com a reivindicação 1 ou 2, caracterizado pelo fato de que o banco de dados local inclui um banco de dados de solicitante para armazenar registros locais para transmissão a um banco de dados de registro no banco de dados vizinho.

4. Método, de acordo com qualquer uma das reivindicações 1 a 3, caracterizado pelo fato de que o banco de dados local inclui um banco de dados de registro para receber registros vizinhos de um banco de dados de solicitante no banco de dados vizinho.

5. Método, de acordo com qualquer uma das reivindicações 1 a 4, caracterizado pelo fato de que a mensagem de olá é um LRPDU de Olá, e em que o LRPDU de olá representa o enlace de destino como um identificador (ID) de Meu Chassi que identifica o nó local, um ID de Minha Porta que identifica uma porta de destino no nó local, um ID de Chassi Vizinho que identifica o nó vizinho, e um ID de Porta Vizinha que identifica uma porta de destino no nó vizinho.

6. Método implementado em um nó local, o método caracterizado pelo fato de que compreende: transmitir, por um transmissor no nó local, uma ou mais mensagens de unidade de dados de protocolo de registro local (LRPDU) de enlace de registro para um banco de dados de registro em um nó vizinho, as mensagens LRPDU de registro indicando atualizações de registros armazenados em um banco de dados de solicitante no nó local; receber, por um receptor no nó local, uma ou mais mensagens LRPDU reconhecendo as mensagens LRPDU de registro; marcar, em uma memória no nó local, pelo menos um registro atualizado no banco de dados de solicitante, conforme reconhecido pelo banco de dados de registro; e notificar, por meio do processador, um aplicativo que o banco de dados de requerente está sincronizado com o banco de dados de registro.

7. Método, de acordo com qualquer uma das reivindicações

1 a 6, caracterizado pelo fato de que compreende ainda determinar, por um processador no nó local, que todos os registros atualizados no banco de dados de solicitante são reconhecidos pelo banco de dados de registro por meio de mensagens LRPDU, em que a notificação da solicitação de que o banco de dados de solicitante seja sincronizado com o banco de dados de registro é iniciada com base na determinação de que todos os registros atualizados no banco de dados de solicitante são reconhecidos pelo banco de dados de registro por meio de mensagens LRPDU.

8. Método, de acordo com qualquer uma das reivindicações 1 a 7, caracterizado pelo fato de que as mensagens LRPDU reconhecendo as mensagens LRPDU de registro incluem uma mensagem LRPDU de lista parcial, a mensagem LRPDU de lista parcial incluindo pelo menos um cabeçalho de registro reconhecendo pelo menos um registro atualizado.

9. Método, de acordo com qualquer uma das reivindicações 1 a 8, caracterizado pelo fato de que o cabeçalho de registro inclui um número de registro que indica o registro atualizado e um número de sequência que identifica uma atualização incluída no registro atualizado.

10. Método, de acordo com qualquer uma das reivindicações 1 a 9, caracterizado pelo fato de que compreende ainda gerar uma notificação de falha para o aplicativo quando um temporizador de mensagem LRPDU de registro expira sem receber uma mensagem LRPDU de lista parcial correspondente.

11. Método, de acordo com qualquer uma das reivindicações 1 a 10, caracterizado pelo fato de que as mensagens LRPDU reconhecendo as mensagens LRPDU de registro incluem uma mensagem LRPDU de lista completa, a mensagem

LRPDU de lista completa incluindo cabeçalhos de registro para todos os registros no banco de dados de registro.

12. Método, de acordo com qualquer uma das reivindicações 1 a 11, caracterizado pelo fato de que a mensagem LRPDU de lista completa inclui um primeiro campo de número de registro indicando o primeiro registro armazenado no banco de dados de registro e um último campo de número de registro indicando o último registro armazenado no banco de dados de registro, e em que os cabeçalhos de registro incluem números de registro indicando os registros armazenados no banco de dados de registro e números de sequência que identificam as atualizações incluídas nos registros armazenados no banco de dados de registro.

13. Método, de acordo com qualquer uma das reivindicações 1 a 12, caracterizado pelo fato de que as mensagens LRPDU de registro incluem um ou mais números de registro indicando registros atualizados no banco de dados de solicitante e um ou mais números de sequência identificando atualizações incluídas nos registros atualizados na base de dados de solicitante.

14. Método, de acordo com qualquer uma das reivindicações 1 a 13, caracterizado pelo fato de que compreende ainda: transmitir, pelo transmissor, uma mensagem LRPDU de lista completa de solicitação para o banco de dados de registro; e receber, pelo destinatário, uma mensagem LRPDU de lista completa do banco de dados de registro em resposta à mensagem LRPDU de lista completa de solicitação.

15. Método implementado em um nó local, o método caracterizado pelo fato de que compreende:

gerar, por um processador no nó local, um código desconectado para um aplicativo, o código desconectado indicando que uma troca mensagens de olá de unidade de dados de protocolo de registro local (LRPDU) de enlace falhou; receber, no processador, um comando do aplicativo para manter um banco de dados de solicitante na memória no nó local, apesar do código desconectado; receber, por um receptor no nó local, uma mensagem LRPDU de lista completa de um banco de dados de registro em um nó vizinho após uma troca bem-sucedida de mensagens LRPDU de olá, a mensagem LRPDU de lista completa incluindo cabeçalhos de registro para todos os registros no banco de dados de registro; e comparar, pelo processador, os cabeçalhos de registro da mensagem LRPDU de lista completa com os cabeçalhos de registro no banco de dados de solicitante para ressincronizar o banco de dados de solicitante com o banco de dados de registro.

16. Método, de acordo com qualquer uma das reivindicações 1 a 15, caracterizado pelo fato de que compreende ainda redefinir temporizadores de notificação no banco de dados de solicitante após uma troca malsucedida de mensagens de olá para evitar a transmissão de mensagens LRPDU de registro até que a mensagem LRPDU de lista completa seja recebida.

17. Método, de acordo com qualquer uma das reivindicações 1 a 16, caracterizado pelo fato de que compreende ainda: determinar, pelo processador, uma incompatibilidade entre um ou mais cabeçalhos de registro no banco de dados de solicitante e um ou mais cabeçalhos de registro da mensagem LRPDU de lista completa; e transmitir uma mensagem LRPDU de registro para o banco de dados de registro, a mensagem LRPDU de registro contendo cabeçalhos de registro atualizados que tratam da incompatibilidade.

18. Método, de acordo com qualquer uma das reivindicações 1 a 17, caracterizado pelo fato de que compreende ainda: determinar, pelo processador, que não há incompatibilidade entre os cabeçalhos de registro no banco de dados de solicitante e os cabeçalhos de registro do banco de dados de registro; e com base na determinação de não incompatibilidade, notificar, por meio do processador, o aplicativo que o banco de dados de solicitante está sincronizado com o banco de dados de registro.

19. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende ainda o método conforme definido em qualquer uma das reivindicações 6 e 15.

20. Método, de acordo com a reivindicação 6, caracterizado pelo fato de que compreende ainda o método conforme definido na reivindicação 15.

21. Nó local, caracterizado pelo fato de que compreende uma memória, um transmissor, um receptor e um processador acoplado à memória, ao transmissor, ao receptor, o nó local configurado para realizar o método conforme definido em qualquer uma das reivindicações 1 a 20.

22. Meio legível por computador não transitório, caracterizado pelo fato de que compreende um produto de programa de computador para uso por um nó local, o produto de programa de computador compreendendo instruções executáveis por computador armazenadas no meio legível por computador não transitório de modo que, quando executado por um processador, faz com que o nó local realize o método conforme definido em qualquer uma das reivindicações 1 a 20.

23. Nó local, caracterizado pelo fato de que compreende: um meio de recepção para receber uma mensagem de olá incluindo um identificador de aplicativo (AppId) e um enlace de destino entre um nó local e um nó vizinho; um meio de determinação para determinar que o AppId está associado a um aplicativo para realizar a sincronização de banco de dados; um meio de configuração de par de banco de dados para configurar um banco de dados local no nó local como parte de um par de banco de dados para uso pelo aplicativo, o par de banco de dados incluindo um banco de dados vizinho no nó vizinho; um meio de associação para associar o par de banco de dados ao enlace de destino; e um meio de controle de sincronização para controlar a sincronização de banco de dados local com o banco de dados vizinho através do enlace de destino.

24. Nó local, caracterizado pelo fato de que compreende: um meio de transmissão para transmitir uma ou mais mensagens de unidade de dados de protocolo de registro local (LRPDU) de enlace de registro para um banco de dados de registro em um nó vizinho, as mensagens de LRPDU de registro indicando atualizações de registros armazenados em um banco de dados de solicitante no nó local; um meio de recepção para receber uma ou mais mensagens LRPDU reconhecendo as mensagens LRPDU de registro; um meio de memória para marcar pelo menos um registro atualizado no banco de dados de solicitante como reconhecido pelo banco de dados de registro; um meio de determinação para determinar se todos os registros atualizados no banco de dados de solicitante são reconhecidos pelo banco de dados de registro por meio de mensagens LRPDU; e um meio de notificação para notificar um aplicativo de que o banco de dados de solicitante está sincronizado com o banco de dados de registro com base na determinação de que todos os registros atualizados no banco de dados de solicitante são reconhecidos pelo banco de dados de registro através de mensagens LRPDU.

25. Nó local, caracterizado pelo fato de que compreende: um meio de desconexão para gerar um código desconectado para um aplicativo, o código desconectado indicando que uma troca de mensagens de olá de unidade de dados de protocolo de registro local (LRPDU) de enlace falhou; um meio de comando para receber um comando do aplicativo para manter um banco de dados de solicitante na memória no nó local, apesar do código desconectado; um meio de recepção para receber uma mensagem LRPDU de lista completa de um banco de dados de registro em um nó vizinho após uma troca bem-sucedida de mensagens de Olá, a mensagem LRPDU de lista completa incluindo cabeçalhos de registro para todos os registros no banco de dados de registro; e um meio de comparação de registros para comparar os cabeçalhos de registro da mensagem LRPDU de lista completa com os cabeçalhos de registro no banco de dados de solicitante para ressincronizar o banco de dados de solicitante com o banco de dados de registro.

26. Nó local, de acordo com qualquer uma das reivindicações 23 a 25, caracterizado pelo fato de que compreende ainda meios para realizar o método conforme definido em qualquer uma das reivindicações 1 a 20.