BRPI0713964A2 - comunicação inter-proximidade dentro de uma federação de encontro - Google Patents

Abstract

COMUNICAçãO INTER-PROXIMIDADE DENTRO DE UMA FEDERAçãO DE ENCONTRO. A presente invenção se estende a métodos, sistemas, e produtos de programa de computador para facilitar a comunicação inter-proximidade dentro de uma federação de encontro. Os nós mantêm as tabelas de entrada de conjunto de anel colateral que incluem anéis colaterais e nós de entrada correspondentes nos anéis colaterais. Os nós podem permutar o estado de entrada de conjunto de anel colateral para atualizar um ao outro na configuração de anéis dentro de uma árvore de anéis. Os nós podem se referir às tabelas de consulta de conjunto de anel colateral, além de a outros nós, para identificar os nós de entrada nos anéis que são anéis colaterais do nó. As mensagens podem ser enviadas para os nós de entrada dos anéis colaterais. Uma mensagem pode incluir uma indicação de que um nó de entrada dos anéis colaterais. Uma mensagem pode incluir uma indicação de que um nó de entrada em um anel de proximidade alvo deve resolver a mensagem par ao nó no anel de proximidade alvo que possui um ID de nó mais próximo de um nó de destino indicado.

Description

"COMUNICAÇÃO INTER-PROXIMIDADE DENTRO DE UMA FEDERAÇÃO DE ENCONTRO"

Fundamentos

Fundamentos e Técnica Fundamental

Os sistemas de computador e tecnologia relacionada afetam muitos aspectos da sociedade. Na verdade, a capacidade do sistema de computador de processar informação transformou a forma pela qual nós vivemos e trabalhamos. Os sistemas de computador ago- ra funcionam comumente como um hospedeiro de tarefas (por exemplo, processamento de texto, programação e gerenciamento de base de dados), que antes do advento do sistema de computador eram realizadas manualmente. Mais recentemente, os sistemas de compu- tador têm sido acoplados um ao outro e a outros dispositivos eletrônicos para formar redes de computador com e sem fio através das quais os sistemas de computador e outros dispo- sitivos eletrônicos podem transferir dados eletrônicos. Como resultado disso, muitas tarefas realizadas em um sistema de computador (por exemplo, comunicação de voz, acesso a cor- reio eletrônico, controle de eletrodomésticos, navegação na Rede, e impressão de docu- mentos) incluem a permuta de mensagens eletrônicas entre vários sistemas de computador e/ou outros dispositivos eletrônicos através de redes de computador com e/ou sem fio.

No entanto, para se utilizar um recurso de rede para a realização de uma tarefa computadorizada, um sistema de computador deve ter alguma forma de identificar e acessar o recurso de rede. De acordo, os recursos recebem tipicamente identificadores singulares, por exemplo, endereços de rede, que identificam de forma singular os recursos e podem ser utilizados para distinguir um recurso de outros recursos. Dessa forma, um sistema de com- putador que deseja utilizar um recurso pode ser conectado ao recurso utilizando o endereço de rede que corresponde ao recurso. No entanto, o acesso a um recurso de rede pode ser difícil se um sistema de computador não tiver conhecimento prévio de um endereço de rede para um recurso de rede. Por exemplo, um sistema de computador não pode imprimir um documento em uma impressora de rede a menos que o sistema de computador (ou outro sistema de computador em rede) conheça o endereço de rede da impressora de rede.

De acordo, vários mecanismos (por exemplo, Sistema de Nome de Domínio ("DNS"), Diretório Ativo ("AD"), Sistemas de Arquivo Distribuídos ("DFS")) foram desenvolvi- dos para os sistemas de computador poderem identificar (e acessar) recursos prévios des- conhecidos. No entanto, devido à quantidade e diversidade de recursos (por exemplo, dis- positivos e serviços) que são acessíveis através de diferentes redes de computador, os pro- jetistas são freqüentemente obrigados a desenvolver aplicativos que implementam uma va- riedade de diferentes mecanismos de identificação e acesso de recurso. Cada mecanismo diferente pode ter exigências de codificação diferentes e pode não fornecer a um projetista toda a funcionalidade que é necessária em um aplicativo. Por exemplo, apesar de DNS possuir uma arquitetura de administração distribuída (isso é, gerenciamento centralizado não ser exigido), DNS não é suficientemente dinâmico, não é auto-organizável, suporta um modelo de pesquisa e dados fraco, e possui um conjun- to fixo de raízes. Por outro lado, AD é suficientemente dinâmico, mas exige administração centralizada. Adicionalmente, os aspectos de diferentes mecanismos podem não ser compa- tíveis um com o outro. Por exemplo, um recurso identificado utilizando DNS pode não ser compatível com os protocolos de direcionamento DFS. Dessa forma, o projetista pode ser forçado a escolher o mecanismo mais adequado e eliminar as vantagens de outros meca- nismos.

Os mecanismos para identificação de recursos podem ser particularmente proble- máticos em redes não hierarquizadas. DNS fornece um serviço de consulta, com nomes de hospedeiros como chaves e endereços IP como valores, que se baseiam em um conjunto de servidores raiz especiais para implementar as solicitações de consulta. Adicionalmente, DNS exige o gerenciamento da informação (registros NS) para permitir que os clientes na- veguem na hierarquia do servidor de nome. Dessa forma, um recurso deve ser registrado no DNS antes de o recurso poder ser identificado em uma rede. Em grande escala, as redes onde os nós freqüentemente conectam e desconectam da rede baseando-se no registro de informação não são sempre práticas. Adicionalmente, DNS é especializado na tarefa de en- contras hospedeiros ou serviços e geralmente não é aplicável a outros tipos de recursos.

De acordo, outros mecanismos para identificação de recursos e acesso têm sido desenvolvidos para tentar solucionar essas desvantagens. Um número de mecanismos in- clui os protocolos de consulta distribuídos que são mais escalonáveis do que o DNS. Esses mecanismos utilizam várias disposições de nó e algoritmos de direcionamento para direcio- nar as solicitações para os recursos correspondentes e para armazenar a informação para consulta.

Pelo menos um desses mecanismos utiliza os mapas vizinhos de múltiplos níveis locais em cada nó em uma rede para direcionar mensagens para um no de destino. Isso resulta essencialmente em uma arquitetura onde cada nó é um "nó raiz" de uma árvore cor- respondente de nós (os nós em seu mapa vizinho). As mensagens são direcionadas de for- ma incrementada para um ID de destino, dígito por dígito (por exemplo, ***6=> **46=>, *346=>2346, onde *s representa coringas). A eficiência de direcionamento desses tipos de mecanismos é 0(log N) pulos de direcionamento e exige nós para manter uma tabela de direcionamento de tamanho de 0(log N).

Pelo menos outro desses mecanismos designa para os nós um ID singular que é obtido a partir de um anel linear de números. Os nós mantêm as tabelas de direcionamento que contêm apontadores para seu nó sucessor imediato (de acordo com o valor de ID) e para os nós cujos valores de ID são mais próximos do sucessor do ID de valor + 2L. A efici- ência de direcionamento desses tipos de mecanismos também é de 0(log N) pulos de dire- cionamento e exige que os nós mantenham uma tabela de direcionamento do tamanho de 0(log N).

Pelo menos um mecanismo adicional exige Oflog N~1/d) pulos de direcionamento e exige que os nós mantenham uma tabela de direcionamento de tamanho O(D). Dessa for- ma, a eficiência de direcionamento de todos esses mecanismos depende, pelo menos em parte, do número de nós no sistema.

Adicionalmente, visto que os IDs (para pelo menos alguns dos mecanismos) podem ser distribuídos uniformemente em torno de um anel, existe sempre alguma possibilidade de o direcionamento entre os nós no anel resultar em alguma ineficiência. Por exemplo, os pu- los de direcionamento podem cruzar vastas distâncias geográficas, cruzar conexões mais caras, ou passar através dos domínios inseguros, etc. Adicionalmente, quando o direciona- mento de mensagem envolve múltiplos pulos, existe alguma chance que tais eventos ocor- rerem múltiplas vezes. Infelizmente, esses mecanismos não levam em consideração a pro- ximidade dos nós (físicos ou outros) com relação um ao outro. Por exemplo, dependendo da distribuição do nó em um anel, o direcionamento de uma mensagem de Nova Iorque para Boston pode envolver o direcionamento da mensagem de Nova Iorque, para Londres, para Atlanta, para Tóquio, e então para Boston.

De acordo, pelo menos outro mecanismo mais recente leva a proximidade em con- sideração pela definição da proximidade como uma métrica de proximidade escalar única (por exemplo, pulos de direcionamento IP ou distância geográfica). Esses mecanismos utili- zam a noção da escolha com base em proximidade dos registros de tabela de direciona- mento. Visto que existem muitos candidatos de nó "corretos" para cada registro de tabela de direcionamento, esses mecanismos tentam selecionar um nó próximo dentre os nós candi- datos. Esses mecanismos podem fornecer uma função que permite que cada nó determine a "distância" de um nó com um determinado endereço IP para si. As mensagens são dire- cionadas entre os nós em proximidade para fazer progresso na direção de um destino antes do direcionamento para um nó que está mais distante. Dessa forma, alguns recursos podem ser conservados e o direcionamento é mais eficiente.

Infelizmente, esses mecanismos existentes tipicamente não fornecem, entre outras coisas, relações simétricas entre os nós (isso é, se um primeiro nó considerar um segundo nó como seu parceiro, o segundo nó considera o primeiro nó como seu parceiro também), mensagens de direcionamento em ambas as direções (horária e anti-horária) em um anel, divisão de listas conectadas de nós com base em uma pluralidade de métricas de proximi- dade, e mensagens de direcionamento baseadas em uma pluralidade de métricas de proxi- midade. Essas deficiências podem limitar a transferência dinâmica, distribuída e eficiente de dados entre os nós de uma rede, tal como, por exemplo, quando da difusão de dados para todos os nós da rede.

Breve Sumário

A presente invenção se estende a métodos, sistemas e produtos de programa de computador para facilitar a comunicação inter-proximidade dentro de uma federação de en- contro (rendezvous). Em algumas modalidades, uma tabela de registro de conjunto de anel colateral para um nó é mantida. Um nó acessa uma tabela de registro de conjunto de anel colateral configurada para armazenar os registros de conjunto de anel colateral para o nó. Cada registro de conjunto de anel colateral é configurado para indicar um anel colateral do nó e pelo menos um nó de registro correspondente em um anel colateral do nó. A informa- ção da tabela de registro de conjunto de anel colateral dos recursos disponíveis que mantêm a informação relacionada com a configuração da árvore de anéis é descoberta. A tabela de registro de conjunto de anel colateral é atualizada com o estado de registro de conjunto de anel colateral adequado com base na informação de tabela de registro de conjunto de anel colateral descoberta. O estado de registro de conjunto de anel colateral adequado incluindo um anel colateral do nó e pelo menos um nó de registro correspondente no anel colateral do nó.

Em outras modalidades, a comunicação inter-proximidade é enviada em uma árvo- re de anéis. Em uma modalidade de comunicação inter-proximidade, é determinado que um nó deve enviar uma mensagem para um anel colateral do nó. O nó acessa uma tabela de registro de conjunto de anel colateral configurada para armazenar os registros de conjunto de anel colateral para o nó. Cada registro de conjunto de anel colateral é configurado para indicar um anel colateral do nó e pelo menos um nó de registro correspondente no anel cola- teral do nó. Pelo menos um registro de conjunto de anel colateral para o anel colateral espe- cificado é identificado a partir da tabela de registro de conjunto de anel colateral do nó. Cada um dos pelo menos um registros de conjunto de anel colateral indica pelo menos um nó de registro do anel colateral especificado. A mensagem é enviada para pelo menos um nó de registro indicado.

Em outra modalidade da comunicação inter-proximidade, é determinado que um nó de origem pretende direcionar uma mensagem para um nó de destino que está mais próxi- mo de um ID de nó determinado em um anel de proximidade alvo dentro da árvore de anéis. Um ou mais nós de registro conhecidos como sendo nós membros de pelo menos um den- tre um anel de proximidade alvo e um anel antepassado do anel de proximidade alvo são identificados. A mensagem é enviada para um nó de registro identificado. A mensagem indi- ca que o nó de registro identificado deve resolver a mensagem para o nó que possui um ID de nó mais próximo e um nó de destino indicado no anel de proximidade alvo.

Esse Sumário é fornecido para introduzir uma seleção de conceitos de uma forma simplificada que serão descritos abaixo na Descrição Detalhada. Esse Sumário não deve identificar características chave ou características essenciais da matéria reivindicada, nem pretende ser utilizado como um auxílio na determinação do escopo da matéria reivindicada.

Características e vantagens adicionais serão apresentadas na descrição que se se- gue, e, em parte serão óbvias a partir da descrição, ou podem ser aprendidas pela prática dos ensinamentos apresentados aqui. As características e vantagens da invenção podem ser realizadas e obtidas por meio de instrumentos e combinações particularmente destaca- dos nas reivindicações em anexo. As características da presente invenção se tornarão mais totalmente aparentes a partir da descrição a seguir e das reivindicações em anexo, ou podem ser aprendidas pela prática da invenção como apresentada posteriormente.

Breve Descrição dos Desenhos

A fim de se descrever a forma na qual as vantagens e características recitadas a- cima, bem como outras, podem ser obtidas, uma descrição mais particular da matéria des- crita brevemente acima será criada por referência às modalidades especificas que são ilus- tradas nos desenhos em anexo. Compreendendo que esses desenhos apresentam apenas as modalidades típicas e não são, portanto, considerados limitadores em termos de escopo, as modalidades serão descritas e explicadas com especificidade adicional e detalhes atra- vés do uso dos desenhos em anexo, nos quais:

A figura 1 ilustra um exemplo de uma infra-estrutura de federação;

A figura 2 ilustra um exemplo de uma arquitetura de computador que facilita a solici- tação de direcionamento indiretamente para os parceiros;

A figura 3 ilustra um exemplo de relação binária entre os nós em uma infra-estrutura de federação na forma de uma lista classificada e anel correspondente;

A figura 4 ilustra um anel ilustrativo dentre os anéis que facilitam o direcionamento proximal;

A figura 5 ilustra uma árvore divisória de anéis induzida por proximidade ilustrativa que facilita o direcionamento proximal;

A figura 5a ilustra uma árvore divisória de anéis induzida por proximidade ilustrativa da figura 5 com detalhes adicionais em partes da árvore divisória de anéis da figura 5;

A figura 6 ilustra um ambiente operacional adequado para os princípios da presente invenção;

A figura 7 ilustra um fluxograma ilustrativo de um método para preencher uma tabe- la de direcionamento de nó que leva os critérios de proximidade em consideração;

A figura 8 ilustra um fluxograma ilustrativo de um método de divisão dos nós de uma infra-estrutura de federação;

A figura 9 ilustra um fluxograma ilustrativo de um método de preenchimento de uma tabela de direcionamento de nó;

A figura 10 ilustra um fluxograma ilustrativo de um método de direcionamento nu- mérico de uma mensagem na direção de um nó de destino;

A figura 11 ilustra um fluxograma ilustrativo de um método para direcionar de forma proximal uma mensagem na direção de um nó de destino;

A figura 12a ilustra um exemplo de uma relação de estabelecimento de nó dentro de uma federação existente;

A figura 12b ilustra um exemplo de nós em uma infra-estrutura de federação de permuta de mensagens;

A figura 13 ilustra um fluxograma ilustrativo de um método de estabelecimento da relação dentro de uma infra-estrutura de federação;

A figura 14 ilustra um fluxograma ilustrativo de um método para manutenção da re- lação dentro de uma infra-estrutura de federação;

A figura 15 ilustra um fluxograma ilustrativo de um método para descobrir informa- ção de vivacidade para outro nó;

A figura 16 ilustra um exemplo de um modelo de mensagem e modelo de proces- samento relacionado;

A figura 17 ilustra um exemplo de um número de interações de vivacidade que pode ocorrer entre uma camada de função e uma camada de aplicativo;

A figura 18 ilustra um exemplo de mensagens formando parte de um padrão de permuta de mensagem de resposta à solicitação que são direcionadas através dos nós em um anel;

A figura 19a ilustra uma árvore divisória de anéis induzida por proximidade ilustrati- va que facilita a comunicação inter-proximidade;

A figura 19b ilustra outra vista da árvore divisória de anéis induzida por proximidade ilustrativa da figura 19a;

A figura 19c ilustra uma vista dividida de uma parte da árvore divisória de anéis in- duzida por proximidade ilustrativa da figura 19a;

A figura 19d ilustra uma vista expandida de um anel intermediário da árvore divisó- ria de anéis induzida por proximidade ilustrativa da figura 19a;

A figura 19e ilustra outra vista da árvore divisória de anéis induzida por proximidade ilustrativa da figura 19a;

A figura 19f ilustra uma vista adicional da árvore divisória de anéis induzida por pro- ximidade ilustrativa da figura 19a;

A figura 19g ilustra uma vista expandida de uma parte da figura 19f;

A figura 20 ilustra um fluxograma ilustrativo de um método para manutenção de um conjunto de anel colateral para um nó na árvore de anéis;

A figura 21 ilustra um fluxograma ilustrativo para um método par ao envio da comu- nicação inter-proximidade em uma árvore de anéis; A figura 22 ilustra um fluxograma ilustrativo para outro método para o envio da co- municação inter-proximidade em uma árvore de anéis.

Descrição Detalhada

A presente invenção se estende a métodos, sistemas e produtos de programa de computador para facilitar a comunicação inter-proximidade dentro de uma federação de en- contro. Em algumas modalidades, uma tabela de registro de conjunto de anel colateral para um nó é mantida. Um nó acessa uma tabela de registro de conjunto de anel colateral confi- gurada para armazenar os registros de conjunto de anel colateral par ao nó. Cada registro de conjunto de anel colateral é configurado para indicar um anel colateral do nó e pelo me- nos um nó de registro correspondente no anel colateral do nó. A informação da tabela de registro de conjunto de anel colateral dos recursos disponíveis que mantêm a informação relacionada com a configuração da árvore de anéis é descoberta. A tabela de registro de conjunto de anel colateral é atualizada com o estado de registro de conjunto de anel colate- ral com base na informação de tabela de registro de conjunto de anel colateral descoberta. O estado de registro de conjunto de anel colateral adequado incluindo um anel colateral do nó e pelo menos um nó de registro correspondente no anel colateral do nó.

Em outras modalidades, a comunicação inter-proximidade é enviada em uma árvo- re de anéis. Em uma modalidade da comunicação inter-proximidade, é determinado que um nó deve enviar uma mensagem para um anel colateral especificado do nó. O nó acessa uma tabela de registro de conjunto de anel colateral configurada para armazenar os registros de conjunto de anel colateral para o nó. Cada registro de conjunto de anel colateral é configu- rado para indicar um anel colateral do nó e pelo menos um nó de registro correspondente no anel colateral do nó. Pelo menos um registro de conjunto de anel colateral para o anel cola- teral especificado é identificado a partir da tabela de registro de conjunto de anel colateral do nó. Cada um dos pelo menos um registros de conjunto de anel colateral indica pelo menos um nó de registro do anel colateral especificado. A mensagem é enviada para pelo menos um nó de registro indicado.

Em outra modalidade de comunicação inter-proximidade, é determinado que um nó de origem pretende direcionar uma mensagem para um nó de destino que está mais próxi- mo de um determinado ID de nó em um anel de proximidade alvo dentro da árvore de anéis. Um ou mais nós de registro conhecidos como sendo membros dos nós de pelo menos um anel de proximidade alvo e um anel antepassado do anel de proximidade alvo são identifi- cados. A mensagem é enviada para um nó de registro identificado. A mensagem indica que o nó de registro identificado deve resolver a mensagem para o nó que possui um ID de nó mais próximo de um nó de destino indicado no anel de proximidade alvo.

As modalidades dentro do escopo da presente invenção incluem mídia legível por computador para transportar ou possuindo instruções executáveis por computador ou estru- turas de dados armazenadas na mesma. Tal mídia legível por computador pode ser qual- quer mídia disponível, que seja acessível por um sistema de computador de finalidade geral ou finalidade especial. Por meio de exemplo, e não de limitação, tal mídia legível por compu- tador pode compreender mídia de armazenamento físico tal como RAM, ROM, EPROM, CD- ROM ou outro armazenamento em disco ótico, armazenamento em disco magnético ou ou- tros dispositivos de armazenamento magnético, ou qualquer outra mídia que possa ser utili- zada para portar ou armazenar os dispositivos de código de programa desejados na forma de instruções executáveis por computador, instruções legíveis por computador, ou estrutu- ras de dados, e que possam ser acessados por um sistema de computador de finalidade geral ou finalidade especial.

Nessa descrição e nas reivindicações a seguir, uma "rede" é definida como uma ou mais conexões de dados (ou possivelmente velocidades diferentes) que permitem o trans- porte de dados eletrônicos entre os sistemas e/ou módulos de computador (por exemplo, módulos de hardware e/ou software). Quando a informação é transferida ou fornecida atra- vés de uma rede ou outra conexão de comunicação (com fio, sem fio ou uma combinação de ambas) para um sistema de computador, a conexão é adequadamente visualizada como um meio legível por computador. Dessa forma, qualquer conexão dessas é adequadamente chamada de meio legível por computador. As combinações do acima devem ser incluídas também no escopo da mídia legível por computador. As instruções executáveis por compu- tador compreendem, por exemplo, instruções e dados que fazem com que o sistema de computador de finalidade geral ou sistema de computador de finalidade especial realizem uma determinada função ou grupo de funções. As instruções executáveis por computador podem ser, por exemplo, instruções de formato intermediário binárias, tal como linguagem de conjunto ou mesmo código fonte. Em algumas modalidades, os módulos de hardware, tal como, por exemplo, circuitos integrados de finalidade especial ou conjuntos de Porta são otimizados para implementar os princípios da presente invenção.

Nessa descrição e nas reivindicações a seguir, um "nó" é definido como um ou mais módulos de software, um ou mais módulo de hardware, ou combinações dos mesmos, que funcionam juntos para realizar as operações em dados eletrônicos. Por exemplo, a defi- nição de um nó inclui os componentes de hardware de um computador pessoal, além de módulos de software, tal como o sistema operacional do computador pessoal. A disposição física dos módulos não é importante. Um nó pode incluir um ou mais computadores acopla- dos através de uma rede. Da mesma forma, um nó pode incluir um único dispositivo físico (tal como um telefone móvel ou Assistente Digital Pessoal "PDA") onde os módulos internos (tal como memória e processador) funcionam juntos para realizar as operações nos dados eletrônicos. Adicionalmente, um nó pode incluir hardware de finalidade especial, tal como, por exemplo, um roteador que inclui circuitos integrados de finalidade especial. Os versados na técnica apreciarão que a invenção pode ser praticada nos ambien- tes de computação de rede com muitos tipos de configurações de nó, incluindo, computado- res pessoais, computadores laptop, dispositivos portáteis, sistemas multiprocessadores, partes eletrônicas de consumidor programáveis ou baseadas em microprocessador, PCs em rede, mini computadores, computadores principais, telefones móveis, PDAs1 pagers, roteadores, circuitos de acesso, intermediadores (brokers), proxies, firewalls, redirecionado- res, tradutores de endereço de rede, e similares. A invenção também pode ser praticada em ambientes de sistema distribuído onde os nós local e remoto, que são conectados (por co- nexões de dados com fio, conexões de dados sem fio ou por uma combinação das cone- xões de dados com e sem fio) através de uma rede, realizam ambas as funções. Em um ambiente de sistema distribuído, os módulos de programa podem estar localizados em am- bos os dispositivos de armazenamento em memória local e remota.

Arquitetura de Federação

A figura 1 ilustra um exemplo de uma infra-estrutura de federação 100. A infra- estrutura de federação 100 inclui nós 101, 102, 103 que podem formar tipos diferentes de parcerias de federação. Por exemplo, os nós 101, 102, 103 podem ser federados entre si como iguais sem um nó raiz. Cada um dos nós 101, 102, 103 possui um ID correspondente 171, 182 e 193, respectivamente.

Geralmente, os nós 101, 102, 103 podem utilizar protocolos de federação para for- mar parcerias e permutar informação (por exemplo, informação de estado relacionada com as interações com outros nós). A formação de parcerias e permuta de informação facilita um acesso mais eficiente e confiável dos recursos. Outros nós intermediários (não ilustrados) podem existir entre os nós 101, 102, 103 (por exemplo, nós possuindo IDs entre 171 e 193). Dessa forma, uma mensagem direcionada, por exemplo, entre o nó 101 e o nó 103, pode passar através de um ou mais dos outros nós intermediários.

Os nós na infra-estrutura de federação 100 (incluindo outros nós intermediários) podem incluir pilhas de protocolo de encontro correspondentes. Por exemplo, os nós 101, 102 e 103 incluem pilhas de protocolo de encontro correspondentes 141, 142 e 143, respec- tivamente. Cada uma das pilhas de protocolo 141, 142 e 143 inclui uma camada de aplicati- vo (por exemplo, camadas de aplicativo 121, 122 e 123) e outras camadas inferiores (por exemplo, correspondendo a outras camadas inferiores 131, 132 e 133). Cada camada em uma pilha de protocolo de encontro é responsável pela funcionalidade diferente relacionada com o encontro de uma solicitação de recurso com um recurso correspondente.

Por exemplo, outras camadas inferiores podem incluir uma camada de canal, uma camada de direcionamento, e uma camada de função. Geralmente, uma camada de canal é responsável pelo transporte confiável de uma mensagem (por exemplo, utilizando WS- ReIiabIeMessaging e Protocolo de Acesso a Objeto Simples ("SOAP")) de um ponto de ex- tremidade para outro (por exemplo, do nó 101 para o nó 103). A camada de canal também é responsável pelo processamento de cabeçalhos de mensagem confiáveis de entrada e saí- da e pela manutenção do estado relacionado com as sessões de envio de mensagem confiável.

Geralmente, a camada de direcionamento é responsável pela computação do pró- ximo pulo na direção de um destino. Essa camada de direcionamento também é responsá- vel pelo processamento dos cabeçalhos de mensagem de direcionamento e endereçamento de entrada e saída e manutenção do estado de direcionamento. Geralmente, uma camada de função é responsável pela emissão e processamento de mensagens de protocolo de en- contro tal como solicitações em conjunto ou separadas, pings, atualizações e outras mensa- gens, além da geração de respostas a essas mensagens. A camada de função processa as mensagens de solicitação da camada de direcionamento e envia de volta as mensagens de resposta correspondentes, se alguma, para o nó de origem utilizando a camada de direcio- namento. A camada de função também inicia as mensagens de solicitação e utiliza a cama- da de direcionamento para distribuir as mensagens de solicitações.

Geralmente, uma camada de aplicativo processa dados específicos de protocolo de não encontro distribuídos a partir da camada de função (isto é, mensagens de aplicativo). A camada de função pode acessar dados de aplicativo a partir da camada de aplicativo e obter e colocar dados de aplicativo nas mensagens de protocolo de encontro (por exemplo, pings e atualizações). Isto é, a camada de função pode fazer com que os dados de aplicativo se- jam carregados nas mensagens de protocolo de encontro e pode fazer com que os dados de aplicativo sejam passados de volta para a camada de aplicativo nos nós de protocolo de encontro receptores. Em algumas modalidades, os dados de aplicativo são utilizados para identificar os recursos e os interesses de recurso. Dessa forma, uma camada de aplicativo pode incluir lógica específica de aplicativo e estado que processa os dados recebidos de e enviados para as outras camadas inferiores para fins de identificação de recursos e interes- ses de recursos.

Mecanismos de Federação

Os nós podem federar utilizando uma variedade de mecanismos diferentes. Um primeiro mecanismo de federação inclui nós não hierarquizados enviando informação para todos os outros nós não hierarquizados. Quando um nó está para se unir a uma infra- estrutura de federação, o nó utiliza um protocolo de descoberta de difusão/multidifusão, tal como, por exemplo, WS-Discovery para anunciar sua presença e emite uma busca de difu- são/multidifusão para detectar outros nós. O nó então estabelece uma parceria de envio simples com outros nós já presentes na rede e aceita novas parcerias com nós recém che- gados. Depois disso, o nó simplesmente envia todas as mensagens específicas de aplicati- vo para todos os seus nós parceiros. Um segundo mecanismo de federação inclui nós iguais que transmitem de forma mais eficiente as mensagens específicas de aplicativo para seus destinos. Quando um novo nó está para se unir a uma infra-estrutura de federação, o novo nó utiliza um protocolo de descoberta de difusão/multidifusão, tal como, por exemplo, WS-Discovery para anunciar sua presença e emite uma busca de difusão/multidifusão para detectar outros nós que são parte da infra-estrutura de federação. Mediante a detecção de outro nó, o novo nó estabelece uma parceria com o outro nó. A partir da parceira estabelecida, o novo nó aprende sobre a pre- sença de outros nós já participando da infra-estrutura de federação. Estabelece então parce- rias com esses nós recém aprendidos e aceita quaisquer novas solicitações de parceria.

Ambos as chegadas/partidas de nós e registros de interesse em determinadas mensagens especificas de aplicativo são inundadas através da infra-estrutura de federação resultando em cada nó possuindo conhecimento global de outros nós parceiros e registros de interesse nas mensagens específicas de aplicativo. Com tal conhecimento global, qual- quer nó pode enviar mensagens específicas de aplicativo diretamente para os nós que ex- pressaram o interesse na mensagem específica de aplicativo.

Um terceiro mecanismo de federação inclui nós iguais enviando indiretamente to- das as mensagens específicas de aplicativo para seus destinos. Nesse terceiro mecanismo, os nós recebem ID, tal como, por exemplo, um ID de 128 bits ou 160 bits. O nó responsável pela manutenção do registro de interesse em uma determinada mensagem especifica de aplicativo pode ser determinado como sendo um cujo ID está mais próximo do obtido pelo mapeamento (por exemplo, hashing) da identidade de destino (por exemplo, URI) da men- sagem específica de aplicativo para esse espaço de ID de 128 bits ou 160 bits.

Nesse terceiro mecanismo, as chegadas e partidas de nó são inundadas através de todo a rede. Por outro lado, os registros de interesse em determinadas mensagens específi- cas de aplicativo são enviados para os nós determinados como responsáveis pela manuten- ção de tal informação de registro. Por motivos de escalonamento, equilíbrio de carga, e tole- rância de falha, o nó recebendo o registro de interesse em determinadas mensagens espe- cíficas de aplicativo pode inundar de forma confiável essa informação de registro dentro de seu conjunto vizinho. O conjunto vizinho para um nó especificado pode ser determinado co- mo sendo o conjunto de nós possuindo IDs dentro de uma faixa predefinida em cada lado do ID do nó especificado.

Similar ao segundo mecanismo, um nó recém chegado utiliza um protocolo de des- coberta de difusão/multidifusão, tal como, por exemplo, WS-Discovery para anunciar sua presença e emite uma busca de difusão/multidifusão local para detectar um nó que já é par- te da infra-estrutura de federação. O novo código estabelece uma parceria com o nó desco- berto e utiliza essa parceria para aprender sobre a presença de outros novos nós participan- tes da infra-estrutura de federação. O novo código então estabelece parcerias adicionais com os nós recém descobertos e aceita quaisquer novas solicitações de parceria. O novo nó aceita os registros de interesse de entrada em determinados recursos específicos de cama- da de aplicativo de seus parceiros pelos quais é responsável e pode inundar os mesmos através de seu conjunto vizinho. Dessa forma, as mensagens podem ser geralmente envia- das para seu destino final através de nós de direcionamento intermediários (por exemplo, com quem os quais o nó recém chegado já teve parceira ou de quem um nó parceiro tem ciência).

Em resposta ao recebimento de uma mensagem específica de aplicativo de chega- da, o novo nó envia a mensagem para o nó parceiro que pode ser responsável pela manu- tenção da informação de registro par ao destino especificado na mensagem. Dessa forma, quando da utilização desse terceiro mecanismo, cada nó na infra-estrutura de federação possui um conhecimento global de todos os outros nós, mas a informação de registro é efi- cientemente dividida entre os nós. As mensagens específicas de aplicativo são transmitidas para seu destino final através apenas dos nós do parceiro que podem ter a responsabilidade de manter a informação de registro de interesse nessas mensagens específicas de aplicati- vo. Dessa forma, desvio é realizado pelo envio apenas para o nó parceiro que tem conheci- mento global da informação de interesse de registro para a mensagem sendo processada. Isso ocorre em contraste com o primeiro mecanismo onde o desvio é realizado pelo envio para todos os nós parceiros.

Um quarto mecanismo de federação inclui nós iguais que direcionam as mensa- gens para outros nós iguais. Esse quarto mecanismo difere do terceiro mecanismo pelo me- nos pelo fato de ambas as chegadas/partidas de nó e registros de interesse em determina- das mensagens específicas de aplicativo serem todos direcionados ao invés de serem inun- dados. Os protocolos de direcionamento são projetados para garantir o encontro entre men- sagens específicas de aplicativo e mensagens de registro que expressam interesse nessas mensagens específicas de aplicativo.

A figura 2 ilustra um exemplo de uma arquitetura de computador 200 que facilita o direcionamento das solicitações indiretamente para os parceiros. A arquitetura de computa- dor 200 representa tipos diferentes de sistemas e dispositivos de computador espalhados potencialmente através de múltiplos escopos de descoberta local participantes de uma infra- estrutura de federação.

A estação de trabalho 233 pode incluir um caso de provedor PnP registrado. Para informar seus parceiros sobre a presença desse caso de provedor PnP, a estação de traba- lho 233 direciona a solicitação de registro 201 através da infra-estrutura de federação. A solicitação de registro 201 é inicialmente enviada par ao Iaptop 231, que, por sua vez, envia a solicitação de registro 201 para o intermediador de mensagem 237, que, por sua vez, en- via a solicitação de registro 201 para o circuito de acesso de mensagem 241. O circuito de acesso de mensagem 241 salva a solicitação de registro de informação de registro 201 em sua base de dados e retorna a mensagem de sucesso 204 para a estação de trabalho 233.

Subseqüentemente, outro caso de provedor registrado, essa vez o de serviços, to- ma vida dentro da estação de trabalho 233. Dessa vez o nó está ciente de que o circuito de acesso de mensagem 241 é responsável pelos registros e envia a solicitação de registro 205 para o circuito de acesso de mensagem 241 diretamente. O circuito de acesso de men- sagem 241 salva a solicitação de registro de informação de registro 205 em sua base de dados e retorna a mensagem de sucesso 206 para a estação de trabalho 233.

Subseqüentemente, a impressora 236 (por exemplo, uma impressora UPnP) é e- nergizada e envia o anúncio 207. O servidor 234 detecta o anúncio 207 e direciona a solici- tação de registro 208 para o intermediador de mensagem 237. O intermediador de mensa- gem 237 envia a solicitação de registro 208 para o circuito de acesso de mensagem 241. O circuito de acesso de mensagem 241 salva a solicitação de registro de informação de regis- tro 208 em sua base de dados e retorna a mensagem de sucesso 210 para o servidor 234.

Subseqüentemente, o computador pessoal 242 emite a solicitação de consulta 211 para descobrir todos os dispositivos. Visto que o computador pessoal 242 não sabe para onde enviar a solicitação de consulta 211, o mesmo direciona a solicitação de consulta 211 através da estação de trabalho 243. Visto que o registro e solicitações de consulta são dire- cionados para o mesmo destino, o protocolo de direcionamento garante essencialmente o encontro entre as duas solicitações resultando na estação de trabalho 243 e envia a solicita- ção de busca 211 para o circuito de acesso da mensagem 241. O circuito de acesso de mensagem 241 consulta a informação de registro mantida pelo mesmo e envia a solicitação de busca 211 para ambas a estação de trabalho 233 e o servidor 234. A estação de trabalho 233 e o servidor 234 enviam mensagens de resposta 214 e 216, respectivamente, para o computador pessoal 242.

Esse quarto mecanismo funciona pelo direcionamento (ao invés de inundação) de uma solicitação para o nó (circuito de acesso de mensagem 241) que possui conhecimento global dos registros especificados em uma solicitação. Esse quarto mecanismo, como será descrito em maiores detalhes abaixo, garante essencialmente que o direcionamento possa ser realizado em pulos 0(log N), onde N é o número de nós participantes na infra-estrutura de federação. Visto que esse quarto mecanismo divide de forma eficiente ambas a parceria de nó e informação de registro, o mesmo se aplica a redes muito grandes, até mesmo a In- ternet.

Apesar de um número de mecanismos de federação terem sido descritos, seria a- parente aos versados na técnica, depois de terem revisado essa descrição, de que outros mecanismos de federação são possíveis.

Relações Entre Nós Em uma Federação De acordo, uma federação consiste de um conjunto de nós que cooperam entre si para formar uma rede dinâmica e escalonável na qual a informação pode ser sistematica- mente e eficientemente disseminada e localizada. Os nós são organizados para participar em uma federação como uma lista classificada utilizando uma relação binária que é reflexi- va, anti-simétrica, transitiva, total e definida através do domínio das identidades de nó. Am- bas as extremidades da lista classificada são unidas, formando, assim, um anel. Dessa for- ma, cada nó na lista pode ver a si mesmo como estando no meio da lista classificada (como resultado da utilização da aritmética de módulo). Adicionalmente, a lista é conectada dupla- mente de forma que qualquer nó possa atravessar a lista em qualquer direção.

Cada nó de federação pode receber um ID (por exemplo, por um gerador de núme- ro aleatório com detecção duplicada) a partir de um conjunto fixo de IDs entre O e algum limite superior fixo. Dessa forma, a adição de 1 a um ID do limite superior fixo resulta em um ID de zero (isso é, movendo da extremidade da lista conectada de volta para o começo da lista conectada). Adicionalmente, uma função de mapeamento de 1:1 do domínio de valor das identidades de nó para os nós propriamente ditos é definida.

A figura 3 apresenta uma lista conectada ilustrativa 304 e anel correspondente 306. De acordo com tal anel, as funções a seguir podem ser definidas:

RouteNumerically(V, Msg): De acordo com um valor V do domínio de valor das i- dentidades de nó e uma mensagem "Msg", distribuir a mensagem para o nó X cuja identida- de pode ser mapeada para V utilizando a função de mapeamento.

Vizinhança (X, S): Vizinhança é o conjunto de nós em cada lado do nó X com cardi- nalidade igual a S.

Quando cada nó na federação possui conhecimento global do anel, RouteNumeri- cally(V, Msg) é implementado pelo envio direto de Msg para o nó X, cuja identidade é obtida pela aplicação da função de mapeamento a V. Alternativamente, quando os nós possuem conhecimento limitado de outros nós (por exemplo, apenas dos nós imediatamente adjacen- tes), RouteNumerically(V, Msg) é implementado pelo envio da mensagem para nós conse- cutivos ao longo do anel até que alcance o nó de destino X.

Alternativamente (e vantajosamente), os nós podem armazenar conhecimento sufi- ciente sobre o anel para realizar uma busca binária distribuída (sem precisar ter conheci- mento global ou implementar o direcionamento entre nós imediatamente adjacentes). A quantidade de conhecimento de anel é configurável de forma que a manutenção do conhe- cimento de anel possui um impacto suficientemente pequeno em cada nó, mas permite o desempenho de direcionamento aumentado da redução no número de pulos de direciona- mento.

Como previamente descrito, os IDs podem ser designados utilizando-se a relação "<" (menos que) definida através de um conjunto limitado, suficientemente grande, de núme- ros naturais, significando que sua faixa é sobre um conjunto finito de números entre 0 e al- gum valor fixo, inclusive. Dessa forma, cada nó participante na federação recebe um número natural que se encontra entre 0 e algum limite superior escolhido de forma adequada, inclu- sive. A faixa não precisa ser muito restrita e pode haver espaços entre os números designa- dos para os nós. O número designado para um nó serve como sua identidade no anel. A função de mapeamento é responsável pelos espaços no espaço de número pelo mapea- mento de um número que se encontra entre duas identidades de nó para o nó cuja identida- de é numericamente mais próxima do número.

Essa abordagem apresenta várias vantagens. Pela designação para cada nó de um número distribuído de maneira uniforme, existe uma probabilidade maior de que todos os segmentos do anel sejam preenchidos de maneira uniforme. Adicionalmente, as computa- ções sucessoras, antecessoras e vizinhas podem ser realizadas de forma eficiente utilizan- do-se a aritmética de módulo.

Em algumas modalidades, os nós de federação recebem um ID de dentro de um espaço de ID tão grande que as chances de os dois nós receberem o mesmo ID são impro- váveis (por exemplo, quando a geração de número aleatório é utilizada). Por exemplo, um nó pode receber um ID na faixa de 0 a bn-1, onde b é igual, por exemplo, a 8 ou 16 e η é igual a, por exemplo, dígitos equivalentes de 128 bits ou 160 bits. De acordo, um nó pode receber um ID, por exemplo, de uma faixa de 0 a IS40-I (ou aproximadamente 1,461502E48). Afaixa de 0 a 1640-1 fornece, por exemplo, um número suficiente de IDs para designar para cada nó na Internet um ID singular.

Dessa forma, cada nó em uma federação pode ter:

Um ID que é um valor numérico distribuído de maneira uniforme na faixa de 0 a bn- 1;e

Uma tabela de direcionamento consistindo de (toda a aritmética é feita por módulo bn):

Nó sucessor (s);

Nó predecessor (p);

Nós vizinhos (pk.....P1, p, s, Si.....Sj) de forma que Sj.s.id>(id+u/2), j>v/2-1, e

pk.p.id<(id-u/2), e k > v/2-1; e

Nós de direcionamento (r(n.i), ..., ^1, T1,..., rn-i) de forma que r+/. i=RouteNumerically(id+/-b', Msg).

onde b é o número base, η é o tamanho de campo no número de dígitos, u é a faixa de vizinhança, ν é o tamanho da vizinhança, e a aritmética é realizada por módulo bn. Para se ter uma boa eficiência de direcionamento e tolerância de falha, os valores de u e ν podem ser u=b e v>max(log2(N), 4), onde N é o número total de nós fisicamente participantes na federação. N pode ser estimado a partir do número de nós presentes em um segmento de anel cujo comprimento é superior a ou igual a b, por exemplo, quando existe uma distribui- ção uniforme de IDs. Os valores típicos para b e η são b=8 ou 16 e n=dígitos equivalentes a .128 bits ou 160 bits.

De acordo, os nós de direcionamento podem formar um índice logarítmico abran- gendo um anel. Dependendo das localizações dos nós em um anel, um índice logarítmico preciso é possível, por exemplo, quando existe um nó existente em cada número no conjun- to de id +/- b' onde i = (1, 2,...(n-1)). No entanto, pode ocorrer de não existirem nós em cada número no conjunto. Nesses casos, um nó mais próximo de id +/- b' pode ser selecionado como um nó de direcionamento. O índice logarítmico resultante não é preciso e pode até mesmo não ter nós de direcionamento singulares para alguns números no conjunto.

Com referência novamente à figura 3, a figura 3 ilustra um exemplo de uma relação binária entre os nós em uma infra-estrutura de federação na forma da lista classificada 304 e anel correspondente 306. O espaço ID da lista classificada 304 está na faixa de 0 a 28-1 (ou .255). Isso é, b=2 e n=8. Dessa forma, os nós apresentados na figura 3 recebem IDs em uma faixa de 0 a 255. A lista classificada 304 utiliza uma relação binária que é reflexiva, anti- simétrica, transitiva, total e definida através do domínio das identidades de nó. Ambas as extremidades da lista classificada 304 são unidas, formando, assim, o anel 306. Isso possi- bilita que cada nó na figura 3 veja a si mesmo como estando no centro da lista classificada .304. A lista classificada 304 é conectada duplamente de forma que qualquer nó possa atra- vessar a lista classificada 304 em qualquer direção. A aritmética para atravessar a lista clas- sificada 304 (ou anel 306) é realizada por módulo 28. Dessa forma, 255 (ou o final da lista classificada 304) + 1 = 0 (ou o começo da lista classificada 304).

A tabela de direcionamento indica que o sucessor de ID 64 é ID 76 (o ID imediata- mente no sentido horário do ID 64). O sucessor pode mudar, por exemplo, quando um novo nó (por exemplo, com um ID de 71) se une ou um nó existente (por exemplo, ID 76) deixa a infra-estrutura de federação. Da mesma forma, a tabela de direcionamento indica que o pre- decessor do ID 64 é ID 50 (o ID imediato no sentido anti-horário do ID 64). O predecessor pode mudar, por exemplo, quando um novo nó (por exemplo, com um ID igual a 59) se une ou um nó existente (por exemplo, ID 50) deixa a infra-estrutura de federação.

A tabela de direcionamento indica adicionalmente que um conjunto de nós vizinhos ao ID 64 possui IDs 83, 76, 50 e 46. Um conjunto de nós vizinhos pode ser um número es- pecificado de nós (isso é, o tamanho da vizinhança v) que estão dentro de uma faixa especi- ficada (isso é, faixa vizinha u) do ID 64. Uma variedade de diferentes tamanhos de vizinhan- ça e faixas de vizinho, tal como, por exemplo, V=4 e U=10, pode ser potencialmente utiliza- da para identificar o conjunto de nós vizinhos. Um conjunto de vizinhança pode mudar, por exemplo, quando os nós se unem ou deixam a infra-estrutura de federação ou quando o número especificado de nós ou faixa especificada é alterado. A tabela de direcionamento indica adicionalmente que ID 64 pode direcionar para os nós possuindo IDs 200, 2, 30, 46, 50, 64, 64, 64, 64, 76, 83, 98, 135 e 200. Essa lista é gerada pela identificação do nó mais próximo de cada número no conjunto de id +/- 2' onde i = (1,2, 3, 4, 5, 6, 7). Isso é, b=2 e n=8. Por exemplo, o nó possuindo ID 76 pode ser identifi- cado a partir do cálculo do nó mais próximo a 64 + 23 ou 72.

Um nó pode direcionar as mensagens (por exemplo, solicitações para acesso aos recursos) diretamente para um nó predecessor, um nó sucessor, qualquer nó em um conjun- to de nós vizinhos, ou qualquer nó de direcionamento. Em algumas modalidades, os nós implementam uma função de direcionamento numérico para direcionar as mensagens. Des- sa forma, RouteNumerically(V, Msg) pode ser implementado no nó X para distribuir Msg para o nó Y na federação cuja ID é numericamente mais próximo de V, e retorna o ID do nó Y para o nó X. Por exemplo, o nó possuindo ID 64 pode implementar RouteNumericaIIy (243, Msg) para fazer com que uma mensagem seja direcionada para o nó possuindo ID 250. No entanto, visto que ID 250 não é um nó de direcionamento para ID 64, ID 64 pode direcionar a mensagem para ID 2 (o nó de direcionamento mais próximo de 243). O nó pos- suindo ID 2 pode, por sua vez, implementar RouteNumerically(243, Msg) para fazer com que a mensagem seja direcionada (diretamente ou através de nós intermediários adicionais) para o nó possuindo ID 250. Dessa forma, pode ser que a função RouteNumericaIIy seja invocada de forma recursiva com cada invocação direcionando uma mensagem para mais perto do destino.

Vantajosamente, outras modalidades da presente invenção facilitam a divisão de um anel em um anel de anéis ou árvore de anéis com base em uma pluralidade de critérios de proximidade de uma ou mais categorias de proximidade (por exemplo, limites geográfi- cos, características de direcionamento (por exemplo, pulos de direcionamento de IP), domí- nios administrativos, limites organizacionais, etc.). Deve-se compreender que um anel pode ser dividido mais de uma vez utilizando o mesmo tipo de critérios de proximidade. Por e- xemplo, um anel pode ser dividido com base em um critério de proximidade de continentes e um critério de proximidade de países (ambos de uma categoria de proximidade de limites geográficos).

Visto que os IDs podem ser distribuídos de maneira uniforme através de um espaço ID (um resultado de geração de número aleatório) existe uma grande probabilidade de qual- quer segmento determinado de um espaço de ID circular conter nós que pertencem a dife- rentes classes de proximidade desde que essas classes tenham quase que a mesma cardi- nalidade. A probabilidade aumenta ainda mais quando existe um número suficiente de nós para obtenção do comportamento estatístico significativo.

Dessa forma, os nós vizinhos de qualquer nó determinado são tipicamente bem dispersos a partir do ponto de vista de proximidade. Visto que o estado de aplicativo publi- cado pode ser duplicado dentre os nós vizinhos, a informação publicada pode ser bem dis- persa também do ponto de vista de proximidade.

A figura 4 ilustra um anel de anéis 400 que facilita o direcionamento proximal. O anel 401 pode ser observado como um anel principal ou raiz, e contém todos os nós em cada um dos anéis 402, 403 e 404. Cada um dos anéis 402, 403 e 404 contém um subcon- junto de nós do anel 401 que são divididos com base em um critério de proximidade especi- ficado. Por exemplo, o anel 401 pode ser dividido com base na localização geográfica, onde o anel 402 contém nós na América do Norte, o anel 403 contém nós na Europa, e o anel 404 contém nós na Ásia.

Em um espaço numérico contendo 65.536(216) IDs1 o direcionamento de uma men- sagem de um nó Norte Americano possuindo um ID 5.345 para um nó Asiático contendo um ID 23.345 pode incluir o direcionamento da mensagem dentro do nó 402 até que um nó vizi- nho do nó Asiático seja identificado. O nó vizinho pode então direcionar a mensagem para o nó Asiático. Dessa forma, um único pulo (em oposição a múltiplos pulos) é feito entre um nó Norte Americano e um nó Asiático. De acordo, o direcionamento é realizado de forma efici- ente em termos de recursos.

A figura 5 ilustra uma árvore divisória de anéis induzida por proximidade ilustrativa .500 que facilita o direcionamento proximal. Como apresentado, a árvore de divisão de anéis .500 inclui um número de anéis. Cada um dos anéis representa uma divisória de uma lista conectada classificada. Cada anel inclui uma pluralidade de nós possuindo IDs na lista co- nectada classificada. No entanto, por motivos de clareza, devido ao número de nós em po- tencial, os nós não podem ser expressamente apresentados nos anéis (por exemplo, o es- paço ID da árvore divisória 500 pode ser de b=16 e n=40).

Dentro da árvore divisória 500, o anel raiz 501 é dividido em uma pluralidade de sub-anéis, incluindo os sub-anéis 511, 512, 513 e 514, com base no critério 571 (um primei- ro critério de limite de domínio administrativo). Por exemplo, cada componente de um nome DNS pode ser considerado um critério de proximidade com a ordem parcial dentre os mes- mos induzido por sua ordem de aparição no nome DNS lido da direita para a esquerda. De acordo, o sub-anel 511 pode ser dividido adicionalmente em uma pluralidade de sub-anéis, incluindo os sub-anéis 521, 522, e 523, com base no critério 581 (um segundo critério de limite de domínio administrativo).

O sub-anel 522 pode ser adicionalmente dividido em uma pluralidade de sub-anéis, incluindo os sub-anéis 531, 532 e 533, com base no critério 572 (um critério de limite geo- gráfico). O critério de proximidade baseado em localização pode ser parcialmente ordenado ao longo das linhas de continentes, países, códigos postais, e assim por diante. Os códigos postais são propriamente ditos organizados de forma hierárquica significando que podem ser considerados como induzindo adicionalmente uma sub-lista parcialmente ordenada de critérios de proximidade.

O sub-anel 531 pode ser adicionalmente dividido em uma pluralidade de sub-anéis, incluindo os sub-anéis 541, 542, 543 e 544, com base no critério 573 (um primeiro critério de limite organizacional). Uma lista parcialmente ordenada de critério de proximidade pode ser induzida ao longo das linhas de como uma determinada companhia é estruturada de forma organizacional tal como divisões, departamentos, e grupos de produto. De acordo, o sub- anel 543 pode ser adicionalmente dividido em uma pluralidade de sub-anéis, incluindo os sub-anéis 551 e 552, com base no critério 583 (um segundo critério de limite organizacio- nal).

Dentro da árvore divisória 500, cada nó possui um único ID e participa dos anéis ao longo de um percurso divisório correspondente começando na raiz até a folha. Por exemplo, cada nó participante do sub-anel 552 também participará dos sub-anéis 543, 531, 522, 511 e da raiz 501. O direcionamento para um nó de destino (ID) pode ser realizado pela imple- mentação de uma função RouteProximaIIy, como se segue:

RouteProximally(V, Msg, P): De acordo com um valor V a partir do domínio das i- dentidades de nó e uma mensagem "Msg", distribuir a mensagem para o nó Y cuja identida- de pode ser mapeada para V entre os nós considerados equivalentes pelo critério de proxi- midade P.

Dessa forma, o direcionamento pode ser realizado pelo movimento progressivo pa- ra mais perto do nó de destino dentro de um anel determinado até que nenhum progresso adicional possa ser feito pelo direcionamento dentro desse anel como determinado a partir da condição de que o nó de destino se encontra entre o nó atual e seu nó sucessor ou pre- decessor. Nesse ponto, o nó atual começa a direcionar através de seus nós parceiros no próximo anel maior no qual participa. Esse processo de movimentação progressiva na dire- ção do nó de destino pela subida ao longo do percurso divisório na direção do anel raiz ter- mina quando o nó mais próximo do nó de destino é alcançado dentro do contexto proximal solicitado, como originalmente especificado na invocação RouteProximaIIy.

Os pulos de direcionamento podem permanecer na vizinhança proximal do nó que originou a solicitação até que nenhum progresso adicional possa ser feito dentro dessa vizi- nhança visto que o nó de destino está fora da mesma. Nesse ponto, o critério de proximida- de é relaxado para aumentar o tamanho da vizinhança proximal para se realizar progresso adicional. Esse processo é repetido até que a vizinhança proximal seja suficientemente ex- pandida para incluir o nó de destino (ID). O pulo de direcionamento realizado após cada re- laxamento sucesso do critério de vizinhança proximal pode ser um pulo potencialmente mai- or no espaço proximal enquanto tornando um pulo correspondentemente menor no espaço numérico em comparação com o pulo anterior. Dessa forma, apenas o número absoluta- mente necessário de tais pulos (inter-anel) é realizado antes de o destino ser alcançado. Pode ser o caso de alguns pulos serem evitados para mensagens de consulta visto que os dados de aplicativo publicados são duplicados pela árvore divisória quando são du- plicados entre os nós vizinhos do nó de destino.

Para se realizar o direcionamento proximal, cada nó de federação mantém as refe- rências de seus nós sucessor e predecessor em todos os anéis nos quais participa como um membro (similar ao sucessor ou predecessor para um único anel) - o predecessor proximal, o sucesso proximal, e a vizinhança proximal. A fim de se tornar o direcionamento eficiente, os nós também podem manter a referência de outros nós mais próximos de uma distância exponencialmente crescente em qualquer metade do anel como parceiros de direcionamen- to (similar aos nós de direcionamento para um único anel). Em algumas modalidades, os nós parceiros de direcionamento que se encontram entre um par de nós sucessor ou prede- cessor consecutivos participam do mesmo anel mais baixo compartilhado pelo nó atual e o nó numericamente mais próximo do mesmo entre os pares de nó sucessor e predecessor, respectivamente. Dessa forma, os pulos de direcionamento na direção de um nó de destino transitam utilizando um critério de proximidade relaxado (isso é, transitam para um anel mais alto) apenas quando absolutamente necessário para se realizar progresso adicional. De a- cordo, as mensagens podem ser eficientemente encontradas com um nó de federação cor- respondente.

Em algumas modalidades, os nós implementam uma função de direcionamento proximal para direcionar as mensagens com base nas relações de critérios d equivalência. Dessa forma, de acordo com um número V e uma mensagem "Msg", um nó pode implemen- tar RouteProximaIIy (V, Msg, P) para distribuir a mensagem para o nó Y cuja identidade po- de ser mapeada para V entre os nós considerados equivalentes pelo critério de proximidade Ρ. O critério de proximidade P identifica o anel inferior na árvore divisória que é o antepas- sado comum de todos os nós considerados equivalentes de forma proximal. Pode ser repre- sentado como um cordão obtido pela concatenação do critério de proximidade encontrado ao longo do percurso do anel raiz até o anel identificado pelo mesmo separado pelo caracte- re de separação de percurso 7*. Por exemplo, o critério de proximidade identificando o sub- anel 542 pode ser representado como "Proximity:/.COM/Corp2/LocationA/Div2". Cada anel na árvore divisória 500 pode receber um número singular, por exemplo, por verificação de seu cordão representativo com um algoritmo com base em SHA. Se o número 0 for reserva- do para o anel raiz, pode ser inferido que RouteNumerically(V, Msg)=RouteProximally(V, Msg, 0).

Por exemplo, um nó no sub-anel 544 pode implementar RouteProximaIIy para iden- tificar um nó mais próximo no sub-anel 531 (por exemplo, a um nó no sub-anel 513). Por sua vez, o sub-anel 531 pode implementar RouteProximaIIy para identificar um nó mais próximo no sub-anel 522. Da mesma forma, o sub-anel 522 pode implementar RouteProximaIIy para identificar um nó mais próximo no sub-anel 511. De forma similar, o sub-anel 511 pode im- plementar RouteProximaIIy para identificar um nó mais próximo no anel 501. Dessa forma, pode ser que uma função RouteProximaIIy seja invocada de forma recursiva com cada invo- cação direcionando uma mensagem mais para perto do destino.

Dessa forma, quando o critério de proximidade é levado em consideração, os pulos de direcionamento em um percurso para um destino final podem permanecer dentro da pro- ximidade de um nó que origina uma solicitação, enquanto realizando progresso significativo entre o nó de origem e o nó de destino em um espaço numérico, até que qualquer nó de destino seja alcançado ou nenhum progresso adicional possa ser feito sob o critério de pro- ximidade escolhido, ponto no qual é relaxado apenas o suficiente para se realizar um pro- gresso adicional no sentido do destino. Por exemplo, o critério de proximidade pode ser re- laxado o suficiente para que uma mensagem seja direcionada a partir do anel 531 até o anel .522, etc.

Utilizando-se a abordagem de proximidade acima, é possível se confinar a informa- ção publicada em um anel determinado. Por exemplo, as organizações podem preferir ga- rantir que a informação específica de organização não esteja disponível para entidades fora de seus domínios de confiança (1) implicitamente na forma de duplicação de vizinhança dos nós fora de seus domínios ou (2) explicitamente na forma de solicitações de consulta de serviços para tal informação. O primeiro aspecto é satisfeito pela duplicação da informação publicada apenas entre os nós vizinhos do ID alvo dentro do anel especificado. Visto que todas as mensagens originadas por um nó são direcionadas pela subida sucessiva dos a- néis aos quais pertence na direção do anel raiz, existe uma grande probabilidade de todas as solicitações de consulta originadas dentro de uma organização poderem localizar a in- formação publicada confinada satisfazendo, dessa forma, implicitamente o segundo aspec- to.

Além disso, as organizações não gostam de nós federando automaticamente com nós fora de seu domínio de confiança. Isso pode acontecer, por exemplo, quando um ven- dedor visitante conecta seu computador Iaptop à rede nas instalações do cliente. De forma ideal, o computador Iaptop pertencente ao vendedor deseja localizar a informação publicada em seu domínio doméstico e/ou federar com os nós em seu domínio doméstico começando em seu anel de proximidade preferido mais inferior. Tipicamente não será permitido se fede- rar com os nós no domínio do cliente. Suportar essa situação exige capacidade de localizar os nós semente no domínio doméstico. Tais nós semente podem ser utilizados para se loca- lizar informação publicada no domínio doméstico, para se unir à federação doméstica, e se importar e exportar seletivamente a informação publicada através dos domínios. Os nós se- mente também são algumas vezes referidos como circuitos de acesso de mensagem.

Em outras modalidades, uma entidade publica referências aos nós semente no anel raiz. Os nós semente podem ser publicados no número singular (tal como um obtido por verificação de seu cordão representativo) associado com o anel (como um ID alvo). A infor- mação do nó semente pode se armazenada temporariamente adicionalmente sob demanda pelos nós em vários anéis que estão no percurso dos IDs alvo correspondentes no anel raiz. Tal armazenamento temporário sob demanda fornece o desempenho aperfeiçoado e redu- ção de hotspots que podem ocorrer quando informação semi-estática é consultada com fre- qüência. A informação do nó semente também pode ser obtida através de outros meios tal como DNS.

Para fornecer tolerância à falha para informação publicada confinada, cada nó pode manter um conjunto de nós vizinhos em todos os anéis nos quais participa. De acordo com o exposto acima, o estado mantido por um nó pode ser resumido como se segue:

Um ID que é um valor numérico distribuído uniformemente na faixa de 0 a b"-1. Uma tabela de direcionamento consistindo de (toda a aritmética é feita pelo módulo bn):

Para cada anel, digamos, o anel d, do qual o nó participa O nó sucessor (sd) O nó predecessor (pd) Os nós vizinhos (Pkd. ···P1d. Pd. sd, s1d,.·, Sjd) de forma que Sjd.Sd.id> (id+u/2),j>v/2-1, Pkd-Pd-id<(id-u/2), e k>v/2-1.

Os nós de direcionamento (^rv1),..., r_i, π.....r^) de forma que r+/1i = RouteProximaI- ly(id+/- b', updateMsg, d) de forma que sd<id+b'<sd+1 ou pd+1<id-b'<pd como adequado.

onde b é a base do número, η é o tamanho de campo no número de dígitos, u é a faixa de vizinhança, e ν é o tamanho da vizinhança.

Note-se que um subconjunto de nós vizinhos mantidos por um determinado nó no anel "d" pode aparecer novamente como nós de vizinhança no anel criança "d+1" no qual o nó determinado participa também. Como tal pode-se derivar o limite superior no número total de nós vizinhos mantidos por um determinado nó através de todos os anéis D dos quais participa como D*max(u,v)/2. Isso só considera que apenas uma referência para um nó determinado seja mantida e a pior hipótese para o limite superior seja para uma árvore equilibrada.

Deve-se notar que quando um anel é dividido em uma pluralidade de sub-anéis ir- mãos correspondentes, é possível para um nó especificado participar simultaneamente em mais de um dentre a pluralidade de sub-anéis irmãos correspondentes, por exemplo, através de desalinhamento. O desalinhamento pode ser implementado para associar o estado dife- rente, por exemplo, a partir de subanéis diferentes, com o nó especificado. Dessa forma, apesar de desalinhamentos para um determinado nó possuírem o mesmo ID1 cada desali- nhamento pode ter um estado distinto associado com o mesmo. O desalinhamento permite que o nó especificado participe de múltiplos anéis possuindo distintos critérios de proximida- de que não são necessariamente antepassados comuns de critérios de proximidades mais específicos. Isso é, o nó especificado pode participar em múltiplas ramificações da árvore de proximidade.

Por exemplo, um Iaptop NIC duplo (com ou sem fio) pode ser considerado equiva- lente em termos de proximidade de ambos os nós com e sem fio compartilhando os mesmos segmentos LAN que o laptop. Mas, esses dois critérios de proximidade distintos podem ser modelados como sub-critérios que são aplicáveis apenas após a aplicação de um critério de proximidade de prioridade maior diferente, tal como, por exemplo, um baseado na associa- ção organizacional. Visto que o laptop pertence à mesma organização, os nós desalinhados nos dois subanéis representando 1) associação nos segmentos LAN com fio e 2) associa- ção nos segmentos LAN sem fio se misturam em um único nó no anel que representa a or- ganização à qual o laptop pertence. Deve-se compreender que RouteProximaIIy funcional como esperado sem quaisquer modificações na presença de desalinhamento.

Cada anel proximal pode ser configurado de acordo com parâmetros de anel (po- tencialmente diferentes). Os parâmetros de anel podem ser utilizados para definir uma vizi- nhança (por exemplo, parâmetros de anel podem representar uma faixa de vizinhança, um tamanho de vizinhança, mensagem de ping e padrões de distribuição e temporização de mensagem de partida para mensagens de ping e saída), indicar um mecanismo de federa- ção particular (por exemplo, dentre os primeiro a quarto mecanismos de federação descritos acima previamente descritos ou dentre outros mecanismos de federação), ou definir as par- tes específicas de comunicação entre os parceiros de direcionamento no mesmo anel pro- ximal. Alguns parâmetros de anel podem ser mais gerais, aplicados a uma pluralidade de diferentes mecanismos de federação, enquanto outros parâmetros de anel são mais especí- ficos e se aplicam a um tipo específico de mecanismo de federação.

Os parâmetros de anel utilizados para configurar um anel proximal de nível mais al- to podem ser herdados em algumas modalidades pelos anéis proximais de nível mais baixo. Por exemplo, pode ocorrer que o anel 543 herde alguns dos parâmetros de anel do anel 531 (que, por sua vez, herdou do anel 522, etc.) Dessa forma, um tamanho e faixa de vizinhança associados com o anel 531 também são associados com o anel 541.

No entanto, os parâmetros de anel herdados podem ser alterados e/ou os anéis proximais podem ser configurados individualmente de acordo com diferentes parâmetros de anel. Por exemplo, pode ocorrer de o anel 511 ser destinado ao domínio administrativo que contém um número grande de nós e, dessa forma, o quarto mecanismo de federação descri- to acima é mais adequado para o anel 511. Por outro lado, pode ocorrer de o anel 521 seja destinado para um pequeno negócio com um número relativamente menor de nós, e dessa forma, o segundo mecanismo de federação descrito acima é mais adequado para o anel .521. Dessa forma, os parâmetros de anel associados com o anel 521 podem ser configura- dos para (ou os parâmetros herdades alterados para) valores diferentes dos parâmetros de anel associados com o anel 511. Por exemplo, um parâmetro de anel indicando um tipo par- ticular de mecanismos de federação pode ser diferente entre os anéis 511 e 521. De forma similar, os parâmetros que definem uma vizinhança podem ser diferentes entre os anéis 511 e 521. Adicionalmente, o anel 521 pode ser configurado de acordo com parâmetros especí- ficos que são específicos para o segundo mecanismo de federação descrito acima, enquan- to o anel 511 é configurado de acordo com parâmetros específicos que são específicos do quarto mecanismo de federação descrito acima.

De acordo, anéis proximais podem ser configurados de forma flexível com base nas características (por exemplo, número, recursos incluídos, etc.) dos nós nos anéis proximais. Por exemplo, um administrador pode selecionar parâmetros de anel para anéis proximais utilizando um procedimento de configuração (por exemplo, através de uma interface de usu- ário). Um procedimento de configuração pode facilitar a configuração das relações de he- rança entre os anéis proximais além da configuração dos anéis proximais individuais, tal como, por exemplo, para eliminar os parâmetros de anel herdados de outra forma.

A figura 8 ilustra um fluxograma ilustrativo de um método 800 para dividir os nós de uma infra-estrutura de federação. O método 800 será descrito com relação aos anéis de uma árvore de divisão 500 na figura 5. O método 800 inclui um ato de acessar uma lista co- nectada classificada contendo os IDs do nó que foram designados aos nós em uma infra- estrutura de federação (ato 801). Por exemplo, a lista conectada classificada representada pelo anel 501 pode ser acessada. Os IDs de nó da lista conectada classificada (os nós a- presentados no anel 501) podem representar nós em uma infra-estrutura de federação (por exemplo, infra-estrutura de federação 100).

O método 800 inclui um ato de acessar categorias de proximidade que representam uma pluralidade de critérios de proximidade diferentes para dividir a lista conectada classifi- cada (ato 802). Por exemplo, o critério de proximidade representando os limites de domínio .561, os limites geográficos 562, e os limites organizacionais 563 pode ser acessado. No entanto, outros critérios de proximidade, tal como, limites de domínio de confiança, também podem ser representados no critério de proximidade acessado. As categorias de proximida- de podem incluir listas parcialmente ordenadas e criadas previamente dos critérios de pro- ximidade. Um anel pode ser dividido com base em listas parcialmente ordenadas dos crité- rios de proximidade.

O método 800 inclui um ato de dividir a lista conectada classificada em uma ou mais primeiras sub-listas com base em um primeiro critério de proximidade, cada uma das uma ou mais primeiras sub-listas contendo pelo menos um subconjunto de IDs de nó da lista conectada classificada (ato 803). Por exemplo, o anel 501 pode ser dividido em sub-anéis .511, 512, 513 e 514 com base no critério 571. Cada um dos sub-anéis 511, 512, 513 e 514 pode conter um subconjunto diferente de IDs de nó do anel 501.

O método 800 inclui um ato de dividir uma primeira sub-lista, selecionada dentre as uma ou mais primeiras sub-listas, em uma ou mais segundas sub-listas com base em um segundo critério de proximidade, cada uma das uma ou mais segundas sub-listas contendo pelo menos um subconjunto de IDs de nó contido na primeira sub-lista (ato 804). Por exem- plo, o sub-anel 511 pode ser dividido em sub-anéis 521, 522 e 523 com base no critério 581. Cada um dos sub-anéis 521, 522 e 523 pode conter um subconjunto diferente de IDs de nó do sub-anel 511.

A figura 9 ilustra um fluxograma ilustrativo e um método 900 para preencher uma tabela de direcionamento de nó. O método 900 será descrito com relação à lista conectada classificada 304 e o anel 306 na figura 3. O método 900 inclui um ato de inserção de um nó predecessor em uma tabela de direcionamento, o nó predecessor antecedendo um nó atual com relação ao nó atual em uma primeira direção de uma lista conectada classificada (ato .901). Por exemplo, o nó possuindo ID 50 pode ser inserido na tabela de direcionamento co- mo um predecessor para o nó possuindo ID 64 (o nó atual). Movendo-se em uma direção horária 321 (da extremidade A da lista conectada classificada 304 na direção da extremida- de B da lista conectada classificada 304), o nó possuindo ID 50 antecede o nó possuindo ID .64. A inserção de um nó predecessor pode estabelecer uma parceria simétrica entre o nó atual e o nó predecessor de forma que o nó atual seja um parceiro do nó predecessor e o nó predecessor seja um parceiro do nó atual.

O método 900 inclui um ato de inserção de um nó sucessor na tabela de direciona- mento, o nó sucessos sucedendo o nó atual com relação ao nó atual na primeira direção da lista conectada classificada (ato 902). Por exemplo, o nó possuindo ID 76 pode ser inserido na tabela de direcionamento como um sucessor para o nó possuindo ID 64 (o nó atual). Mo- vendo-se em uma direção anti-horária 322, o nó possuindo ID 76 sucede o nó possuindo ID .64. A inserção de um nó sucessor pode estabelecer uma parceria simétrica entre o nó atual e o nó sucessor de forma que o nó atual seja um parceiro do nó sucessor e o nó sucessor seja um parceiro do nó atual.

O método 900 inclui um ato de inserção de nós de direcionamento adequados na tabela de direcionamento, os nós de direcionamento identificados a partir da lista conectada classificada em ambas as primeira e segunda direções com base na base de número e ta- manho de campo do espaço ID para a infra-estrutura de federação, os nós de direcionamen- to representando um índice logarítmico da lista de conexão classificada em ambas as pri- meira e segunda direções (ato 904). Por exemplo, os nós possuindo IDs 200, 2, 30, 46, 50, .64, 64, 64, 64, 64, 76,83, 98, 135 e 200 podem ser inseridos na tabela de direcionamento como nós de direcionamento para o nó possuindo ID 64. Com base na base do número 2 e no tamanho de campo de 8 dos nós possuindo IDs 64, 64, 76, 83, 98, 135 e 200 pode ser identificado na direção 321 e dos nós possuindo IDs 64, 64, 50, 46, 30, 2 e 200 pode ser identificado na direção 322. Como representado dentro do anel 306, os nós de direciona- mento representam um índice logarítmico da lista de conexão classificada 304 em ambas a direção horária 321 e direção anti-horária 322. A inserção de um nó de direcionamento pode estabelecer uma parceria simétrica entre o nó atual e o nó de direcionamento de forma que o nó atual seja um parceiro do nó de direcionamento e o nó de direcionamento seja um par- ceiro do nó atual.

A figura 7 ilustra um fluxograma ilustrativo e um método 700 para preencher uma tabela de direcionamento de nó que leva os critérios de proximidade em consideração. O método 700 será descrito com relação aos anéis na figura 5. O método 700 inclui um ato de inserção de um nó predecessor para cada anel de direcionamento dividido de forma hierár- quica do qual o nó atual participa dentro de uma tabela de direcionamento (ato 701). Cada nó predecessor antecede o nó atual em uma primeira direção (por exemplo, horária) dentro de cada anel de direcionamento dividido de forma hierárquica do qual o nó atual participa. Os anéis de direcionamento divididos de forma hierárquica são divididos de acordo com os critérios de proximidade correspondentes e contêm pelo menos subconjuntos de uma lista conectada bidirecionalmente (e possivelmente toda a lista conectada de forma bidirecional). Por exemplo, pode ser o caso de um nó especificado participar do anel raiz 501 e dos sub- anéis 511, 522, 523, 531 e 542. Dessa forma, um nó predecessor é selecionado para o nó especificado a partir de dentro de cada um dos anéis 501 e dos sub-anéis 511, 522, 523, .531 e 542.

O método 700 inclui um ato de inserção de um nó sucessor para cada anel de dire- cionamento dividido de forma hierárquica do qual o nó atual participa e para dentro da tabela de direcionamento (ato 702). Cada nó sucessor sucedendo o nó atual na primeira direção dentro de cada anel de direcionamento dividido de forma hierárquica do qual o nó atual par- ticipa. Por exemplo, um nó sucessor é selecionado para o nó especificado a partir de dentro de cada um dos anéis 501 e sub-anéis 511, 522, 523, 531 e 542.

O método 700 inclui um ato de inserção dos nós de vizinhança adequados para ca- da anel de direcionamento dividido de forma hierárquica do qual o nó atual participa dentro da tabela de direcionamento (ato 703). Os nós vizinhos podem ser identificados em ambas a primeira direção (por exemplo, horária) e em uma segunda direção oposta (por exemplo, anti-horária) com base em uma faixa de vizinhança e tamanho de vizinhança a partir dos anéis de direcionamento divididos de forma hierárquica dos quais o nó atual participa. Por exemplo, os nós vizinhos podem ser identificados para o nó especificado a partir de dentro de cada um os anéis 501 e sub-anéis 511, 522, 523, 531 e 542.

O método 700 inclui um ato de inserção dos nós de direcionamento adequados pa- ra cada anel de direcionamento dividido de forma hierárquica do qual o nó atual participa para dentro da tabela de direcionamento (ato 704). Por exemplo, os nós de direcionamento podem ser identificados para o nó especificado a partir de dentro de cada um dos anéis 501 e sub-anéis 511, 522, 523, 531 e 542.

Em algumas modalidades, os nós de direcionamento adequados são inseridos para cada anel de proximidade d exceto pelo anel laminado (ou anéis laminados nas modalida- des que utilizam desalinhamento), do qual o nó Y participa. Os nós de direcionamento ade- quados podem ser inseridos com base nas seguintes expressões:

se Y.sd.id<Y.id+b'<Y.sd+1.id for verdadeiro, então utilizar anel d; ou

se Y.pd.id<Y.id-b'<Y.pd+1.id for verdadeiro, então utilizar o anel d.

Se um anel não tiver sido identificado na etapa anterior, utilizar o anel dianteiro (por exemplo, anel 501) como o anel d. Agora, o anel d é o anel de proximidade no qual o nó Y deve buscar o parceiro de direcionamento mais próximo de z.

A figura 10 ilustra um fluxograma ilustrativo de um método 1000 para o direciona- mento de uma mensagem na direção de um nó de destino. O método 1000 será descrito com relação à lista conectada classificada 304 e o anel 306 na figura 3. O método 1000 in- clui um ato de um nó de recebimento receber uma mensagem juntamente com um número indicando um destino (ato 1001). Por exemplo, o nó possuindo ID 64 pode receber uma mensagem indicando um destino de 212.

O método 1000 inclui um ato de determinação de que o nó de recebimento é pelo menos um numericamente mais distante do destino o que um nó predecessor correspon- dente e numericamente mais distante do destino do que um nó sucessor correspondente (ato 1002). Por exemplo, na direção 322, ID 64 está mais distante do destino 212 do que ID50 e, na direção 321, ID 64 está mais distante do destino 212 do que ID 76. O método 1000 inclui um ato de determinação de que o destino não está dentro de um conjunto vizinho de nós correspondente de nós correspondendo ao nó e recebimento (ato 1003). Por exemplo, o nó com ID 64 pode determinar que o destino 212 não está dentro do conjunto vizinho de 83,76, 50 e 46.

O método 1000 inclui um ato de identificação de um nó intermediário a partir de uma tabela de direcionamento correspondente ao nó de recebimento, o nó intermediário sendo numericamente mais próximo do destino do que outros nós de direcionamento na tabela de direcionamento correspondente (ato 1004). Por exemplo, o nó possuindo 64 pode identificar o nó de direcionamento possuindo ID 200 como sendo numericamente mais pró- ximo do destino 212 do que os outros nós de direcionamento. O método 1000 inclui um ato de envio de mensagem para o nó intermediário (ato 1005). Por exemplo, o nó possuindo ID64 pode enviar a mensagem para o nó possuindo ID 200.

A figura 11 ilustra um fluxograma ilustrativo de um método 1100 para o direciona- mento de uma mensagem no sentido de um nó de destino com base nos critérios de proxi- midade. O método 1100 será descrito com relação aos anéis na figura 4 e na figura 5. O método 1100 inclui um ato de um nó de recebimento receber uma mensagem juntamente com um número indicando um destino e um critério de proximidade (ato 1101). O critério de proximidade define uma ou mais classes de nós. O nó de recebimento recebe a mensagem como parte de uma classe atual de nós selecionada a partir de uma ou mais classes de nós com base no critério de proximidade. Por exemplo, o nó possuindo ID 172 pode receber uma mensagem indicando um destino de 201 e o critério de proximidade indicando que o nó de destino é parte das classes representadas pelo anel 401. O nó possuindo ID 172 pode receber a mensagem como parte do anel 404.

O método 1100 inclui um ato de determinação de que o nó de recebimento é pelo menos um dentre, numericamente mais distante do destino do que um nó predecessor cor- respondente e numericamente mais distante do destino do que um nó sucessor correspon- dente, dentre os nós em uma classe selecionada de nós (ato 1102). Por exemplo, dentro do anel 404, o nó com ID 172 está mais distante do destino 201 do que o nó possuindo ID 174 na direção horária e está mais distante do destino 201 do que o nó possuindo ID 153 na direção anti-horária.

O método 1100 inclui um ato de determinação de que o destino não está dentro do conjunto de nós de vizinhança do nó de recebimento para qualquer uma das uma ou mais classes de nós definidas pelo critério de proximidade (ato 1103). Por exemplo, o nó possu- indo ID 172 pode determinar que o destino 201 não está em um conjunto vizinho correspon- dente no anel 404 ou no anel 401.

O método 1100 inclui um ato de identificação de um nó intermediário a partir da ta- mais próximo do destino do que outros nós de direcionamento na tabela de direcionamento (ato 1104). Por exemplo, o nó possuindo ID 172 pode identificar o nó possuindo ID 194 co- mo estando numericamente mais próximo do destino 201 do que outros nós de direciona- mento no anel 404. O método 1100 inclui um ato de envio de mensagem para o nó interme- diário (ato 1105). Por exemplo, o nó possuindo ID 172 pode enviar a mensagem recebida para o nó possuindo ID 194. O nó possuindo ID 172 pode enviar a mensagem recebida para o nó possuindo ID 194 para honrar uma lista parcialmente ordenada definida previamente de critério de proximidade.

O nó 194 pode estar tão perto do destino 201 possível dentro do anel 404. Dessa forma, a proximidade pode ser relaxada o suficiente para permitir o direcionamento adicional no sentido do destino no anel 401 no próximo trecho. Isso é, o direcionamento é transitado do anel 404 para o anel 401 visto que nenhum progresso adicional no sentido do destino pode ser realizado no anel 404. Alternativamente, pode ser o caso de o nó possuindo ID 201 estar na vizinhança do nó possuindo ID 194 no anel 401 resultando em nenhum direciona- mento adicional. Dessa forma, em algumas modalidades, o relaxamento do critério de pro- ximidade para obtenção do próximo anel mais alto é suficiente para causar direcionamento adicional.

No entanto, em outras modalidades, o relaxamento incrementado dos critérios de proximidade causando a transição para o próximo anel mais alto continua até que o direcio- namento adicional possa ocorrer (ou até que o anel raiz seja encontrado). Isso é, uma plura- lidade de transições para anéis superiores ocorre antes de o progresso adicional de direcio- namento poder ser realizado. Por exemplo, com referência agora à figura 5, quando nenhum progresso de direcionamento adicional pode ser realizado no anel 531, os critérios de pro- ximidade podem ser relaxados o suficiente para transitar para o anel 511 ou mesmo para o anel raiz 501.

Fases de Nó

Um nó participante de uma infra-estrutura de federação pode operar em diferentes fases operacionais. Os valores de fase válidos para um nó podem ser definidos como sendo membros de um conjunto ordenado. Por exemplo, {ID de nó}.{ID de caso}.{Valor de Fa- se[Valores de Estado de Fase: Inserção, Sincronização, Direcionamento, Opera- ção].[Indicação de fase desconhecida: fase conhecida no momento da transmissão, fase desconhecida no momento da transmissão]} define um possível conjunto ordenado repre- sentando um espaço de fase de um nó determinado dentro de uma infra-estrutura de fede- ração. Um caso de nó pode transitar (ou avançar) através dos estados de fase do nó de In- serção para Sincronização para Direcionamento para Operação na ordem. Adicionalmente, em algumas modalidades, um caso de nó pode ser configurado de modo que o caso de nó seja impedido de transitar de volta para um estado de fase de nó anterior. Em algumas mo- dalidades, um nó avança seu ID de caso cada vez que o nó aparece.

Por exemplo, um caso de nó pode ser impedido de transitar de Direcionamento de volta para Sincronização (ou de volta para Inserção), etc. De acordo, em algumas modalida- des, quando é sabido que um determinado caso de nó (por exemplo, identificado por (ID de nó, ID de caso)) foi avançado para um estado de fase de nó particular (por exemplo, Opera- ção), é sabido também que o caso de nó determinado não deve (e em algumas modalidades não irá) reverter para um estado de fase de nó anterior (por exemplo, de volta para Direcio- namento; Sincronização ou Inserção). Dessa forma, existe uma probabilidade significativa de qualquer caso de nó em uma fase de nó anterior ao estado de fase de nó particular ser um caso novo (e avançado) do nó.

Em algumas modalidades, a informação de fase e Ids de caso correspondentes (que avançam à medida que um nó surge) são transferidos juntos. Dessa forma, é possível se determinar que um estado de fase de nó inferior para o mesmo caso seja mais antigo. Adicionalmente, quando um caso de nó mais recente é conhecido (em qualquer um dos va- lores de estado de nó) qualquer informação sobre os casos mais antigos é considerada de- satualizada.

De tempos em tempos, os nós podem ser reinicializados ou perder comunicação um com o outro, tal como, por exemplo, quando é inicializado pela primeira vez, através de uma partida graciosa, ou como resultado de um encerramento anormal (quebra). Dessa forma, existe um potencial para um nó em qualquer estado de fase de nó ser reinicializado ou perder comunicação com outros nós. Por exemplo, uma quebra pode fazer com que um nó em um estado de fase Direcionamento seja reinicializado. Durante uma reinicialização ou perda de comunicação, pode não haver forma de se determinar o estado de fase de nó no qual o nó se encontra. De acordo, quando um nó está sendo reinicializado ou a comunica- ção com um nó foi perdida, um [Indicação de Fase Desconhecida] pode ser configurado pa- ra indicar que o estado de fase para o nó é atualmente desconhecido. No entanto, qualquer estado de fase detectado e/ou expressado anteriormente para o nó pode ser mantido e não é perdido.

O [Indicação de Fase Desconhecida] pode ser utilizado para indicar se um estado de fase era conhecido no momento em que um valor de estado de fase foi transmitido (por exemplo, o valor de fase com fase desconhecida não configurado) ou se um estado de fase é um estado de fase expressado previamente e o estado de fase não era conhecido no mo- mento em que o estado de fase foi transmitido (por exemplo, o valor de fase com fase des- conhecida configurado). Dessa forma, a fase de um nó (seu valor de fase) pode se repre- sentada utilizando-se ambos um valor de estado de fase e um indicação de fase desconhe- cida.

Protocolo de Adesão

De tempos em tempos, os nós podem aderir e deixar federações existentes. Os nós podem implementar os protocolos adequados para aderir e deixar as federações. Por exem- plo, um nó pode implementar uma função Adesão() para se tornar parte de uma federação existente. Um nó implementando a função Adesão() Poe transitar através de três estados de fase ordenados: um estado de fase de inserção, um estado de fase de sincronização, e um estado de fase de direcionamento antes de alcançar o estado de fase operacional final. Em outras modalidades, esses estados de fase de ordem específica podem não existir enquanto outros podem ser definidos. A figura 12a ilustra um exemplo de um nó estabelecendo asso- ciação dentro de uma infra-estrutura de federação. A figura 12b ilustra um exemplo dos nós em uma infra-estrutura de federação permutando mensagens.

Fase de Inserção: Um nó, Y, entra nesse estado de fase emitindo uma mensagem de adesão, incluindo pelo menos seu ID de nó e indicando uma ação de adesão à federa- ção. Uma mensagem de adesão pode ser uma mensagem direcionada enviada por um nó recém aderido (nó Y) com seu destino configurado para a identidade do nó recém aderido. Nesse estado de fase, um nó recém aderido é inserido entre seus nós predecessor e suces- sor na federação. O estado de fase de inserção pode se implementado de açodo com o al- goritmo a seguir (Toda a aritmética é realizada pelo módulo bn).

IP1 Y identifica um nó existente que já é parte de um anel mais inferior do qual o nó que está aderindo deseja participar na federação. Isso pode ser estaticamente configurado ou dinamicamente descoberto utilizando DHCP e/ou DNS e/ou WS-Discovery ou uma cons- tante (potencialmente bem conhecida). Considere-se o nó de federação existente como sendo E.

IP2. Y invoca E.RouteNumerically(Y, JoinMsg) para determinar o nó X cujo ID é numericamente mais próximo de Y.id em cada anel de proximidade do qual o nó Y participa. Isso pode incluir o direcionamento de uma mensagem de adesão a múltiplos nós.

IP3. Determinar os nós sucessor (s) e predecessor (p) numéricos. (Note-se que os dados necessários para se realizar a inserção a seguir podem ser transportados na mensa- gem de adesão e sua resposta. Como tal, não existem viagens adicionais necessárias).

Caso 1: X.id>Y.id

Y.s=X, Y.p=X.p, X.p.s=Y, e X.p = Y

Caso 2: X.id<Y.id

Y.p=X, Y.s = X.s, X-S.p = Y, e X.s = Y

Em resposta à mensagem de adesão, o nó X (o nó que processou a mensagem de adesão) pode enviar uma resposta de adesão de volta para o nó Υ. A resposta de adesão pode indicar o nó predecessor (Y.p) e o nó sucessor (Y.s) para o nó Υ. O nó Y pode receber a resposta de adesão e processar a resposta de adesão para tomar ciência de seus nós predecessor e sucessor. Depois do processamento da resposta de adesão, o nó Y pode ser um participante de direcionamento fraco na federação. Por exemplo, o nó Y pode simples- mente enviar a mensagem enviada para o mesmo, para seus nós predecessor ou sucessor. Dessa forma, o nó Y é inserido na infra-estrutura de federação, mas as tabelas de direcio- namento e vizinhança não são preenchidas. Antes de alcançar esse ponto, o nó Y solicitará que outros nós enviando suas mensagens que redirecionem as mensagens enviadas para o mesmo através de um nó diferente pelo retorno de uma mensagem de situação para o nó remetente indicando que a fase de vivacidade do nó Y está em um estado de fase de inser- ção.

Geralmente, de tempos em tempos, os nós podem permutar mensagens de solici- tação e resposta de sincronização. As mensagens de solicitação e resposta de sincroniza- ção podem incluir informação de vivacidade (por exemplo, cabeçalhos) para outros nós do ponto de vista do remetente. O estado de vizinhança pode ser incluído também nas mensa- gens de solicitação e reposta de sincronização de forma que as camadas de aplicativo em uma vizinhança estejam cientes sobre o estado um do outro. Um exemplo de quando as mensagens de solicitação e resposta de sincronização são permutadas é durante um estado de fase de sincronização de um nó de adesão. No entanto, as mensagens de solicitação e resposta de sincronização podem ser permutadas durante outros estados de fase operacio- nais também (por exemplo, enquanto no estado de fase operacional).

A figura 16 apresenta um exemplo de um modelo de mensagem e modelo de pro- cessamento relacionado 1600. Como apresentado na figura 16, um nó pode enviar e rece- ber mensagens de solicitações de sincronização. Por exemplo, a mensagem de solicitação de sincronização 1601 pode ser recebida na camada de função 1651 de um nó recém inse- rido (por exemplo, o nó na figura 12b possuindo ID 144). Dados de aplicativo 1602 (por e- xemplo, assinaturas de espaço de nome), podem ser carregados na mensagem de solicita- ção de sincronização 1601. A camada de função 1651 pode informar à camada de aplicativo .1652 sobre quaisquer dados de aplicativo incluídos nas mensagens de solicitações de sin- cronização. Por exemplo, a camada de função 1651 pode invocar o evento de sincronização de estado de vizinhança 1603, incluindo dados de aplicativo 1602, para a camada de aplica- tivo 1652. A solicitação de sincronização 1631, incluindo dados de aplicativo 1607, também pode ser enviada para outro nó que processa a solicitação de sincronização 1631 similar ao processamento da solicitação de sincronização 1601 no modelo de processamento 1600.

Em resposta a algum evento de camada de função (por exemplo, mensagem de so- licitação de sincronização 1601, mensagem de resposta de sincronização 1641, ou mensa- gem ping 1612) a camada de função 1651 pode invocar a função de solicitação de estado de vizinhança 1604 na camada de aplicativo 1652. A solicitação de estado de vizinhança .1604 é uma solicitação para que a camada de aplicativo obtenha o estado que precisa ser propagado na vizinhança. Em resposta à solicitação de estado de vizinhança 1604, a cama- da de aplicativo 1652 pode suprir o estado de vizinhança 1606, incluindo dados de aplicativo opcionais 1607, para a camada de função 1651. Alternativamente, a camada de aplicativo .1652 pode enviar o estado de vizinhança 1606, incluindo os dados de aplicativo opcionais .1607 em reação a algum evento da camada de aplicativo. Utilizando mecanismos internos similares aos acima, a camada de função 1651 pode enviar a mensagem de resposta de sincronização 1608, incluindo dados de aplicativo opcionais 1607, para propagar o estado de vizinhança de camada de aplicativo.

Fase de Sincronização: Depois do processamento de uma mensagem de resposta de adesão, um nó Y transita do estado de fase de inserção para o estado de fase de sincro- nização (Syncing). No estado de fase de sincronização, o nó Y recém inserido sincroniza a informação com os nós na vizinhança. Geralmente, o nó Y pode enviar mensagens de sin- cronização para pelo menos seus nós predecessor e sucessor identificados no estado de fase de inserção. Esses nós processando as mensagens de sincronização podem retornar as respostas que indicam os nós parceiros vizinhos e de direcionamento correspondentes desses nós de processamento. Em um exemplo mais específico, o estado de fase de sin- cronização pode ser implementado de acordo com o algoritmo a seguir (Toda a aritmética realizada pelo módulo bn):

SP1. Computar o nó vizinho (Y) a partir da união dos nós vizinho (Y.s) e Vizinho (Y.p) em cada anel proximal do qual o nó Y participa. A computação da união pode ser reali- zada como se segue:

(Sj.....S1, s, p, p1.....pk) de forma que Sj.s.id>(Y.id+u/2),j>v/2-1, pk.p.id<(Y.id-u/2), e k > v/2-1.

SP2. Com referência breve à figura 16, pesquisar a camada de aplicativo local do Y (por exemplo, camada de aplicativo 1652) através de uma solicitação de estado de vizi- nhança (por exemplo, solicitação de estado de vizinhança) 1604 para obtenção dos dados de vizinhança específicos de aplicativo opcionais (por exemplo, dados específicos de aplica- tivo 1607).

SP3. Enviar a mensagem de sincronização para pelo menos os nós sucessor e predecessor proximais incluindo pelo menos a informação do estado de vivacidade de cada nó parceiro vizinho e de direcionamento proximal da perspectiva de Y. Quaisquer dados de vizinhança específicos de aplicativo opcionais (por exemplo, dados de aplicativo 1607) a- cessado através de SP 2 é incluído na solicitação de sincronização 1631.

SP3. Y recebe as mensagens de resposta de sincronização de volta dos nós pro- cessando as mensagens de sincronização em SP2. Por exemplo, o nó Y pode permutar mensagens de sincronização (solicitação/resposta) com um ou mais nós dentro de sua vizi- nhança computada. Depois que as mensagens de sincronização são permutadas com pelo menos um e potencialmente todos os nós vizinhos do nó Y, os nós vizinhos computados podem permutar mensagens adicionais para propagar os dados sincronizados. Uma men- sagem sincronizada (solicitação ou resposta) pode ser uma mensagem não direcionada en- viada por um nó para sincronizar de forma pró-ativa seus dados com um nó alvo, isso é, por exemplo, na vizinhança dos nós.

SP4. À medida que a mensagem de resposta de sincronização em SP3 é recebida (por exemplo, mensagem de resposta de sincronização 1641), quaisquer dados vizinhos específicos de aplicativo opcionais presentes nessas mensagens de resposta de sincroniza- ção recebidas (por exemplo, dados de aplicativo 1622) podem ser oferecidas para a camada de aplicativo de Y 1652 através do evento de sincronização do estado da vizinhança 1603.

Como parte do estado de fase de sincronização, os nós sucessor proximal (por e- xemplo, Y.s) e predecessor (Y.p) permutam suas tabelas de direcionamento com o nó re- cém inserido (por exemplo, Y). Os nós que recebem as mensagens de sincronização podem responder enviando respostas de sincronização. As respostas de sincronização transportam dados similares às mensagens de sincronização exceto pela perspectiva do nó de resposta. Ambas as mensagens de sincronização e respostas de sincronização podem transportar (ou piggyback) dados de aplicativo. Dessa forma, os dados de aplicativo podem ser propagados entre os nós durante o estado de fase de sincronização. Quando o estado de fase de sin- cronização está completo, o nó pode processar mensagens destinadas ao mesmo, ao invés de simplesmente enviar as mesmas para um sucessor ou predecessor. No entanto, o nó ainda pode ser visualizado como um participante de direcionamento fraco visto que sua ta- bela de direcionamento não está preenchida.

Fase de Direcionamento: Depois de o estado de fase de sincronização estar com- pletado, um nó transita para o estado de fase de direcionamento. No estado de fase de dire- cionamento o nó recém sincronizado (por exemplo, nó Y) computa seus nós de direciona- mento. O estado de fase de direcionamento pode ser implementado de acordo com o algo- ritmo a seguir (toda a aritmética é realizada por módulo bn).

RP1. Se o estado de fase de direcionamento estiver sendo executado como parte do procedimento de equilíbrio (explicado posteriormente), garantir que o nó sucessor (Y.s) e o nó predecessor (Y.p) estejam vivos em cada anel de proximidade do qual o nó Y participa. Se não estiverem vivos, determinar o nó de substituição para os que apresentam falhas es- colhendo um próximo melhor nó sucessor ou predecessor dentre os nós vizinhos no anel em consideração.

RP2. Com 1 < i <n-1 RP2a. computar z = Y.id +/- bi RP2b. Se o anel d não for o de proximidade mais específica, encontrar o anel d de proximidade do qual o nó Y participa e satisfazendo a condição Y.sd.id<Y.id+b'<Y.sd+i.id ou Y.pd.id<Y.id-b'<Y.pd+1.id. Ou torne o anel d o anel de proximidade mais específica. O anel d é o anel de proximidade no qual o nó Y deve buscar o parceiro de direcionamento mais próxi- mo de z. Considere-se Q o nó numericamente mais próximo de z entre Y.sd.r+/.i e Y.pd.r+/.i. Se |Q.id-z| estiver dentro de uma porcentagem configurável de b' (tipicamente 20%), sim- plesmente tornar Y.r+/_i=Q. Se Q.i estiver mais perto de z o que (Y.sd.id+/-b') ou (Y.pd.id+/-b'), isso significa que o nó Y é um nó de direcionamento parceiro melhor para o nó Q no anel de 30 proximidade do que Y.sd ou Y.pd. Portanto, enviar updateMsg para o Nó Q, se ainda não tiver sido enviada, suprindo i e o nó Y como parâmetros de forma que o nó Q possa estabe- lecer o nó Y como seu nó de direcionamento parceiro em r.,.

RP2c. Se esse estado de fase estiver sendo executado como parte do procedimen- to de equilíbrio e se Y.sd.r+/.i.id=Y.pd.r+/.i.id, só existe um nó na faixa numérica entre (Y.sd.id+/-b') e (Y.pd.id+/- b'). Esse nó é um destacado pelo nó de direcionamento r+/., do nó sucessor (ou predecessor). Portanto, simplesmente tornar Y.r+/.j=Y.sd.r+/_u. RP2d. Ou, computador o parceiro de direcionamento Y.r+/_j invocando RouteProxi- mally no nó Q com o conjunto de critério de proximidade ao do anel d. Isso implica em Y.r+/_ i=Q.RouteProximally(z, updateMsg, d).

RP3. Nesse ponto, o nó Y pode processar não apenas as mensagens destinadas ao mesmo, mas também pode direcionar as mensagens.

RP4. Assinar eventos de notificação de vivacidade enviados a partir da camada de aplicativo para os IDs de ponto de extremidade dos nós de direcionamento de parceiro, se isso ainda não tiver sido feito. Além disso, revogar quaisquer assinaturas de evento de viva- cidade estabelecidas anteriormente com a camada de aplicativo para os nós que não são mais nós de direcionamento parceiros. Por exemplo, a assinatura e/ou solicitações de revo- gação podem ser passadas para uma camada de aplicativo (por exemplo, camada de apli- cativo 121) que implementa a lógica de publicação/assinatura para um aplicativo correspon- dente (por exemplo, um aplicativo de espaço de nome). Quando as mensagens de vivacida- de específicas de aplicativo subseqüentes (por exemplo, as que resultam das assinaturas de espaço de nome) são recebidas na camada de aplicativo, notificações (eventos) podem ser empurrados para baixo para outras camadas inferiores (por exemplo, outras camadas inferi- ores 131) para processamento.

A figura 17 apresenta um exemplo de um número de interações de vivacidade que podem ocorrer entre a camada de função 1751 e camada de aplicativo 1752. Como apre- sentado na figura 17, os pontos de extremidade são, por exemplo, tópicos de publica- ção/assinatura (por exemplo, representados por um URL ou URI) representando vários nós e podem ser, por exemplo, nós de infra-estrutura de federação. Eventos de assinatura de vivacidade 1701 pode ser invocado a partir da camada de função 1751 para a camada de aplicativo 1752 para assinar um evento de vivacidade (por exemplo, um tópico de publica- ção/assinatura). Revogar Assinatura de Vivacidade 1702 pode ser invocado a partir da ca- mada de função 1751 para a camada de aplicativo 1752 para revogar uma assinatura de um evento de vivacidade. Desativação de ponto de extremidade 1703 pode ser enviado a partir da camada de aplicativo 1752 para a camada de função 1751 para indicar que um ponto de extremidade pode estar para baixo e fornecer à camada de função 1751 com um ponto de extremidade substituto opcional. O evento de Desativação de Ponto de Extremidade 1703 pode ser enviado de forma assíncrona com base em uma assinatura anterior (por exemplo, Evento de Assinatura de Vivacidade 1701).

Desativação de Nó 1704 pode ser invocado a partir da camada de função 1751 pa- ra a camada de aplicativo 1752 para indicar que a camada de função 1751 (ou alguma outra camada inferior) detectou um nó com falha e opcionalmente fornece à camada de aplicativo .1752 um nó substituto. A camada de aplicativo 1752 pode propagar subseqüentemente que um nó potencialmente com falha foi detectado para outras partes interessadas. O evento de Desativação de Nó 1704 pode ser enviado de forma assíncrona a qualquer momento que a camada de função 1751 ou outra camada inferior detectar um nó potencialmente com falha. Enviar vivacidade 1706 pode ser invocado a partir da camada de aplicativo 1752 para a ca- mada de função 1751 quando a camada de aplicativo 1752 detecta que um nó está desliga- do (por exemplo, a partir do evento de desativação de nó 1704 ou de algum outro mecanis- mo fora de banda). O evento enviar vivacidade 1706 também pode ser invocado de forma assíncrona toda vez que a camada de aplicativo 1752 detectar que um nó está desativado e não depende de qualquer assinatura estabelecida anteriormente (através de assinar vivaci- dade).

Dessa forma, em algumas modalidades, a camada de função 1751 é utilizada de forma recursiva. Por exemplo, a camada de função 1751 pode indicar um interesse em um nó especificado (por exemplo, é o nó acima e abaixo particular) para a camada de aplicativo .1752. A camada de aplicativo 1752 pode formular uma assinatura especifica de aplicativo para notificações relacionadas com o nó especificado e então reutilizar a camada de função .1751 para comunicar a assinatura formulada para a camada de aplicativo correspondente adequada 1752 em outros nós de federação. Por exemplo, se as camadas de aplicativo .1752 dentro dos nós de federação implementarem um comportamento pub/sub de espaços de nome, a camada de função 1751 pode direcionar a assinatura para um gerente de publi- cação/assinatura que gerencia as notificações para o nó especificado - o gerente de publi- cação/assinatura sendo implementado como pelo menos parte do aplicativo 1752 nos nós de federação relacionados. De acordo, a camada de função 1751 é utilizada para direcionar uma assinatura que a camada de função 1751 gerou. Os mecanismos recursivos similares também podem ser utilizados para cancelar assinaturas ou de outra forma indicar que não se tem mais interesse no nó especificado.

Fase Operacional: Depois que o estado de fase de direcionamento está completa- do, um nó transita para o estado de fase operacional. O nó pode permanecer em um estado de fase operacional até que seja desativado (por exemplo, reinicialização). No estado de fase operacional, o nó pode enviar as mensagens de atualização pra os parceiros de dire- cionamento de tempos em tempos. As mensagens de atualização (ambas as solicitações de atualização e as respostas de atualização) podem incluir informação de vivacidade de nó vizinho para o envio de nós (por exemplo, para todos os vizinhos proximais de interesse). Essa informação de vivacidade enviada pode incluir também a de informação de vivacidade do remetente. As mensagens de atualização podem ser mensagens direcionadas originadas por nós para atualizar periodicamente seus nós parceiros de direcionamento. Os dados de aplicativo podem ser piggyback nas mensagens de atualização de forma que os dados de aplicativo possam ser propagados durante as atualizações de parceiros de direcionamento. O destino da mensagem é determinado para a identidade do parceiro de direcionamento perfeito no índice de direcionamento desejado. A propriedade ID de mensagem dessa men- sagem recebe um número de seqüência de aplicativo de forma a permitir que os nós que processam essa mensagem determinem a última mensagem e essa mensagem seja dire- cionada de forma proximal.

Um nó que recebe uma mensagem de atualização pode responder com uma res- posta atualizada. Uma resposta atualizada transporta os mesmos dados que a mensagem atualizada exceto que os dados são da perspectiva do nó que está respondendo. Através da permuta das mensagens de atualização e respostas de atualização os nós podem permutar informação de direcionamento. De tempos em tempos, os nós operacionais podem atualizar os parceiros de direcionamento.

De tempos em tempos, os nós operacionais também podem enviar mensagens ping (por exemplo, mensagens ping 1609e 1611). Uma mensagem ping é uma mensagem de via única enviada por um nó para anunciar periodicamente sua presença e disseminar informa- ção dentro de sua vizinhança sobre seus nós vizinhos/de direcionamento e duplicar os da- dos de aplicativo (por exemplo, carregados).

Um nó de origem pode enviar uma mensagem ping para um ou mais de seus nós vizinhos predecessor e sucessor imediatos. Dessa forma, dependendo do padrão de distri- buição de ping (isso é, quais nós recebem mensagens ping) a informação relacionada com o nó de origem é propagada para outros nós em um anel dentro do nó vizinho do nó de ori- gem. Por exemplo, o nó de origem pode enviar uma mensagem ping apenas para seus nós predecessor e sucessor imediatos e a mensagem ping se propaga para fora a partir da posi- ção (ID de nó) do nó de origem ao longo do anel em ambas as direções para a borda da vizinhança do nó de origem. Alternativamente, o nó de origem pode enviar uma mensagem ping para cada nó η em sua vizinhança em ambas as direções predecessora e sucessora.

Cada nó recebendo uma mensagem ping verifica seu interesse no nó de origem de uma perspectiva de faixa de vizinhança. Se não estive interessado, o mesmo descarta a mensagem ping. Se estiver interessado, processa a mensagem ping e envia a mensagem ping de acordo com seu padrão ping especificado se tal envio for restringido à vizinhança do nó de origem. Por exemplo, depois do processamento de uma mensagem ping um nó de recebimento pode enviar a mensagem ping para pelo menos seu nó sucesso se os nós de envio e origem estiverem em seu conjunto de nó predecessor ou pelo menos seu nó prede- cessor se o nó de envio e de origem estiverem em seu conjunto sucessor.

Dessa forma, a propagação externa das mensagens ping para quando a mensa- gem alcança a borda do conjunto de nó vizinho em torno do nó de origem. A propriedade de ID de mensagem da mensagem ping recebe um número de seqüência de aplicativo de for- ma a permitir que os nós que estão processando essa mensagem determinem a última mensagem do nó de origem e evitem o processamento duplicado ou outro envio desneces- sário. Com referência novamente à figura 16, a mensagem ping 1609 pode ser recebida na camada de função 1651 a partir de um nó vizinho. Os dados de aplicativo 1612 (por e- xemplo, assinaturas de espaço de nome) podem ser carregados na mensagem ping 1609. A camada de função 1651 pode informar à camada de aplicativo 1652 sobre quaisquer dados de aplicativo incluídos nas mensagens ping. De forma similar, a camada de função 1651 pode informar à camada de aplicativo 1652 sobre quaisquer dados de aplicativo incluídos nas mensagens de Solicitação de Sincronização. Ambos esses casos de transferência po- dem ser realizados através do envio de um evento de sincronização de estado de vizinhan- ça 1603, incluindo os dados de aplicativo 1612, para a camada de aplicativo 1652.

Em resposta a algum evento de camada de função (por exemplo ,mensagem ping recebida 1609) a camada de função 1651 pode enviar a solicitação de estado de vizinhança1604 para a camada de aplicativo 1652. A solicitação de estado de vizinhança 1604 é invo- cada na camada de aplicativo 1652 para obtenção do estado que precisa ser opcionalmente propagado na vizinhança. Em resposta à solicitação de estado de vizinhança 1604, a cama- da de aplicativo 1652 pode retornar o estado de vizinhança 1606, incluindo os dados de a- plicativo opcionais 1607, para a camada de função 1651. A camada de função 1651 pode enviara mensagem ping 1611, incluindo os dados de aplicativo opcionais 1607, para propa- gar a informação de vivacidade do nó parceiro de direcionamento e vizinhança além do es- tado de vizinhança de camada de aplicativo opcional. A camada de função 1651 também pode enviar a resposta de sincronização 1608, incluindo os dados de aplicativo opcionais1607, para propagar o estado de aplicativo.

Protocolo de Partida

Quando é adequado para um nó sair de uma federação, o nó pode implementar uma função de Partida para ser graciosamente removido da federação. Um nó parte de uma federação existente enviando uma mensagem de partida para um ou mais de seus nós pre- decessor e sucessor proximais imediatos, e talvez outros nós na mesma vizinhança proxi- mal. Dessa forma, dependendo do padrão de distribuição de partida (isso é, quais nós rece- bem as mensagens de partida) a informação relacionada com o nó de partida é propagada para outros nós em um anel dentro da vizinhança do nó de partida. Uma mensagem de par- tida é uma mensagem de via única originada por um nó que esta graciosamente partindo para informar um ou mais outros nós dentro de pelo menos uma de suas vizinhanças proxi- mais sobre sua partida iminente. O nó de partida propaga a mensagem de partida (por e- xemplo, dentro de sua vizinhança) de forma similar à propagação de mensagens ping. Por exemplo, o nó possuindo ID 30 pode enviar mensagens de partida 1219 para os nós possu- indo IDs 17 e 40. O nó possuindo ID 30 pode então ser removido da infra-estrutura de fede- ração do ponto de vista de um anel proximal determinado. Note-se que é possível que um nó remova a si mesmo de uma vizinhança proximal, mas não outros aos quais pode perten- Visto que os nós possuindo IDs 17 e 40 (isso é, os nós predecessor e sucessor) podem ser os nós mais próximos do ID 30 depois de o nó possuindo ID 30 ser removido, os nós possuindo IDs 17 e 40 são informados sobre a partida do nó possuindo ID 30. Dessa forma, futuras mensagens que devem ser distribuídas para o ID 30 podem ser adequada- mente processadas nos nós possuindo IDs 17 e 40. Os nós possuindo IDs 17 e 40 podem propagar a partida do nó possuindo ID 30 para os outros nós no anel 1206. Na ausência do nó possuindo ID 30, os nós possuindo IDs 17 e 40 também podem recomputar os apontado- res predecessor e sucessor, apontando potencialmente um para o outro. A propriedade de ID de mensagem de uma mensagem de partida recebe o mesmo ID de seqüência de aplicativo que as mensagens Ping de forma a permitir que os nós que estão processando a mensagem de partida determinem a última mensagem dentre uma série de mensagens de ping e partida enviadas por um nó de origem. A partida graciosa de um anel proximal de federação é opcional, mas encorajada. No entanto, a federação é proje- tada no sentido da auto-cura se os nós partirem subitamente.

Vivacidade

Durante a vida útil de uma federação, os nós podem permutar informação de viva- cidade para manter a federação. A informação de vivacidade pode ser incluída em virtual- mente qualquer mensagem que seja permutada dentro de uma federação na forma de Ca- beçalhos de Mensagem Vivacidade. Por exemplo, mensagens de adesão, respostas de a - desão, mensagens de sincronização, respostas de sincronização, mensagens de atualiza- ção, respostas de atualização, mensagens específicas de aplicativo, mensagens de vivaci- dade, e mensagens de ping podem todas incluir cabeçalhos de informação de vivacidade. Quando um nó de federação envia qualquer mensagem ou resposta, o nó pode incluir in- formação de Vivacidade para o processamento por outros nós. A informação de vivacidade pode ser incluída em um cabeçalho de informação de vivacidade da mensagem de vivaci- dade.

A informação de vivacidade indicando o estado de vivacidade de um nó pode ser representada utilizando-se as seguintes propriedades:

[Nó]: Identifica o nó cujo estado de vivacidade está sendo representado. Um nó po- de ser identificado com base em [Propriedades de Referência] que incluem adicionalmente um [ID de caso].

[Propriedades de Referência]: Itens de informação de elemento especificados na especificação WS-addressing. WS-addressing define a propriedade de referência [ID de caso] para inclusão no conjunto de propriedade de referência.

[ID de caso]: Um número que identifica um caso particular de um nó. Uma conta- gem de inicialização incrementada pode ser utilizada como ID de caso de um nó. [Fase]: transporta a fase do nó identificado.

[Valor de Estado de Fase]: Transporta o estado de fase mais alto (inserção, sincro- nização, direcionamento, operação) que o caso de nó indicado tenha alcançado.

[Indicação de Fase Desconhecida]: Um indicador que informa se a fase atual é co- nhecida ou não.

[Frescor]: Informa o frescor da informação e seu valor varia de 0 a MaxFreshness. Quanto maior o valor, mais recente a informação com 0 informando que não há informação e MaxFreshness sendo uma constante definida por protocolo.

[Cor]: Identifica a classe de equivalência de proximidade à qual o nó pertence. Os dois nós com o mesmo valor de cor são sempre considerados senso os mais próximos visto que ambos pertencem à mesma classe de equivalência identificada pelo valor de cor. O número de classes de equivalência de proximidade pode aumentar com o tempo à medida que mais nós se unem à federação.

[Peso]: Supre a métrica de capacidade de nó e seu valor varia de O a MaxWeight. Isso mede as características desejáveis de um nó de federação tal como grande potência de computação, alta largura de banda de rede, e tempo de funcionamento longo. Quanto maior o valor, mais capaz o nó de tornar mais desejável de uma perspectiva de parceria.

Em alguns ambientes, as propriedades [Nó] e [Frescor] de um nó são informadas implícita ou explicitamente em um escopo maior tal como cabeçalhos de mensagem [Ori- gem] e [Remetente] e como tal a inclusão das propriedades acima novamente nos cabeça- lhos de vivacidade será dobrada. Por exemplo, o remetente de uma mensagem só precisa transportar sua informação de fase atual, cor e peso visto que seu ID, Id de caso são supri- dos nos cabeçalhos de endereçamento de mensagem e seu Frescor é subentendido.

O estado de vivacidade pode ser pelo menos parcialmente ordenado com base em uma relação binária "<" definida como se segue:

"L1 < L2" é verdadeiro se

1. "L1[Nó]-[Nome]=L2.[Nó].[Nome]M for verdadeiro e um dos seguintes for verdadei- ro com os testes realizados e curto-circuitado na ordem listada:

L1.[Nó].[Propriedades de Referência].[ID de caso]<L2.[Nó].[Propriedades de Refe- rência].[ID de caso]

L1.[Indicação de Fase Desconhecida]!=verdadeira E L2.[Indicação de Fase Desco- nhecida]!=verdadeira E L1.[Estado de Fase]<L2.[Estado de Fase]

L1 .[Frescor]<L2.[Frescor]

2. Ou "L1.[Cor]=L2.[Cor]" é verdadeiro e um dos seguintes é verdadeiro com os tes- tes realizados e curto-circuitado na ordem listada:

L1.[Estado de Fase]<L2.[Estado de Fase]

L1.[Peso]<L2.[Peso] Adicionalmente, uma mensagem de vivacidade "desativada" pode ser enviada para um nó especificado quando for detectado ou suspeitado que o nó especificado se tornou indisponível (por exemplo, desativado). Como um exemplo, quando uma camada de aplica- tivo (por exemplo, a camada de aplicativo 121) detecta que outra camada de aplicativo (por exemplo, camada de aplicativo 123) ou um nó hospedando outra camada de aplicativo está desativado, a camada de aplicativo de detecção pode notificar outras camadas inferiores (por exemplo, outras camadas inferiores 131) de que o nó pode estar desativado, por exem- plo, de acordo com o modelo de mensagem e modelos de processamento relacionados 1600 e/ou 1700. Tal notificação pode fazer com que outras camadas inferiores, tal como, por exemplo, a camada de função 1651, envie uma mensagem de vivacidade desativada. Esse é apenas um exemplo do estímulo para a geração de mensagens de vivacidade desativada.

Visto que as mensagens de vivacidade desativada são direcionadas e, dessa for- ma, distribuídas para um nó mais próximo dos nós suspeitos de estarem desativados, se uma mensagem de vivacidade desativada para um nó especificado for distribuída de volta para o nó especificado, então o nó especificado nunca foi desativado ou o nó especificado é um caso diferente (por exemplo, com um ID de caso diferente). Por outro lado, se a mensa- gem de vivacidade desativada for distribuída para outro nó, isso indica que o nó especifica- do parece ter sido desativado. De acordo, se o nó que está recebendo a mensagem de vi- vacidade desativada se ver como estando na vizinhança proximal do nó especificado, pode criar uma mensagem de partida para o nó especificado nessa vizinhança proximal como descrito além de indicar para sua camada de aplicativo (por exemplo, utilizando Nó Desati- vado 1704) que o nó especificado pode estar desativado e que o nó de recebimento é seu substituto. Uma mensagem de vivacidade desativada para o nó especificado pode ser dire- cionada de forma proximal com seu ID alvo configurado para o do nó que pode estar desati- vado.

Procedimento de Equilíbrio

As modalidades da presente invenção são projetadas para acomodar grandes nú- meros de nós aderindo e partindo da federação em um curto período de tempo. Tais mu- danças na rede podem causar retardos de direcionamento se as árvores de busca logarítmi- ca mantidas nos vários nós se tornarem desequilibradas. Isso é, se houver mais nós em um lado de um anel do que em outro. Para facilitar a eficiência de direcionamento ideal, os nós participantes de uma federação executam o procedimento de equilíbrio quando determina- dos critérios são correspondidos.

Por exemplo, quando qualquer uma das condições a seguir é verdadeira, qualquer nó pode executar o procedimento de equilíbrio para garantir uma tabela de direcionamento equilibrada para a eficiência ideal de direcionamento:

Um número configurado de mensagens de vivacidade descritas acima for recebido. Uma quantidade configurada de tempo ter passado desde o recebimento da última mensagem de vivacidade descrita acima.

A vizinhança ter mudado no sentido de alguns novos nós terem chegado ou alguns nós existentes terem partido.

O equilíbrio das tabelas de direcionamento é um processo simples. Por exemplo, os nós com uma tabela de direcionamento desequilibrada podem executar novamente os esta- dos de fase de Sincronização e Direcionamento do protocolo de Adesão.

Os atos RP2b, RP2d e RP4 combinados com 1) encontrar o nó de direcionamento mais próximo a um número, 2) o protocolo de partida seguido pelos nós que estão deixando uma federação de forma graciosa, e 3) o procedimento de equilíbrio seguido pelos nós re- cebendo mensagens de vivacidade resultam em um sistema de cura mais rápido quando os nós de federação aderem e partem da rede de forma bem rápida e em grandes números.

Mensagens de Situação

Uma mensagem de situação é uma mensagem não direcionada enviada por um nó receptor para um nó remetente para informar o sucesso/falha do direcionamento de uma mensagem correlacionada que o nó remetente enviou previamente para o nó receptor. A figura 18 apresenta um exemplo de como as mensagens que fazem parte de um padrão de permuta de mensagem de solicitação e resposta são direcionadas através dos nós em um anel. Uma mensagem de situação pode incluir cabeçalhos que identificam a mensagem cor- relacionada original cuja situação de direcionamento está sendo reportada. Como tal, as mensagens de situação podem ser utilizadas entre os nós para indicar que a mensagem foi direcionada com sucesso de um nó para o próximo. Por exemplo, o direcionamento da men- sagem de solicitação 1811 do nó 1801 para o nó 1806 inclui o envio da solicitação 1811 a- través dos nós 1802, 1803, 1804 e 1805. As mensagens de situação de sucesso em cascata correspondentes (situação 1817, 1818, 1819, 1820 e 1821) podem ser enviadas do nó 1806 para o nó 1805, do nó 1805 para o nó 1804, do nó 1804 para o nó 1803, do nó 1803 para o nó 1802, e do nó 1802 para o nó 1801, respectivamente. Em resposta à solicitação 1811, a resposta 1816 pode ser enviada de extremidade para extremidade do nó 1807 para o nó .1801. A resposta 1816 é opcional e pode não existir em um padrão de permuta de mensa- gem de via única.

A figura 13 ilustra um fluxograma ilustrativo de um método 1300 para um nó se unir à infra-estrutura de federação. O método 1300 será descrito com relação ao anel 1206 nas figuras 12a e 12b. O Método 1300 inclui um ato de emissão de uma mensagem de adesão a uma infra-estrutura de federação (ato 1301). Por exemplo, o nó possuindo ID 144 pode emi- tir a adesão 1201 à infra-estrutura de federação incluindo o anel 1206. O método 1300 inclui um ato de recebimento de uma mensagem de adesão de um nó de adesão (ato 1308). Por exemplo, um nó existente na infra-estrutura de federação incluindo o anel 1206 pode rece- ber a adesão 1201.

O método 1300 inclui um ato de direcionamento de uma mensagem de adesão a um nó de processamento (ato 1309). O nó de processamento pode ser um nó possuindo um ID numericamente mais próximo do ID do nó de adesão do que outros nós ativos na infra- estrutura de federação no momento em que a mensagem de adesão está sendo direciona- da. Por exemplo, a adesão 1201 pode inicialmente ser recebida no nó possuindo ID 64, di- recionada para o nó possuindo ID 135 e direcionada para o nó possuindo ID 151.

O método 1300 inclui um ato de computação de um ou mais nós predecessores e um ou mais nós sucessores para o nó de adesão (ato 1310). Por exemplo, o nó possuindo ID 151 pode computar um nó predecessor imediato e um nó sucessor imediato par ao nó possuindo ID 144. Dentro do anel 1206, o nó possuindo ID 151 pode computar que o nó possuindo ID 135 é um nó predecessor imediato e que nó possuindo ID 151 é um nó suces- sor imediato. As computações similares podem ser feitas para outros anéis proximais.

O método 1300 inclui um ato de computação de um ou mais nós de direcionamento para o nó de adesão (ato 1311). Por exemplo, o nó possuindo ID 151 pode computar os nós de direcionamento (do nó possuindo a perspectiva do ID 151) para o nó possuindo ID 144. Dentro do anel 1206, o nó possuindo ID 151 pode computar, por exemplo, que os nós pos- suindo IDs 218 e 40 são nós de direcionamento para o nó possuindo ID 144. Computações similares podem ser feitas para outros anéis proximais.

O método 1300 inclui um ato de envio de uma resposta de adesão para o nó de a- desão (ato 1312). Uma resposta de adesão pode identificar todos os nós predecessor e su- cessor vizinhos e parceiros de direcionamento para o nó de adesão como computador pelo nó de processamento de acordo com sua visão atual da infra-estrutura de federação. Por exemplo, a resposta de adesão 1202 pode identificar pelo menos o nó possuindo ID 135 como o nó predecessor imediato do nó possuindo ID 144, e pode identificar quaisquer nós de direcionamento (para o nó possuindo ID 144) computados no nó possuindo ID 151 para o nó ID 144 (o nó recém aderido).

O método 1300 inclui um ato de recebimento de uma resposta de adesão a partir de um nó de federação que processou a mensagem de adesão (ato 1302). Por exemplo, o nó possuindo UD 144 pode recebera resposta de adesão 1202 do nó possuindo ID 151.

O método 1300 inclui um ato de envio de uma solicitação de sincronização para pe- lo menos cada um dos nós predecessores proximais imediatos e nós sucessores proximais imediatos (ato 1303). Por exemplo, com referência agora à figura 12b, o nó possuindo ID .144 pode enviar solicitações de sincronização 1203 para os nós possuindo IDs 135 e 151. A solicitação de sincronização 1203 pode incluir uma identificação de quaisquer nós vizinhos do nó possuindo ID 144 e/ou uma identificação de quaisquer parceiros de direcionamento do nó possuindo ID 144. Os nós possuindo IDs 135 e 151 podem receber as solicitações de sincronização .1203. Em resposta ao recebimento das solicitações de sincronização 1203, os nós possuin- do IDs 135 e 151 podem identificar os nós vizinhos e os parceiros de direcionamento das tabelas de direcionamento correspondentes. Os nós possuindo IDs 135 e 151 podem incluir a informação de vivacidade dos nós parceiros de direcionamento e vizinhos identificados na resposta de sincronização 1204 e enviar as respostas de sincronização 1204 para o nó pos- suindo ID 144.

O método 1300 inclui um ato de recebimento de uma resposta de sincronização de cada um os nós predecessor e sucessor proximais (ato 1304). Por exemplo, o nó possuindo ID 144 pode receber respostas de sincronização 1204 dos nós possuindo IDs 135 e 151. A resposta de sincronização 1204 pode incluir informação de vivacidade para um ou mais nós no anel 1206 ou outros anéis em uma infra-estrutura de federação. A resposta de sincroni- zação 1204 também pode identificar quaisquer nós parceiros de direcionamento em poten- cial para o nó possuindo ID 144.

O método 1300 inclui um ato de computação dos nós vizinhos (ato 1305). Por e- xemplo, o nó possuindo ID 144 pode computar os nós vizinhos correspondentes com base na união dos nós vizinhos para os nós possuindo IDs 135 e 151. Os nós vizinhos podem ser computados com base em uma visão resumida da mensagem de resposta de adesão e quaisquer mensagens de resposta de sincronização.

O método 1300 inclui um ato de computação dos nós de direcionamento (ato 1306). Por exemplo, o nó possuindo ID 144 pode computar os nós de direcionamento dentre os nós do anel 1206. Os parceiros de direcionamento podem ser computados com base em uma visão resumida da mensagem de resposta de adesão e quaisquer mensagens de resposta de sincronização.

O método 1300 inclui um ato de permuta de pelo menos a informação de nó vizinho com parceiros de direcionamento computados (ato 1307). Por exemplo, o nó possuindo ID .144 e o nó possuindo ID 218 (um parceiro de direcionamento computado) podem permutar informação de estado (por exemplo, ID de caso, estado de fase, etc.) correspondente aos seus nós vizinhos respectivos. Essas permutas são realizadas pelo nó recém aderido dire- cionando uma mensagem de Atualização para pelo menos cada parceiro de direcionamento computado singular como descrito no texto de estado de Fase de Direcionamento acima. Os nós que estão processando a mensagem de Atualização enviarão a mensagem de resposta de Atualização correspondente em resposta ao recebimento dessas mensagens de atuali- zação do nó recém aderido. A resposta de Atualização inclui pelo menos informação de vi- vacidade para si e seus nós vizinhos.

O método 1300 também pode incluir um ato de iniciação de uma propagação inicial das tabelas de direcionamento para pelo menos um nó vizinho. Por exemplo, o nó possuin- do ID 144 pode incluir nós parceiros de direcionamento e vizinhos computados em uma mensagem ping e enviar a mensagem ping para o nó possuindo ID 174 (por exemplo, um dos nós vizinhos computados). O nó possuindo ID 174 pode receber a mensagem ping e atualizar uma tabela de direcionamento correspondente com a informação de vivacidade originada no nó possuindo ID 144. O nó possuindo ID 174 também pode incluir sua tabela de direcionamento correspondente em uma segunda mensagem ping e enviar a segunda mensagem ping em algum ponto futuro para o nó possuindo ID 144. O nó possuindo ID 144 pode receber a segunda mensagem ping e Poe atualizar sua tabela de direcionamento cor- respondente com nós na informação de vivacidade incluída na segunda mensagem ping (isso é, nós na tabela de direcionamento do nó possuindo ID 174). O nó possuindo ID 144 pode repetir o envio das mensagens de ping com outros nós vizinhos no anel 1206. Deve-se compreender que quando um nó recém aderido se une a uma federação, o nó recém aderido pode não encontrar um membro de federação existente e, dessa forma, se torna o único membro. Dessa forma, pode não haver nó predecessor, sucessor ou vizi- nho designado para o nó recém aderido. De acordo, o nó recém aderido é mapeado como o melhor parceiro de direcionamento em todas os casos.

Adicionalmente, apesar de o método 1300 ter sido descrito com relação a um único anel (anel 1206), deve-se compreender que em algumas modalidades um nó que se une a um anel inerentemente também se une a um ou mais outros anéis. Por exemplo, com refe- rência breve de volta à figura 5, um nó que se une ao anel 551 inerentemente se une tam- bém aos anéis 543, 531, 522, 511 e 501. Dessa forma, o método 1300 pode ser implemen- tado para se unir a uma pluralidade de anéis. Em outras modalidades, alguns ou todos os atos no método 1300 podem ser repetidos quando se unindo a múltiplos anéis. Por exemplo, com referência novamente à figura 5, um ou mais atos de 1300 podem ser repetidos quando um nó se une a ambos o anel 551 e ao anel 514 (por exemplo, desalinhamento). Em qual- quer caso, um ID de nó que está se unindo pode ser acessado e utilizado para identificar um nó que está aderindo em uma lista conectada classificada além de sub-listas divididas hie- rarquicamente correspondentes das quais o nó que está se unindo participa. Um nó de re- cebimento é identificado a partir da lista conectada classificada e cada sub-lista dividida. A mensagem de adesão é direcionada para um nó de processamento (por exemplo, com base em ID) na lista conectada classificada e cada sub-lista dividida. Uma resposta de adesão é recebida do nó de processamento na lista conectada classificada e cada sub-lista dividida.

A figura 14 ilustra um fluxograma ilustrativo e um método 1400 para um nó para a manutenção da associação em uma infra-estrutura de federação. O método 1400 será des- crito com relação ao anel 1206. O método 1400 inclui um ato de envio de uma primeira mensagem de ping para um nó vizinho (ato 1401). A primeira mensagem de ping indica que um nó atual enviando a primeira mensagem de ping é vizinho do nó vizinho. A primeira mensagem de ping também pode incluir o estado dos nós parceiro de direcionamento e vizi- nho do nó atual. Por exemplo, o nó possuindo ID 144 pode enviar uma mensagem de ping para o nó possuindo ID 151. Depois do recebimento da primeira mensagem de ping, o nó possuindo ID 151 pode estar ciente de que o nó possuindo ID 144 é um vizinho do nó pos- suindo ID 151. O nó 151 também pode descobrir informação de vivacidade mais recente (para outros nós no anel 1206) do nó 144 como um efeito colateral desse ato.

As mensagens de ping podem ser repetidas periodicamente em uma freqüência especificada com base, por exemplo, no estado da configuração associado com um anel proximal no qual a mensagem ping deve ser enviada. A freqüência pode variar dependendo do estado de configuração. Por exemplo, uma freqüência de ping especificada para uma WAN pode ser diferente da freqüência especificada para uma LAN. As mensagens ping também podem ser enviadas de acordo com um padrão de distribuição de ping. O padrão de distribuição de ping para um nó de origem pode indicar que as mensagens de ping de- vem ser enviadas para os nós vizinhos em ambas as direções em um anel. Por exemplo, o nó possuindo ID 144 pode enviar pings tanto na direção do nó possuindo ID 135 quando na direção do nó possuindo ID 151. Os padrões de distribuição de ping e freqüências podem variar. Por exemplo, por anel de proximidade.

O método 1400 inclui um ato de recebimento de uma segunda mensagem de ping a partir do nó vizinho (ato 1402). A segunda mensagem de ping indica para o nó atual pelo menos que o nó vizinho originando a segunda mensagem ping é um vizinho do nó atual. A segunda mensagem de ping também pode incluir o estado dos nós vizinho e parceiro de direcionamento do nó vizinho de origem. Por exemplo, o nó possuindo ID 151 pode enviar uma segunda mensagem de ping para o nó possuindo ID 144. Depois de receber a segunda mensagem de ping, o nó possuindo ID 144 fica ciente de que o nó possuindo ID 151 é um vizinho do nó possuindo ID 144. A segunda mensagem de ping pode incluir também infor- mação de vivacidade para outros nós no anel 1206. Dessa forma, geralmente, as mensa- gens de ping podem ser permutadas dentro de uma vizinhança e podem ser utilizadas para manter a associação de vizinhança (para cada associação proximal) e uma vista de vizi- nhança comum aproximada da presença do nó dentro da federação.

Uma mensagem de ping recebida pode ser periodicamente repetida/enviada para outros nós dentro da vizinhança proximal dentro da qual o ping foi originado (enviada pelo nó de origem). As mensagens de ping enviadas também podem ser enviadas de acordo com um padrão de distribuição de ping. O padrão de distribuição de ping para um nó de en- vio pode indicar que as mensagens de ping devem ser enviadas para os nós vizinhos em uma direção para longe de um nó de origem. Por exemplo, o nó possuindo ID 1151 pode enviar pings originados no nó possuindo ID 144 na direção do nó possuindo ID 174. Os pa- drões de distribuição de envio de ping podem variar, por exemplo, de acordo com o anel de proximidade.

Os nós podem ser configurados para receber mensagens de ping em intervalos cor- respondentes. Quando as mensagens de ping esperadas não são recebidas, um nó pode interpretar uma falha de comunicação e configurar a indicação de fase desconhecida para outro nó como verdadeira para o nó que deveria ter originado a mensagem de ping espera- da, mas, pelo menos, tardia.

O método 1400 inclui um ato de direcionamento proximal de uma mensagem de so- licitação de atualização para um nó de direcionamento perfeito (ato 1403). A mensagem de solicitação de atualização indica para o nó de direcionamento que está recebendo tal solici- tação de atualização direcionada que o nó atual está participando como um parceiro de di- recionamento do nó de direcionamento de recebimento. A mensagem de solicitação de a- tualização também pode incluir pelo menos as identidades dos nós vizinhos do nó atual (por exemplo, na forma de informação de vivacidade). Por exemplo, o nó possuindo ID 144 pode direcionar a mensagem de atualização 1216 para o nó possuindo ID 208 (o parceiro de dire- cionamento perfeito desviado por 64 de 144). Visto que o nó 210 (um nó de direcionamento computado previamente) está mais próximo de 208, o mesmo receberá e processará a soli- citação de atualização direcionada. Depois do recebimento da mensagem atualizada 1216, o nó possuindo ID 210 toma ciência (ou é reforçado) de que o nó possuindo ID 144 é um parceiro de direcionamento do nó possuindo ID 210.

O método 1400 inclui um ato de recebimento de uma mensagem de resposta de a- tualização do nó de direcionamento de processamento (recebimento) (ato 1404). A resposta de atualização indica para o nó atual que o nó de direcionamento de processamento está participando como um parceiro de direcionamento do nó atual. A mensagem de resposta de atualização também pode incluir pelo menos as identidades dos nós vizinhos do parceiro de direcionamento que está processando. Por exemplo, o nó possuindo ID 210 pode enviar a resposta de atualização 1207 para o nó possuindo ID 144. Depois do recebimento da res- posta de atualização 1207, o nó possuindo ID 144 toma ciência de que o nó possuindo ID210 é um parceiro de direcionamento do nó possuindo ID 144.

O método 1400 também pode incluir um ato de informação de nó de atualização adequada para indicar que o nó atual e o nó vizinho estão participando como vizinhos e que o nó atual e o nó vizinho estão participando como parceiros de direcionamento. Por exem- plo, o nó possuindo ID 144 pode atualizar informação de nó correspondente ao nó possuin- do ID 151 para indicar que os nós possuindo IDs 144 e 141 estão participando de um vizi- nho (proximal). De forma similar, o nó possuindo ID 144 pode atualizar a informação de nó correspondente ao nó possuindo ID 210 para indicar que os nós possuindo IDs 144 e 210 estão participando como parceiros de direcionamento.

Em algumas modalidades, o estado de aplicativo salvado em um nó especificado X é duplicado entre seus nós vizinhos (X) utilizando o protocolo de inundação confiável. Cada item no estado de aplicativo possui um proprietário designado, que pode ser o ponto final que criou o item. Cada item no estado de aplicativo também possui um selo de tempo asso- ciado (a.k.a. número de seqüência) fornecido por seu proprietário. O selo de tempo possui pelo menos três componentes:

ID de caso (por exemplo, um inteiro não assinado) da entidade proprietária. Deve aumentar pelo menos de forma monotônica (>1).

ID de seqüência (por exemplo, uma URI) identificando a seqüência particular gera- da por um proprietário. Esse componente permite que o mesmo proprietário gere múltiplas seqüências independentes.

Número ordinal (por exemplo, um inteiro não assinado) identificando o desvio den- tro da ID de seqüência de aplicativo identificado.

Os selos de tempo de item são utilizados para detectar a última informação associ- ada com o item correspondente durante a duplicação visto que os selos de tempo de item geram pelo menos uma ordem parcial com <ID de caso, ID de seqüência e Desvio> triplos. O selo de tempo associado com um item sendo duplicado é comparado com o local, se al- gum, para detectar o último. Os selos de tempo de item também são utilizados para suportar semântica idempotente das operações de criação/atualização/eliminação. Por exemplo, quando um nó recebe uma solicitação para atualizar um item existente no estado de aplica- tivo, a atualização é aceita apenas se o selo de tempo associado com a solicitação de atua- lização for maior do que o associado com o item local. As técnicas de resolução de conflito com base nos selos de tempo de vetor podem ser utilizadas onde os itens não podem rece- ber um único proprietário. A duplicação do estado de aplicativo fornece tolerância à falha e facilita as solicitações de equilíbrio de carga através dos nós vizinhos.

Como um comportamento opcional, os nós que não detectam (depois de um perío- do de tempo) uma atualização esperada ou ping dos outros nós (de origem) ou parceiros (direcionamento e/ou parceiro) podem considerar o estado de fase desconhecido, configurar uma indicação de fase desconhecida como verdadeira, e reportar a mesma como tal para outros nós de terceiras partes. Em outras palavras, a geração periódica de atualizações e pings pode ser necessária. Essa exigência e os valores de expiração de prazo real podem ser um atributo de vários anéis proximais. Por exemplo, um anel pode ter exigências de temporização mais restritivas para alguns sub-anéis (por exemplo, em um segmento LAN) e a detecção/reporte de falha de nó é relativamente rápida. Por outro lado, um anel pode ter exigências de temporização menos restritivas (ou até mesmo nenhuma exigência de tempo- rização) para outros subanéis (por exemplo, na Internet) e a detecção/reporte de falha de nó pró-ativa é relativamente longa (ou não existe).

A figura 15 ilustra um fluxograma ilustrativo de um método 1500 para descobrir a in- formação de vivacidade para outro nó. O método 1500 será descrito com relação ao anel .1206 nas figuras 12a e 12b. Geralmente, qualquer mensagem, tal como, por exemplo, sin- cronização 1203, resposta de sincronização 1204, atualização 1216, resposta de atualiza- ção 1207, etc., pode incluir pelo menos um cabeçalho de vivacidade. Em algumas modali- dades, um cabeçalho de vivacidade inclui um <ID de nó, ID de caso, fase [valor de estado de fase].[indicação de fase desconhecida], valor de frescor, valor de cor (proximidade), e um valor de peso> para um nó. Em outras modalidades, um cabeçalho de vivacidade inclui <u- ma fase [valor de estado de fase].[indicação de fase desconhecida], valor de frescor, valor de cor (proximidade) e um valor de peso>. Nessas outras modalidades, os cabeçalhos de vivacidade podem ser utilizados para aumentar os cabeçalhos de endereçamento que já incluem ID de nó e ID de caso para os nós remetente e de origem. Visto que os cabeçalhos de endereçamento já incluem ID de nó e ID de caso, essa informação pode ser omitida do cabeçalho de vivacidade.

O método 1500 inclui um ato de receber um cabeçalho de vivacidade representan- do informação de estado para um nó que está participando de uma infra-estrutura de fede- ração (ato 1501). O cabeçalho de vivacidade inclui pelo menos um ID de nó participante recebido, um ID de caso de nó recebido, um valor de fase recebido e um valor de fresco recebido. Por exemplo, o nó possuindo ID 144 pode receber um primeiro cabeçalho de viva- cidade na resposta de sincronização 1204 do nó possuindo ID 151. O primeiro cabeçalho de vivacidade pode incluir um <ID de nó participante, um ID de caso, um valor de fase [valor de estado de fase].[indicação de fase desconhecida], um valor de frescor, um valor de cor (pro- ximidade) e um valor de peso> para o nó possuindo ID 174. O valor de estado de fase (por exemplo, inserção, sincronização, direcionamento, operação) identifica a fase expressada do nó possuindo ID 174 no momento do primeiro valor de frescor. O valor de fase (por e- xemplo, estado de fase: [Inserção, Sincronização, Direcionamento, Operação], e fase des- conhecida) identifica a informação de fase expressada e/ou detectada do nó possuindo ID .174 no momento indicado pelo primeiro valor de frescor.

No entanto, um valor de frescor pode ser descontinuado devido ao retardo de co- municação. Um valor de frescor também pode cair com a passagem do tempo. As curvas de queda para um valor de frescor podem diferir ( e podem não ser lineares ou simétricas) para diferentes estados de fase (incluindo a desconhecida). Dessa forma, através de diferentes fases de nó, a queda de um valor de frescor pode ser não linear e/ou simétrica.

O método 1500 inclui um ato de acesso de pelo menos um ID de caso atual, valor de fase atual, e valor de frescor atual para o nó participante mantido no nó atual (ato 1502). Por exemplo, o nó possuindo ID 144 pode acessar um ID de caso recebido e armazenado anterior, valor de fase [valor de estado de fase].[indicação de fase desconhecida], e o valor de frescor para o nó possuindo ID 174. O método 1500 inclui um ato de comparação de pelo menos o ID de caso recebido, valor de fase recebido, e valor de frescor recebido com o ID de caso atual, o valor de fase atual, e o valor de frescor atual respectivamente em um nó atual (ato 1503). Por exemplo, o nó possuindo ID 144 pode comparar o ID de caso recebido previamente e armazenado, o valor de fase [valor de estado de fase].[indicação de fase desconhecida], e valor de frescor para o nó possuindo ID 174 com o ID de caso, valor de fase [valor de estado de fa- se],[indicação de fase desconhecida] e valor de frescor recebido no cabeçalho de vivacida- de.

O nó possuindo ID 144 pode determinar que a informação de estado atual par ao nó possuindo ID 174 (por exemplo, recebida do nó possuindo ID 151) é antiga com base (na ordem) no primeiro ID de caso sendo maior do que o ID de caso atualmente armazenado para o nó possuindo ID 174, com base no primeiro valor de estado de fase sendo mais a- vançado o que o valor de estado de fase atualmente armazenado para o nó possuindo ID .174, ou com base no primeiro valor de frescor sendo um valor superior ao valor de frescor atualmente armazenado par ao nó possuindo ID 174. O nó possuindo ID 144 também pode determinar que pelo menos uma indicação de fase desconhecida (atualmente armazenada ou recebida no cabeçalho de vivacidade) indica que um estado de fase foi conhecido no momento em que o estado de fase foi detectado/transmitido.

O método 1500 inclui um ato de determinação de se a informação de estado par ao nó participante precisa ser atualizada no nó atual com base na comparação (ato 1504). Por exemplo, com base na comparação de valores para o nó possuindo ID 174, o nó possuindo ID 144 pode determinar que a informação de estado para o nó possuindo ID 174 deve ser atualizada. A atualização da informação de estado desatualizada para o nó possuindo ID .174 pode incluir a substituição de valores armazenados atuais (por exemplo, ID de caso, valor de estado de fase, indicação de fase desconhecida, ou valor de frescor) com os valo- res incluídos no cabeçalho de vivacidade. Por exemplo, o nó possuindo ID 144 pode atuali- zar a informação de estado para o nó possuindo ID 174 para indicar que o nó possuindo ID .174 transitou para um estado de fase mais avançado.

Em algumas modalidades, pode ser detectado que a comunicação com o nó parti- cipante pode não ter sido perdida. Por exemplo, o nó possuindo ID 144 pode detectar que a comunicação com o nó possuindo ID 151 foi perdida. Com referência breve à figura 17, em resposta a uma assinatura anterior por eventos de vivacidade 1701 (com um ponto final do nó possuindo ID 151), uma camada de aplicativo 1752 pode enviar evento de desativação de ponto de extremidade 1703 (com um ponto de extremidade do nó possuindo ID 151) para a camada de função 1751. Nessas modalidades, tais condições de vivacidade detectadas podem ser indicadas na informação de vivacidade com o indicador de fase desconhecida sendo configurado para verdadeiro juntamente com o último valor de estado de fase conhe- cido.

O método 1500 pode incluir adicionalmente um ato de recebimento de uma mensa- gem que inclui um segundo cabeçalho de vivacidade de um segundo nó diferente na infra- estrutura de federação. Por exemplo, o nó possuindo ID 144 pode receber uma mensagem de situação (do nó possuindo ID 103 ou algum outro nó do anel 1206) que inclui um segun- do cabeçalho de vivacidade. O segundo cabeçalho de vivacidade pode incluir <ID do nó participante, um segundo ID de caso, um segundo valor de fase [valor de estado de fa- se],[indicação de fase desconhecida], um segundo valor de frescor, um segundo valor de cor (proximidade), e um segundo valor de peso> para o nó possuindo ID 174. O segundo valor de fase (por exemplo, estado de fase: [Inserção, Sincronização, Direcionamento, Operação], e indicação de fase desconhecida) identifica a fase expressada/detectada do nó possuindo ID 174 no momento do segundo valor de frescor.

Alternativamente, subseqüentemente ao recebimento do primeiro cabeçalho de vi- vacidade, o nó possuindo ID 144 pode tentar se comunicar diretamente com o nó possuindo ID 174. Se a comunicação for bem sucedida, o nó possuindo ID 174 pode retornar uma mensagem (por exemplo, resposta de sincronização) possuindo o I de nó e o segundo ID de caso em um cabeçalho de endereçamento e possuindo um cabeçalho de vivacidade incluin- do<segundo valor de fase, segundo valor de frescor, segundo valor de cor (proximidade), e segundo valor de peso>. Se uma falha for detectada, o nó possuindo ID 144 gera uma mu- dança de estado de vivacidade interna (por exemplo, frescor = max, e indicação de fase desconhecida = verdadeira) e processa a mudança de estado como se a mudança de esta- do fosse recebida de outro nó. Tal mudança de estado possui maior valor de frescor.

O método 1500 também pode incluir um ato de comparação do segundo ID de ca- so, do segundo valor de fase, e do segundo valor de frescor com o ID de caso atual, o valor de fase atual, e o valor de frescor atual respectivamente (ato 1506). Por exemplo, depois de receber uma mensagem de situação do nó possuindo ID 103, o nó possuindo ID 144 pode determinar que a informação de estado atual para o nó possuindo ID 151 está ultrapassada com base (em ordem) no segundo ID de caso sendo maior do que o primeiro ID de caso, na segundo valor de fase sendo mais avançado do que o primeiro valor de fase, ou o segundo valor de frescor sendo maior do que o primeiro valor de fase.

O método 1500 também pode incluir um ato de determinação de se a informação de estado para o nó participante deve ser atualizada com base em comparação. Por exem- plo, com base na comparação de valores para o nó possuindo ID 174, o nó possuindo ID144 pode determinar que a informação de estado para o nó possuindo ID 174 precisa ser atualizada. A atualização da informação de estado desatualizada para o nó possuindo ID174 pode incluir a substituição de valores armazenados atuais (por exemplo, ID de caso, valor de estado de fase, indicação de fase desconhecida, ou valor de frescor) com os valo- res incluídos no segundo cabeçalho de vivacidade. Por exemplo, o nó possuindo ID 144 pode atualizar a informação de estado para o nó possuindo ID 174 para indicar que o nó possuindo ID 174 transitou para um estado de fase mais avançado.

Em algumas modalidades, os valores de fase são comparados dentro do contexto de valores de cor iguais. Como descrito anteriormente, um nó pode participar de múltiplos anéis de proximidade. A participação em múltiplos anéis de proximidade pode ocorrer como resultado da participação em um anel mais específico, implicando na participação em um anel mais geral (ao longo de uma linha comum). Por exemplo, com referência novamente à figura 5, uma participação do nó no anel 532 também implica que o nó esteja participando dos anéis 522, 511 e 501. Dessa forma, uma cor para um anel mais específico também re- presenta todos os anéis proximais parentes. Além disso, como descrito anteriormente, a participação em múltiplos anéis de proximidade pode ocorrer quando um nó em um anel é desalinhado em um ou mais outros anéis (potencialmente ao longo de linhas diferentes). Por exemplo, ainda com referência à figura 5, um nó participante do anel 532 pode ser desali- nhado no anel 531 (ou mesmo o anel 541 que implicaria na participação nos anéis 531, 522, .511 e 501). Dessa forma, uma cor para um anel (por exemplo, anel 531) pode ser vista co- mo uma cor igual (ou proximidade) de outro anel (por exemplo, anel 532).

Quando um nó participa de uma pluralidade de anéis de proximidade de forma de- salinhada, existe algum potencial de que os valores de fase (por exemplo, valores de estado de fase, e/ou indicação de fase desconhecida) para o nó difiram entre os anéis de proximi- dade diferentes. Dessa forma, um nó que recebe informação de estado para outro nó, identi- fica o anel de proximidade de forma correspondente para a informação de estado (cor) antes de determinar se a informação de estado atual deve ser atualizada para esse nó e cor. Por exemplo, o nó possuindo ID 144 pode identificar o anel de proximidade correspondente para a informação de estado recebida correspondente ao nó possuindo ID 14 antes da compara- ção da informação de estado recebida com a informação de estado atual.

A identificação de um anel de proximidade adequado pode incluir a comparação de um valor de cor recebido com um ou mais valores de cor atuais. Quando o valor de cor re- cebido e um valor de cor atual são iguais, outra informação de estado, tal como, por exem- plo, um ID de caso atual, um valor de fase atual, e um valor de frescor atual, podem ser comparados com a informação de estado recebida correspondente, tal como, por exemplo, um ID de caso recebido, um valor de fase recebido e um valor de frescor recebido. Por outro lado, quando o valor de cor recebido e um valor de cor atual diferem, comparações adicio- nais não ocorrem.

A igualdade entre os valores de cor pode resultar em uma variedade de formas. Por exemplo, a igualdade entre os valores de cor pode resultar quando um valor de cor atual e um valor de cor recebido indicam o mesmo anel de proximidade (por exemplo, o anel 532). Adicionalmente, a igualdade entre os valores de cor pode resultar quando um valor de cor mais especifico é comparado com um valor de cor parente correspondente (por exemplo, outro anel ao longo da mesma linha). Por exemplo, a comparação do valor de cor do anel532 com o valor de cor do anel 511 (ou anel 522 ou 501) pode resultar em igualdade. Dessa forma, a proximidade criança é a proximidade parente, mas é mais específica.

Dessa forma, geralmente, os nós atualmente em operação em uma infra-estrutura de federação podem permutar informação de estado de vivacidade expressada e detectada para outros nós mesmo quando a comunicação com esses outros nós parece ter sido perdi- da.

Mecanismos de Inicialização

Geralmente, a fim de que um nó se torne um membro ativo de uma federação (por exemplo, adesão), o nó precisa se comunicar com pelo menos um outro nó que já é um membro ativo do anel laminado ao qual pretende se unir. Para ajudar a garantir essa forma inicial de comunicação, as federações podem utilizar um mecanismo de inicialização. Um mecanismo de inicialização pode ser utilizado como um último recurso quando outros tipos de comunicação falham em identificar um elemento ativo de um anel laminado ou restrições de segurança exigem que um nó recém aderido se comunique inicialmente com pelo menos um dentre um conjunto de nós especiais tal como os nós semente. Isso é, quando outros tipos de comunicação falham ou devido às exigências de segurança, um mecanismo de ini- cialização pode ser utilizado para identificar um nó ativo de um anel laminado.

Em algumas modalidades, os nós semente são utilizados para inicializar a comuni- cação com uma federação. Os nós semente fornecem pontos de entrada bem conhecidos para alguns tipos de comunicação cruzada (inter-proximidade). Os nós semente ajudam a curar as divisões de anel devido à falha de infra-estrutura/recuperação e dinamismo geral. Cada anel pode ter pelo menos um nó semente operacional a fim de fornecer propriedades de inicialização básicas para uma federação.

Os nós semente iguais podem se comunicar entre si para manter uma estrutura de anel (por exemplo, uma lista conectada de forma dupla) para uma proximidade que consiste de pelo menos todos os nós semente ativos para essa proximidade. Um protocolo de sin- cronização de nó semente dedicado pode ser utilizado para fornecer cada nó semente com pelo menos o conhecimento total do estado de presença (atividade) de todos os outros nós semente. Um nó semente ativo é um nó membro do anel laminado de proximidade no qual é hospedado além de todos os outros anéis ancestrais do anel laminado. Dessa forma, um nó semente pode representar toda uma linha de anéis de proximidade, por exemplo, do anel laminado do nó semente até o anel raiz. De acordo, os nós semente podem funcionar como nós de entrada altamente disponíveis e bem conhecidos em cada um desses anéis de pro- ximidade. Como resultado disso, o estado de presença dos nós semente pode ser útil para várias formas de comunicação (por exemplo, comunicação inter-proximal) dentro de uma federação. De acordo, os nós semente podem fornecer um número de propriedades especi- ais, tal como, por exemplo, agindo também como "pontos de adesão" para os nós que estão aderindo, agindo como uma autoridade de anel seguro, auxiliando na cura das divisões de infra-estrutura, e agindo como um "nó de entrada" estável para cada uma de suas proximi- dades.

Para fornecer dados de presença, a chegada e partida ordenada do nó semente podem ser registradas como um nó de entrada estável em um ponto de encontro em cada uma de suas proximidades. Por exemplo, as mensagens de registro podem ser direcionadas para uma URI fixa cujo ID de destino é o hash SHA-1 do cordão "Proximidade:l". Enquanto em uma modalidade os nós semente agindo como nós de entrada estável registram a si mesmos dessa forma existem outras modalidades nas quais os nós não semente seleciona- dos também podem se registrar da mesma forma e com os mesmos protocolos ou protoco- los similares descritos aqui para o nó semente. Quando um nó de entrada estável (tal como um nó semente) se registra, o nó de entrada estável pode indicar cada anel do qual faz par- te. Dessa forma, a informação mantida no ponto de encontro identificada por essa URI fixa é essencialmente uma lista de nós de entrada estável e suas associações com anel corres- pondentes. De acordo, qualquer nó pode se referir ao ponto de encontro identificado por essa URI fixa para obter uma lista de nós de entrada estável disponíveis e suas associações de anel.

Em uma modalidade o nó de entrada estável registra diretamente esses eventos de chegada e partida. Em outra modalidade, o nó de entrada estável registra esses eventos diretamente em um ponto de encontro dentro de seu anel de proximidade imediata e esse ponto de encontro facilita de forma transparente (direta ou indiretamente) a atualização de todos os outros pontos de encontro adequados em cada um dos anéis de proximidade res- tantes aos quais o nó de entrada estável que está se registrando/ou cancelando seu registro pertence. O seqüenciamento do estado de aplicativo e as propriedades de propagação de uma federação podem ser utilizados para manter e propagar essa informação de registro de nó de entrada estável. Por exemplo, um protocolo de inundação confiável pode ser utilizado para duplicar o estado de aplicativo salvo dentre os nós vizinhos do nó.

A promoção dos dados de presença do nó de entrada estável na direção do anel ra- iz permite que outros nós em uma federação consultem pelo menos um nó de entrada em cada proximidade. A consulta por nó e entrada pode ser facilitada pelo direcionamento de uma mensagem de consulta de nó na direção do ponto de encontro determinado acima no Anel Antepassado Comum Inferior ("LCAR") do anel laminado do nó que está realizando a consulta e o anel de proximidade desejado. Por exemplo, com referência à figura 5, um nó no anel 541 pode desejar se comunicar com um nó no anel 533. No entanto, o nó no anel .541 pode não ter qualquer conhecimento direto de qualquer nó no anel 533. Dessa forma, o nó no anel 541 pode enviar uma mensagem de consulta de nó para o anel 522 (O LCAR do anel 541 e do anel 533). Um nó de ponto de encontro no anel 522 que processa a informa- ção de presença do nó de entrada (por exemplo, que existe no sistema devido a uma men- sagem de registro originada por esse nó de entrada) pode retornar uma mensagem de res- posta de consulta com informação de contato para pelo menos um nó de entrada estável registrado no anel 533.

Em algumas modalidades, os nós de entrada estável são nós semente configura- dos especificamente como nós de entrada estável para manutenção de dados de presença para várias proximidades. Em outras modalidades, outros tipos de nós também podem fun- cionar como nós de entrada estável mantendo os dados de presença para várias proximida- des e também podem ser configurados para realizar outras operações. Por exemplo, deter- minados outros tipos de nós podem ser configurados (por exemplo, por um administrador) como sendo altamente confiáveis e, dessa forma, adequados como um nó de entrada está- vel (isso é, a ser registrado como descrito acima). No entanto, os outros tipos de nós podem não incluir funcionalidade de nó semente adicional (por exemplo, podem não ser confiados como uma autoridade de anel de segurança). Em algumas modalidades, os pontos de en- contro que mantêm o estado de presença de nó de entrada para sua proximidade imediata podem se registrar como um nó de entrada estável no anel ou anéis ancestrais.

Comunicação Inter-Proximidade

As modalidades da presente invenção também podem facilitar a comunicação inter- proximidade, tal como, por exemplo, entre nós em diferentes ramificações proximais de uma árvore de anéis. A comunicação inter-proximidade pode ser utilizada para comunicar com e/ou entre um ou mais, e potencialmente todos os anéis de proximidade em uma infra- estrutura de anel dividida de forma proximal. Com referência agora à figura 5a, a figura 5a ilustra a árvore divisória induzida por proximidade ilustrativa 500 com níveis adicionais de detalhes nas partes da árvore divisória 500. A comunicação inter-proximidade pode ocorrer entre vários nós na figura 5a.

Como apresentado na figura 5a, a adição da árvore divisória dos anéis 500 inclui vários subanéis sob o anel 513. Cada um dos subanéis adicionais representa uma divisória de uma lista conectada classificada. Como descrito anteriormente para a figura 5, dentro da árvore divisória 500, o anel raiz 501 é dividido em uma pluralidade de subanéis, incluindo os subanéis 511, 512, 513 e 514, com base no critério 571 (um primeiro critério de limite de domínio administrativo). Além disso, como descrito previamente para a figura 5, o sub-anel .511 pode ser adicionalmente dividido em uma pluralidade de sub-anéis, incluindo os sub- anéis 521, 522 e 532 com base no critério 581 (um segundo critério limite de domínio admi- nistrativo). Outros sub-anéis sob o sub-anel 522 são adicionalmente divididos com base em outro critério.

Como descrito anteriormente, dentro da árvore divisória 500, cada nó possui um Cí- nico ID e participa de anéis ao longo de um percurso de divisória correspondente (uma li- nha) começando a partir da raiz até uma folha. Por exemplo, cada nó participante do sub- anel 552 também participará dos sub-anéis 543, 531, 522, 511 e da raiz 501.

Na figura 5a, o sub-anel 513 também pode ser dividido adicionalmente em uma plu- ralidade de subanéis, incluindo os sub-anéis 561 e 562 com base em outro critério, tal como, por exemplo, jurisdição de estado. O sub-anel 562 pode ser adicionalmente dividido em uma pluralidade de sub-anéis incluindo os subanéis 571 e 572 com base em outro critério, tal como, por exemplo, jurisdição de cidade. De acordo, dentro da figura 5a, a comunicação inter-proximidade pode ser utilizada para enviar uma mensagem de um nó de anel 541 para um nó de anel 572, sem exigir comunicação pela linha do anel 541 até o anel raiz 501 e en- tão de volta do anel raiz 501 par ao anel 572.

A comunicação inter-proximidade pode ser incluída como parte de um padrão de comunicação, tal como, por exemplo, difusão, multidifusão, ou qualquer tipo de difusão, sendo implementado em uma árvore de anéis. A difusão pode incluir o envio de uma men- sagem para todos os nós ativos em uma árvore de anéis. A multidifusão pode incluir o envio de uma mensagem para um grupo de nós em uma árvore de anéis. Qualquer tipo de difusão pode incluir o envio de uma mensagem para pelo menos um nó em uma árvore de anéis.

A figura 19a ilustra uma árvore de anéis divisória induzida por proximidade ilustrati- va 1900 que facilita a comunicação inter-proximidade. Dentro da árvore de anéis divisória .1900, o anel raiz 1901 é dividido em uma pluralidade de sub-anéis, incluindo os sub-anéis 1, .2, 3, e 4, com base nos critério selecionado (por exemplo, um critério de limite de domínio administrativo). O sub-anel 1 é adicionalmente dividido em sub-anéis 11, 21, 31 e 41. O sub- anel 11 é adicionalmente dividido em sub-anéis 111, 211 e 311. O sub-anel 21 é adicional- mente dividido em sub-anéis 121, 221, 321, 421 e 521. Apesar de não ser expressamente apresentado, outros sub-anéis, tal como, por exemplo, os sub-anéis 2, 3, 4, 31 e 41, tam- bém podem ser adicionalmente divididos.

A convenção de numeração dos anéis na árvore de anéis divisória induzida por proximidade 1900 é configurada de forma que quaisquer dígitos depois do primeiro dígito indiquem um anel parente do anel. Por exemplo, o "11" no anel "311" indica que o anel 11 é anel parente do anel 311. De forma similar, o "1" no anel "41" indica que o anel 1 é o anel parente do anel 41. O anel global 1901 é o anel parente para quaisquer anéis numerados com um único dígito, tal como, por exemplo, os anéis 1, 2, 3 e 4. De forma similar à árvore de anéis divisória induzida por proximidade 500 na figura 5a, a árvore de anéis divisória .1900 pode ser dividida com base nos vários critérios de proximidade.

Dentro da descrição e das reivindicações em anexo, a anotação R["<número>"] é utilizada para se referir a um número de anel. Por exemplo, R["11"] se refere ao anel 11. Dentro da descrição e das reivindicações a seguir, a anotação N[<número>] é utilizada para se referir a um número de nó. Por exemplo, N[1311] se refere ao nó 1311.

Para facilitar a comunicação em um árvore de anéis, os nós podem manter uma ta- bela de entrada que combina os anéis com os nós de entrada correspondentes nesses a- néis. Como descrito anteriormente, com base na configuração da árvore divisória de anéis1900 um anel parente contém todos os nós de cada um de seus anéis criança. Por exemplo, o anel 11 contém todos os nós de R["111"], R["211"]· e R["311"]. Dessa forma, o envio de uma mensagem para o anel 11 é suficiente para se enviar a mensagem para qualquer nó no anel R["111"], R["211"] e R["311"]. De acordo, em algumas modalidades, a tabela de entrada de um nó pode ser reduzida para entradas para os anéis que são relativamente diferentes da perspectiva do anel no qual o nó reside. Por exemplo, N[1111] pode simplesmente man- ter uma entrada para R["21"]-N[1121] - visto que a manutenção das entradas para múltiplos anéis criança ou R["21"] seria redundante.

Criação e Manutenção de Conjuntos de Anel Colateral

Dentro dessa descrição e nas reivindicações a seguir qualquer anel igual de um anel especificado é definido como um "anel colateral" do anel especificado. Dentro dessa descrição e nas reivindicações a seguir qualquer anel igual dos anéis antepassado do anel especificado também é definido como um "anel colateral" do anel especificado. Qualquer anel colateral de um anel especificado também é o anel colateral de todos os nós incluídos no anel especificado.

Dessa forma, por exemplo, ainda com referência à figura 19a, R["211"] é um anel colateral do R["111"] visto que R["211"] é um igual de R["H1"]. R["211"] também é um anel colateral de qualquer nó incluído em Rf'111"], tal como, por exemplo, N[1311]. Adicional- mente, R["21"] é um anel colateral de R["111"] visto que R["21"] é um igual de R["11"] (isso é, um ancestral de R["111"]) R["21"] também é um anel colateral de qualquer nó incluído em R["111"], tal como, por exemplo, N[1111].

Dentro dessa descrição e nas reivindicações a seguir, um "conjunto de anel colate- ral" ("CRS") é definido como um conjunto de um ou mais anéis colaterais da perspectiva de um anel especificado ou nós dentro de um anel especificado. Por exemplo, na figura 19a, um conjunto de anel colateral para R["221"], além de quaisquer nós em R["221"], tal como, por exemplo, N[8221], inclui R["11"], R["121"], R["31"], R["41"], R["2"], R["3"] e R["4"].

Dessa forma, para facilitar a comunicação inter-proximidade, um nó pode manter uma tabela de entrada de CRS que inclui um ou mais anéis colaterais e um ou mais nós de entrada correspondentes em um ou mais anéis colaterais. Uma tabela de entrada de CRS pode ser uma estrutura de dados incluindo um ou mais itens <anel colateral 1 para N nós de entrada=», onde N é algum inteiro. Por exemplo, a estrutura de dados pode ser do formato <collateral ring_01, entry node_01, entry node_02,...>, onde a elipse representa um ou mais nós de entrada adicionais no collateral ring_01.

Para se cria uma tabela de entrada CRS1 um nó pode utilizar o conhecimento local, mensagens de protocolo de encontro (por exemplo, mensagens de ping, mensagens de a- tualização e respostas de atualização) utilizadas para propagar o estado em uma árvore de anéis, mensagens de aplicativo, e mensagens utilizadas para facilitar os padrões de comu- nicação especificados (por exemplo, difusão, multidifusão e qualquer tipo de difusão) em uma árvore de anéis.

Um nó pode utilizar o conhecimento local, tal como, por exemplo, a informação de tabela de direcionamento, a partir de todos os níveis de anéis dos quais um nó participa. Por exemplo, ainda com referência à figura 19, N[1121] pode ser um vizinho de N[1311] em RP"]. Um anel colateral de N[1311] da perspectiva de N[1211] é R["21"]. De acordo, N[1311 ] pode inserir o par R["21"], N[1121] (nesse caso um item possuindo um único nó de entrada) na tabela de entrada CRS de N[1311]. Fazendo uso desse tipo de conhecimento local, um nó pode inserir registros em uma tabela de entrada CRS.

Os nós podem, em adição às mensagens especificamente intencionais, propagar sua informação de tabela de entrada CRS para outros nós nas mensagens que são, de ou- tra forma, utilizadas para outras finalidades, tal como, por exemplo, para propagar informa- ção de vizinhança e estado de parceria de direcionamento. Por exemplo, os nós podem in- cluir o estado da tabela de entrada CRS nas mensagens ping enviadas para os nós vizinhos e nas mensagens de atualização e respostas de atualização permutadas entre os nós par- ceiros de direcionamento. Os nós que recebem um estado de tabela de entrada CRS de outro nó podem utilizar o estado de tabela de entrada CRS recebido para aumentar e/ou manter sua própria tabela de entrada CRS.

Por exemplo, quando um nó permuta mensagens de Ping/Atualização de Encontro com seus nós vizinhos (por exemplo, em uma camada de protocolo de encontro), o nó tam- bém pode permutar (pelo menos parte de e potencialmente toda) sua tabela de entrada CRS e utilizar o estado de tabela de entrada CRS recebido de seus vizinhos/parceiros para atualizar sua própria tabela. Supondo-se, por exemplo, que N[1311] não tenha conhecimen- to prévio de qualquer nó em R["3"] (dentro do contexto de ou anel 1901). No entanto, N[1311] não tem um vizinho N[8211] (em Rp"]) e a tabela de entrada CRS de N[8211] pos- sui uma entrada (R["3"], N[8223]). Pelo menos visto que N[1311] e N[8221] são vizinhos, N[1311] e N[8221] podem ,de tempos em tempos, enviar mensagens ping um para o outro. N[8221] pode incluir (pelo menos parte de e potencialmente toda) sua tabela de entrada CRS nas mensagens ping que são enviadas para N[1311]. Dessa forma, quando N[1311] recebe uma mensagem ping de N[8221], então a mensagem ping pode incluir a tabela de entrada CRS de N[8221], A partir da tabela de entrada CRS de N[8221], N[1311] pode iden- tificar o item <R["3"], N[8223],...> e incluir o item <R["3"], N[8223], ...> em sua própria tabela de entrada CRS. N[1311] também pode identificar outros itens para outros anéis em seu CRS e incluir esses outros itens em sua própria tabela de entrada CRS.

O estado da tabela de entrada CRS pode ser permutado de forma similar em men- sagens de atualização e respostas de atualização permutadas entre os parceiros de direcio- namento em um anel. Além disso, qualquer mensagem de protocolo de direcionamento po- de utilizar para aprender (por exemplo, informação de vivacidade) sobre os nós de entrada CRS. Além disso, as mensagens específicas, destinadas a manter as tabelas de entrada CRS, podem ser utilizadas.

O estado da tabela de entrada CRS pode ser descoberto também nas mensagens que facilitam os padrões de comunicação especificados (por exemplo, difusão, multidifusão e qualquer tipo de difusão) em uma árvore de anéis. Por exemplo, para se difundir uma mensagem para cada nó em uma árvore de anéis, um algoritmo de difusão pode utilizar vá- rios tipos de mensagens que são específicas da difusão. Nós que enviam essas mensagens específicas de difusão podem incluir o estado de tabela de entrada CRS dentro das mensa- gens específicas de difusão. De forma similar, quando da multidifusão de uma mensagem para cada nó em um grupo de nós, um algoritmo de multidifusão pode utilizar vários tipos de mensagens que são específicas de multidifusão. Os nós que enviam essas mensagens es- pecíficas de multidifusão podem incluir o estado de tabela de entrada CRS dentro das men- sagens específicas de multidifusão. Da mesma forma, quando do qualquer tipo de difusão de uma mensagem para pelo menos um nó, um algoritmo de qualquer tipo de difusão pode utilizar vários tipos de mensagens que são específicas para qualquer tipo de difusão. Os nós que enviam essas mensagens específicas de qualquer tipo de difusão podem incluir o esta- do da tabela de entrada CRS dentro das mensagens específicas de qualquer tipo de difu- são. Os nós que recebem as mensagens específicas do padrão de comunicação podem identificar as entradas adequadas (por exemplo, itens <anel colateral, nós de entrada>) e incluem algum ou todo o estado dessas entradas em sua própria tabela de entrada CRS.

O estado CRS também pode ser descoberto nas mensagens de componente de a- plicativo que são permutadas entre os aplicativos. Com breve referência à figura 1, as ca- madas de aplicativo 121, 122, e/ou 123 podem permutar mensagens de componente de aplicativo que incluem o estado CRS. Depois do recebimento de uma mensagem de com- ponente de aplicativo incluindo o estado CRS, uma camada de aplicativo pode transferir o estado CRS para as outras camadas inferiores correspondentes, tal como, por exemplo, para uma camada de protocolo de encontro, para aumentar o estado CRS existente.

O estado CRS pode ser fornecido por aplicativo e/ou com fio, e é configurável por nós dentro de uma árvore de anéis.

Com referência novamente à figura 19a, se um nó achar que conhece uma plurali- dade de nós de entrada no mesmo anel, o mesmo pode decidir reter dois ou mais dos nós de entrada para o anel. Em algumas modalidades, o nó seleciona de forma aleatória um nó de entrada dentre quaisquer nós de entrada retidos. Em outras modalidades, uma política é aplicada para auxiliar na seleção de um nó de entrada especificado dentre quaisquer nós de entrada retidos. Uma política pode indicar que o nó de entrada selecionado deve ser o mesmo nó de entrada cada vez. Alternativamente, uma política pode indicar que o nó de entrada selecionado deve variar dentre qualquer nó de entrada retido. Por exemplo, em al- gumas modalidades, os nós de entrada são selecionados na forma de rodízio de forma que a carga possa ser distribuída igualmente entre quaisquer nós de entrada retidos.

Adicionalmente, quando múltiplos nós de entrada são retidos, um nó pode transitar eficientemente para um nó de entrada diferente, por exemplo, se um primeiro nó de entrada selecionado falhar, estiver ocupado, ou por alguma outra razão não estiver disponível.

Alternativamente, um nó pode reter um único nó de entrada para o anel.

De tempos em tempos um nó pode detectar nós de entrada adicionais para um a- nel. Em algumas modalidades, quando um nó retém um único nó de entrada ou não tem memória para armazenar nós de entrada adicionais, o nó pode determinar se um nó de en- trada recém recebido é o substituto de um nó de entrada existente. Em algumas modalida- des, um nó pode utilizar uma função para computar a classificação para nó de entrada can- didato com os seguintes parâmetros: a distância do nó de entrada, o frescor da informação do nó de entrada, e o peso do nó de entrada (por exemplo, preferência de configuração). Um nó de entrada com maior classificação é retido.

Uma tabela de entrada CRS pode ou não ser completa. Uma tabela de entrada CRS completa inclui pelo menos um nó de entrada para cada anel em um CRS do nó. Por exemplo, uma tabela de entrada CRS completa para o nó 1311 incluiria pelo menos um nó de entrada dentro de cada um dos anéis 111, 211, 21, 31, 41, 2, 3 e 4.

Utilizando-se os mecanismos acima é possível se construir tabelas de entrada CRS completas da perspectiva de um ou mais anéis e/ou nós em uma hierarquia de anel proxi- mal. Em algumas modalidades, pode ser que a informação de estado de tabela de direcio- namento apenas forme uma tabela de entrada CRS completa para cada nó na árvore de anéis. Por exemplo, o direcionamento da informação relacionada com a tabela propagada (por exemplo, em mensagens ping, mensagens de solicitação de atualização e mensagens de resposta de atualização) na árvore de anéis 1900 pode formar uma tabela de entrada CRS completa para cada nó em cada um dos anéis apresentados.

No entanto, em outros ambientes de rede distribuídos a natureza dinâmica do anel e/ou retardo na permuta do estado relacionado com a tabela de entrada podem prejudicar a construção de uma tabela de entrada completa. De outra forma, nesses outros ambientes, pode haver um ou mais anéis de um conjunto anel colateral do anel ou nó do qual o nó ou anel não tem ciência em qualquer momento determinado. Por exemplo, com referência no- vamente à figura 19a, supondo-se que N[8004] tenha acabado de aderir, e antes disso não havia qualquer nó pertencendo a R["4"], a maior parte dos nós não terá um nó de entrada para R["4"] até que o tráfego de mensagem (por exemplo mensagens ping/de atualização) ou outras atividades causem a distribuição dessa informação através de toda a infra- estrutura do anel. Dessa forma, a manutenção de uma tabela de entrada CRS completa em um nó nem sempre é possível devido ao dinamismo da rede (por exemplo, falhas de nó, falhas de comunicação, retardos na comunicação, adições de nó, etc.). De acordo, em mui- tos ambientes um nó mantém uma tabela de entrada CRS parcial incluindo os nós de entra- da para menos de todo SOS anéis no CRS do nó.

Comunicação Inter-Proximidade Utilizando a Tabela de Entrada CRS Um nó pode utilizar a informação em uma tabela de entrada CRS para enviar co- municação inter-proximidade (por exemplo, sem ter que direcionar uma mensagem para um LCAR do anel remetente e do anel destinatário). Ainda com referência à figura 19a, com base nas entradas adequadas em uma tabela de entrada CRS, N[1311] (por exemplo, um nó editor) pode ser capaz de enviar a comunicação inter-proximidade diretamente para um ou mais dentre Rp 11"], R["211"], R["21"], R["31"], R["41"], R["2"], R["3"] e R["4"]. Por exem- plo, em algum ponto no tempo uma tabela de entrada CRS para N[1311] pode incluir os se- guintes registros: R["2"J:N[1112] R["3"]:N[8223] R["21"]:N[1121] R["31"]:N[H31] R["111"]:N[1111] R["211"]:N[1211]

Esses registros podem ser utilizados para direcionar a comunicação para R["111"], Rn""], R["21"], R["31"], R["2"], e R["3"]. Por exemplo, N[1311] pode enviar comunicação 52 para R["111"], N[1311] pode enviar comunicação 51 para R["211"], N[1311] pode enviar co- municação 53 para R["21"] (N[1121] é um membro de ambos R["21"] e R["221"]), N[1311] pode enviar comunicação 56 para R["31"], N[1311] pode enviar comunicação 57 para R["2"] e N[1311] pode enviar comunicação 58 para R["3"]. Com o tempo, N["1311"] pode identificar os registros (por exemplo, itens <anel colateral, nó de entrada>) para R["41"] e R["4"]. Esses registros podem ser identificados a partir do conhecimento local atualizado, a partir das ta- belas de entrada CRS contidas nas mensagens de protocolo de encontro (por exemplo, mensagens de ping, mensagem de atualização, e respostas de atualização), através do es- tado de tabela de entrada CRS contido nas mensagens específicas de padrão de comunica- ção e através de outros mecanismos tal como, por exemplo, um componente de aplicativo. Algoritmo de Direcionamento Descendente

Em uma federação de encontro (com ou sem tabelas de entrada CRS), pode ser o caso de uma mensagem ser direcionada para o nó mais próximo de um ID de nó determina- do dentro de um anel de proximidade especificado que não é um antepassado para (ou den- tro) do anel laminado onde a mensagem foi originada (doravante referida como "direciona- mento descendente"). Um exemplo disso é a facilitação de uma comunicação inter- proximidade de um nó em um anel de origem para um anel colateral quando o nó no anel de origem não está ciente de um nó de entrada par ao anel colateral. A figura 19b ilustra outra vista da árvore divisória de anéis induzida por proximidade ilustrativa 1900. Por exemplo, com referência agora à figura 19b, pode ser que N[1311] deva enviar a comunicação desti- nada a um nó R["4"] ou R["41"].

De acordo com uma federação de encontro, a função a seguir pode ser definida:

RouteDown (Μ, P, ID): A federação deve distribuir a mensagem M para o nó mais próximo de ID na proximidade Ρ. A proximidade P pode ser qualquer anel de proximidade na federação (laminado ou intermediário) que não seja um antepassado para (ou dentro) do anel laminado do nó de origem.

Em algumas modalidades, a mensagem M nunca é direcionada acima dos nós den- tro de LCAR do anel laminado do nó de origem e o anel de proximidade alvo P. Por exem- plo, para se implementar o direcionamento descendente de N[1311] para R["41"], pode não haver necessidade de se direcionar uma mensagem acima e R["1"] (LCAR e R["311"] e R["41"]). No entanto, em outras modalidades, se for adequado uma mensagem pode ser direcionada acima de LCAR.

A função RouteDown (Μ, P, ID) pode incluir a identificação de um nó de entrada conhecido como sendo um membro do anel de proximidade alvo P. Um nó remetente pode identificar um nó de entrada em um anel de proximidade alvo utilizando uma variedade de mecanismos diferentes. Um nó remetente pode ser um nó de origem (o primeiro nó reme- tente). Um nó remetente também pode ser um nó intermediário que recebe uma mensagem do nó de origem ou outro nó intermediário e então envia a mensagem.

Um nó remetente pode utilizar o conhecimento local, tal como, por exemplo, a con- figuração ou informação armazenada localmente (por exemplo, em adição a uma tabela de entrada CRS), para identificar um nó de entrada para um anel de proximidade alvo. Por e- xemplo, N[1311] pode ter acesso à memória temporária e configuração 1902 que inclui a configuração ou informação armazenada localmente sobre anéis na árvore de anéis 1900. Em algumas modalidades, o conhecimento local sobre uma federação é obtido através de mecanismos de comunicação fora da federação (isso é, fora de banda). O conhecimento local pode ser utilizado para identificar quaisquer nós no anel de proximidade alvo exato P. Se quaisquer nós no anel de proximidade alvo exato forem encontrados, a mensagem M pode ser enviada para um dos mesmos. Por exemplo, N[1311] pode ser capaz de utilizar a memória temporária e a configuração 1902 para identificar N[8004] e enviar a mensagem .1903 para R["4"].

Um nó remetente pode utilizar uma tabela de entrada CRS para localizar quaisquer nós de entrada no anel de proximidade alvo P. Se quaisquer nós de entrada no anel de pro- ximidade alvo forem encontrados, a mensagem M pode ser enviada para um nó de entrada no anel de proximidade alvo P. Por exemplo, quando N[7521] é um destino para a mensa- gem 1903, N[1311] pode identificar N[6521] como um nó de entrada para R["521"]. De acor- do, a mensagem 1903 pode ser direcionada para N[6521] (ou para dentro de R["521"]). Den- tro de R["521"], N[6521] pode então tentar direcionar a mensagem 1903 para N[7521] utili- zando comunicação intra-anel. Dessa forma, se um nó remetente for capaz de identificar um nó de entrada para o anel de proximidade alvo, o mesmo envia a mensagem para o anel de proximidade alvo exato. Por exemplo, se N["6521"] for capaz de identificar um nó de entrada para R["21"], o mesmo envia mensagem 1903 para R["21"] (linha tracejada).

Por outro lado quando o nó remetente é incapaz de identificar quaisquer nós de en- trada da proximidade alvo de destino (por exemplo, do conhecimento local ou uma tabela de entrada CRS), o nó remetente pode verificar sua tabela de entrada CRS para localizar nós de entrada para quaisquer anéis antepassado do anel de proximidade alvo. Por exemplo, pode se RO caso de N[1311] estar tentando enviar uma mensagem para o nó em R["121"], no entanto N[1311 ] pode ser incapaz de identificar um nó de entrada para R["121"]. De a- cordo, N[1311] pode se referir à tabela de entrada CRS 1904 para localizar N[6521] (um nó de entrada em R["21"]). N[1311] pode enviar a mensagem para N[6521], que agora se torna o nó remetente para a mensagem.

Logicamente, a mensagem 1903 pode agora ser visualizada como estando "em" R["21"], visto que N[6521] também é um nó de R[21], N[6521] pode então tentar identificar um nó de entrada em R[221] (a proximidade alvo). Por exemplo, N[6521] pode se referir ao conhecimento local, uma tabela de entrada CRS, e/ou pode aplicar (de forma recursiva) o algoritmo RouteDown. Pode ser que N[6521] identifique N[3221] como o nó de entrada em R[221], De acordo, N[6521] pode enviar a mensagem 1903 para N[3221]. N[3221] pode en- tão direcionar a mensagem 1903 para um nó adequado em R[221] utilizando a comunicação intra-anel.

Quando adequado (por exemplo, em árvores com maior profundidade do que o ilus- trado na figura 19b), uma mensagem pode ser passada para antepassados que estão mais próximos do anel de proximidade alvo até que um nó de entrada no anel de proximidade alvo seja identificado ou nenhum outro anel antepassado esteja disponível.

Um nó remetente também pode direcionar uma solicitação de consulta de nó de en- trada contendo pelo menos a proximidade alvo solicitada para um mecanismo de diretório de nó de entrada, tal como, por exemplo, utilizado para inicialização da federação. O dire- cionamento de uma solicitação de consulta de nó de entrada pode ser restrito a LCAR do nó remetente e do anel alvo. por exemplo, N[1311 ] pode direcionar a solicitação de consulta1906 para o ponto de encontro 7651 para solicitar os nós de entrada para R["31"]. Um me- canismo de diretório de nó de entrada pode retornar uma lista de nós de entrada potenciais. Por exemplo, o ponto de encontro 7651 pode retornar uma lista de nós de entrada potenci- ais (incluindo N[8431]), e pelo menos os nós semente registrados com esse ponto de encon- tro para a proximidade alvo na resposta de consulta 1907.

O nó remetente considera qualquer nó recém descoberto identificado em uma men- sagem de resposta de consulta (enviada a partir do ponto de encontro) e envia a mensagem M para um dos outros nós de entrada. Considerando-se que os nós recém descobertos po- dem fazer com que a tabela de entrada CRS, além de outro conhecimento de presença de nó armazenado temporariamente localmente, seja aumentada e de outra forma mantida. A mensagem de resposta de consulta pode conter também outra informação de presença de nó. Por exemplo, os nós de entrada específicos conhecidos como sendo importantes para o nó remetente para possível inclusão na tabela de entrada CRS do nó remetente.

Dessa forma, se um ou mais mecanismos disponíveis resultarem pelo menos em um nó de entrada no anel de proximidade alvo, a mensagem M é enviada (pelo nó de envio original, um nó de entrada em um anel antepassado de proximidade alvo, ou um nó de en- trada consultado), para pelo menos um desses nós de entrada no anel alvo. A mensagem M pode incluir instruções para o nó de entrada no anel alvo de proximidade para direcionar a mensagem M para ID. Por outro lado, se nenhum dos mecanismos disponíveis resultar em um nó de entrada no anel de proximidade alvo, a solicitação RouteDown pode voltar para o nó remetente original.

Em algumas modalidades, um nó de origem fixa a um cabeçalho de mensagem RouteDown extremidade com extremidade à mensagem, onde o cabeçalho de mensagem RouteDown especifica a URI e proximidade alvo.

Se qualquer um dos mecanismos acima identificar múltiplos nós de "próximo pulo", um único nó pode ser selecionado. Quando da seleção de um único nó (por exemplo, rom- pendo uma ligação), os nós que estão mais próximos da proximidade alvo P podem ser se- lecionados, então os nós com maior peso podem ser selecionados, então os nós que estão mais próximos do ID de destino de M podem ser selecionados. Se nenhum mecanismo re- sultar em uma seleção, um nó pode então ser selecionado de forma aleatória. Se uma falha na tentativa de envio de mensagem M ocorrer quando houver múltiplos candidatos, o envio pode ser tentado novamente desde que existam nós candidatos sem falha.

Um percurso mensagem de Falha/Situação reverso pode ser estabelecido à medida que a mensagem de aplicativo passa da origem através dos intermediários até o nó de des- tino final. Uma vez que uma mensagem é distribuída para o destino ou uma falha é detecta- da, uma mensagem de falha/situação correspondente pode ser enviada de volta para a ori- gem ao longo desse percurso.

A figura 19c ilustra uma vista dividida de uma parte da árvore divisória de anéis in- duzida por proximidade 1900. A figura 19d ilustra uma vista expandida do anel 11 a partir da árvore divisória de anéis induzida por proximidade ilustrativa 1900. A figura 20 ilustra um fluxograma ilustrativo de um método 2000 para manutenção de um conjunto de anel colate- ral para um nó na árvore de anéis. O método 2000 será descrito com relação aos anéis, nós, mensagens, e dados nas figuras 19c e 19d.

O método 2000 inclui um ato de um nó acessando uma tabela de entrada de anel colateral configurada para armazenar entradas do conjunto de anel colateral par ao nó (ato .2001). Cada entrada de conjunto de anel colateral configurada para indicar um anel colateral do nó e pelo menos um nó de entrada correspondente no anel colateral do nó. Por exemplo, N[1311] pode acessar a tabela de entrada CRS 1904, que é configurada para armazenar as entradas de conjunto de anel colateral, no formato, anel colateral, 1aN nós de entrada>, onde N é algum inteiro, para N[1311]. Dessa forma, a tabela de entrada CRS 1904 pode incluir zero ou mais itens <anel colateral, nó de entrada>, cada item incluído indicando um anel colateral de N[1311 ] e um ou mais nós de entrada correspondentes nesse anel colate- ral. Por exemplo, como apresentado na figura 19c, a tabela de entrada CRS 1904 inclui a entrada CRS <R["51"], N[8651],...> indicativo de N[8651] sendo um dentre 1 a N nós de en- trada em R[51] (um anel colateral de N[1311] e R["311"]).

O método 2000 inclui um ato de descoberta da informação de tabela de entrada de conjunto de anel colateral a partir dos recursos disponíveis que mantém a informação rela- cionada com a configuração da árvore de anéis (ato 2002). Por exemplo, N[1311] pode des- cobrir a informação de tabela de entrada de conjunto de anel colateral a partir das fontes que mantêm a informação relacionada com a configuração da árvore de anéis 1900. Como previamente descrito, várias fontes diferentes da informação da tabela de entrada CRS po- dem estar disponíveis para um nó. Por exemplo, um nó pode ter acesso ao conhecimento local, tal como, por exemplo, configuração local e informação cache, pode acessar o estado relacionado com CRS incluído nas mensagens de protocolo de encontro, tal como, por e- xemplo, mensagens ping, mensagens de atualização, e respostas de atualização, utilizadas para propagar o estado em uma árvore de anéis, pode acessar o estado relacionado com CRS incluído nas mensagens de aplicativo, e pode acessar o estado relacionado com CRS das mensagens utilizadas para facilitar os padrões de comunicação especificados, tal como, por exemplo, difusão, multidifusão, e qualquer tipo de difusão, em uma árvore de anéis.

Dessa forma, na figura 19c, pode ser o caso de N[1311] acessar a configuração lo- cal 1921. a partir da configuração local 1921, N[1311 ] pode descobrir a entrada CRS <R["111"], Ν[1111 ],...> indicativa de N[1111] sendo pelo menos um dos nós de entrada em R["111"] (um anel colateral de N[1311] e R["311"]). N[1311] também pode receber mensa- gem de aplicativo 1971. A partir da mensagem de aplicativo 1971 N[1311] pode descobrir a informação CRS 1972. A informação CRS 1972 pode ou não conter o estado CRS dos A- néis e no CRS de N[1311]. N[1311] também pode receber mensagem específica de padrão de comunicação 1973. Para a mensagem específica de padrão de comunicação 1973 N[1311 ] pode descobrir o estado CRS 1974. O estado CRS 1974 pode ou não conter o es- tado CRS para os Anéis no CRS N[1311],

Com referência agora à figura 19d, N[1311] pode descobrir e permutar o estado CRS nas mensagens de protocolo de encontro. Visto que N[1111] é um membro de R["111"], N[1211] é um membro de R[M211"] e N[1311] é um membro de RR["311"], cada um dos nós N[1111], N[1211] e N[1311] também é um membro de R["11"]. Como descrito ante- riormente, os nós que são membros de um anel comum podem permutar mensagens de ping, mensagens de atualização e respostas de atualização para manter a informação de tabela de direcionamento. Dessa forma, os nós R["11"] podem permutar mensagens de ping, mensagens de atualização e respostas de atualização para manter a informação de tabela de direcionamento para R["11"]. O estado CRS pode ser incluído nas mensagens ping permutadas, mensagens atualizadas, e resposta atualizadas, além de outro tráfego de mensagem de aplicativo e protocolo de encontro entre os nós.

Por exemplo, N[A11] (um vizinho de N[1311 ] em R["11"]) pode enviar a mensagem ping 1931, incluindo o estado CRS 1932, para N[1311]~. A partir do estado CRS 1932, N[1311] pode descobrir a entrada CRS <R["31"], N[1311]> indicativa de N[1311] sendo um nó de entrada em R["31"] (um anel colateral de N[1311] e R["311"]). As entradas CRS 1932 podem ser uma lista completa ou parcial das entradas CRS na tabela de entrada CRS de N[A11], N[1311] também pode enviar mensagens de ping incluindo o estado CRS de seus vizinhos. Por exemplo, N[1311] pode enviar mensagem de ping 1945, incluindo o estado CRS 1934, para N[E11] (um vizinho de N[1311] em R["11"]). As entradas CRS 1934 podem incluir uma lista completa ou parcial das entradas CRS a partir da tabela de entrada CRS 1904.

N[1311] também pode enviar e receber mensagens e atualização e respostas de atualização que incluem informação relacionada com CRS. Por exemplo, N[1311 ] pode en- viar uma mensagem de atualização 1933, incluindo entradas CRS 1934, para N[D11] (um parceiro de direcionamento de N[1311] em R["11"]). N[D11] pode responder enviando a res- posta de atualização 1937, incluindo entradas CRS 1938, para N[1331]. As entradas CRS 1938 podem ser uma lista completa ou parcial das entradas CRS na tabela de entrada CRS de N[D11], De forma similar, N[1311 ] pode receber a mensagem de atualização 1941, inclu- indo as entradas CRS 1942, de N[C11] (um parceiro de direcionamento de N[1311] em R["11"]). As entradas CRS 1942 podem ser uma lista completa ou parcial de entradas CRS na tabela de entrada CRS N[C11]. N[1331] pode responder enviando uma resposta de atua- lização 1943, incluindo as entradas CRS 1934, para N["C11"].

Um nó também pode receber a informação relacionada com a tabela de entrada de conjunto de anel colateral dos recursos disponíveis indicando (direta ou indiretamente) que a entrada CRS pode não ser mais válida, por exemplo, uma indicação de que o nó de entrada não pode ser contatado. Qualquer recurso utilizado para enviar o estado relacionado com CRS também pode ser utilizado para enviar uma indicação de que pode ser interpretado para significar que uma entrada CRS pode não ser mais válida. Dessa forma, pode ser que, de tempos em tempos, um nó receba o estado relacionado com CRS que faz com que uma ou mais entradas CRS sejam adicionadas a sua tabela de entrada CRS além de indicações de que podem causar a remoção de uma ou mais entradas CRS que podem não ser mais adequadas.

O método 2000 inclui um ato de atualização da tabela de entrada de conjunto de anel colateral com o estado de entrada de conjunto de anel colateral adequado com base na informação de tabela de entrada de conjunto de anel colateral descoberta (ato 2003). Cada estado de entrada de conjunto de anel colateral adequado incluindo um anel colateral do nó e pelo menos um nó de entrada correspondente no anel colateral do nó. Por exemplo, N[1311] pode incluir quaisquer critérios CRS recebidos nas figuras 19c e 19d na tabela de entrada CRS 1904. N[1311] também pode remover quaisquer entradas CRS da tabela de entrada CRS 1904 que são indicadas (por exemplo, em configuração, mensagens de proto- colo de encontro, mensagens de aplicativos, ou mensagens específicas de padrão de co- municação) como não sendo potencialmente adequadas. De acordo, uma tabela de entrada CRS do nó pode ser atualizada para refletir adequadamente a estrutura em alteração de uma federação de encontro.

A figura 19e ilustra outra vista da árvore divisória de anéis induzida por proximidade ilustrativa 1900. Apresentada na figura 19e encontra-se uma tabela de entrada CRS 1904, que pode ter sido preenchida, com base no estado CRS permutado nas figuras 19c e 19d. A figura 21 ilustra um fluxograma ilustrativo de um método 2100 para o envio da comunicação inter-proximidade em uma árvore de anéis. O método 2100 será descrito com relação aos nós, anéis, mensagens e dados na figura 19f.

O método 2100 inclui um ato de determinação de que um nó deve enviar uma men- sagem para um anel colateral do nó (ato 2101). Por exemplo, N[1311 ] pode receber uma indicação de que deve enviar a mensagem 1976 para R["2"]. Uma indicação de que uma mensagem deve ser enviada par ao anel colateral pode ser recebida de outro nó, pode ser implicada como uma função de lógica de direcionamento, um aplicativo em N[1311]~, uma instalação de multidifusão, uma instalação de difusão, uma instalação de qualquer tipo de difusão, etc.

O método 2100 inclui um ato de o nó acessar uma tabela de entrada de conjunto de anel colateral configurada para armazenar as entradas de conjunto de anel colateral para o nó (ato 2102). Cada entrada de conjunto de anel colateral configurada para indicar um anel colateral do nó e pelo menos um nó de entrada correspondente no anel colateral do nó. Por exemplo, N[1311] pode acessar a tabela de entrada CRS 1904. Cada entrada CRS na tabe- la de entrada CRS 1904 pode indicar um anel colateral de N[1311] e pelo menos um nó de entrada correspondente no anel colateral de N[1311]. Por exemplo, a entrada <R["111"], N[1111],...> indica que R["111"] é um anel colateral de N[1311] e N[1111] é um de pelo me- nos um dos nós de entrada em R["111"].

O método 2100 inclui um ato de identificação de pelo menos uma entrada de con- junto de anel colateral para o anel colateral da tabela de entrada de conjunto de anel colate- ral do nó (ato 2103). Cada uma das pelo menos uma entradas de conjunto de anel colateral indicando pelo menos um nó de entrada do anel colateral. Por exemplo, N[1311] pode identi- ficar a entrada <["2"], N[1112],...>para R["2"] a partir da tabela de entrada CRS 1094. A en- trada <R["2"], N[1112],...> indica que N[1112] (e potencialmente outros nós) é um nó de en- trada para R["2"].

Com base no número de nós de entrada correspondentes incluídos em uma entra- da de conjunto de anel colateral identificada (por exemplo, quando existem dois ou mais nós de entrada), o método 2100 pode incluir também um ato de solucionar a partir de uma plura- lidade de nós de entrada um anel colateral para um subconjunto adequado de nós de entra- da e potencialmente para um único nó de entrada adequado. Por exemplo, um subconjunto de nós de entrada adequados pode ser solucionado com base na proximidade entre a ori- gem e a proximidade alvo P, com base no peso do nó que pode ser selecionado, com base na proximidade com um ID de destino, ou pode ser selecionado de forma aleatória.

O método 2100 inclui um ato de envio de mensagem para pelo menos um nó de en- trada indicado (ato 2104). Por exemplo, N[1311] pode enviar mensagem 1976 para N[1112]. O envio de uma mensagem para pelo menos um nó pode incluir o envio de uma mensagem para todos os nós de entrada em uma pluralidade de nós, para cada nó de entrada em um subconjunto adequado de nós de entrada, ou para um único nó de entrada adequado. Em algumas modalidades, quando uma falha de mensagem ocorre, para um nó de entrada, um ou mais outros nós de entrada podem ser tentados. É possível também um envio de nó para identificação de novos nós como resultado de uma falha.

A figura 22 ilustra um fluxograma ilustrativo para um método 2200 para o envio de comunicação inter-proximidade em uma árvore de anéis. O método 2200 será descrito com elação aos nós, anéis, mensagens e dados das figuras 19f e 19g.

O método 2200 inclui um ato de determinação de que um nó de origem pretende di- recionar uma mensagem para um nó de destino que está mais próximo de um ID de nó de- terminado em um anel de proximidade alvo dentro de uma árvore de anéis (ato 2201). O anel de proximidade alvo pode ser um anel colateral do nó de origem ou um sub-anel de um anel colateral do nó de origem. Por exemplo, N[1311] pode receber uma indicação de que deve direcionar uma mensagem 1998 para R["1221"] (o anel de proximidade alvo) na dire- ção do ID 30. Uma indicação de que uma mensagem deve ser enviada para o anel colateral ou um sub-anel de um anel colateral pode ser recebida de outro nó, um aplicativo relaciona- do com N[1311], uma instalação de multidifusão, uma instalação de difusão, uma instalação de qualquer tipo de difusão, etc.

O método 2200 inclui um ato de identificação de um ou mais nós de entrada conhe- cidos como sendo nós membros de pelo menos um dentre o anel de proximidade alvo e um anel antepassado do anel de proximidade alvo (ato 2202). Por exemplo, N[1311] pode iden- tificar N[41221], possuindo ID de nó 56, como um nó de entrada em R["1221"]. Uma varie- dade de mecanismos diferentes pode ser utilizada para identificar N[41221], N[1331] pode se referir ao conhecimento local para tentar identificar um nó de entrada no anel alvo de proximidade. Por exemplo, N[1311] pode se referir à memória temporária e configuração .1902 para tentar identificar um nó de entrada em R["1221"]·

N[1311] pode se referir também a uma tabela de entrada CRS para identificar os nós de entrada em anéis antepassados do anel alvo de proximidade (por exemplo, quando um nó de entrada no anel de proximidade alvo não é identificado). Pode ser o caso de o sub-anel R["321"] contribuir com o nó N[4321] como um nó de entrada em R["21"]. Da mes- ma forma, pode ser que R["2221"] contribua com o nó N[12221] como um nó de entrada em R["221"]. Quando um no de entrada em R[1221] não é identificado, N[1311] pode tentar i- dentificar um nó de entrada em R["221"], tal como, por exemplo, N[12221]. N[1331] também pode tentar identificar um nó de entrada em R["21"], tal como, por exemplo, N[4321].

Pode ser que um nó tente identificar os nós de entrada em anéis antepassados mais próximos antes de tentar identificar os nós de entrada em antepassados adicionais da perspectiva de uma proximidade alvo especificada, quando um nó de entrada na proximida- de alvo não for identificada. Por exemplo, quando um nó de entrada em R["1221"] não é identificado, N[1311] pode primeiro tentar identificar um nó de entrada em R["221"]. Se um nó de entrada em R["221"] não for identificado, N[1311] pode então tentar identificar um nó de entrada em R["21"].

N[1311 ] pode também utilizar mecanismos de inicialização, tal como, por exemplo, nós semente. Por exemplo, N[1311 ] pode direcionar uma solicitação de consulta de nó de entrada para um ponto de encontro conhecido, tal como, por exemplo, o ponto de encontro N[7651], solicitando os nós de entrada conhecidos (registrados) (nós semente sendo um exemplo). Em resposta a uma solicitação de consulta, um ponto de encontro pode retornar (enviar) uma mensagem de resposta de consulta incluindo quaisquer nós de entrada conhe- cidos. Por exemplo, a resposta de consulta 1997 pode ser retornada a partir do ponto de encontro N[7651] para N[1311]. A resposta de consulta 1997 pode incluir as localizações de quaisquer nós de entrada registrados com o ponto de encontro N[7651].

Um ou mais desses mecanismos pode identificar N[4221] como um nó de entrada em R["221"].

Em algumas modalidades, alguns mecanismos de identificação de nó de entrada são utilizados antes de outros mecanismos de identificação de nó de entrada. Por exemplo, um nó de envio pode referir a um conhecimento local antes de tentar identificar os nós de entrada em anéis antepassados do anel avo ou direcionar uma solicitação de consulta de nó de entrada. Nessas mesmas modalidades, um nó de envio pode tentar também identificar os nós de entrada em anéis antepassados do anel alvo antes de direcionar a solicitação de consulta de nó de entrada. No entanto, em outras modalidades, os mecanismos de identifi- cação de nó de entrada podem ser utilizados em uma ordem diferente ou podem ser omiti- dos.

O método 2200 inclui um ato de envio da mensagem para o nó de entrada identifi- cado (ato 2203). A mensagem indicando que o nó de entrada deve resolver a mensagem para o nó que possui um ID de nó mais próximo do nó de destino indicado no anel de proxi- midade alvo. Por exemplo, como indicado pela linha sólida, N[1311] pode enviar a mensa- gem 1998 para N[41221] (um nó de entrada em R["1221"] e possuindo ID de nó 56) com uma indicação de que a mensagem deve ser resolvida para o nó ID 30. N[41221] pode a- cessar sua tabela de direcionamento e/ou vizinhança para determinar o ID de nó mais pró- ximo ao ID de nó 30 de que está ciente do fato de N[61221] possuir o ID de nó 25. Da mes- ma forma, N[61221] pode acessar sua tabela de direcionamento e/ou vizinhança para de- terminar o ID de nó mais próximo de ID 30 que está ciente de N[71221] possuir um ID de nó .28. N[71221] pode se referir a sua tabela e/ou vizinhança para determinar que seu ID de nó, ID de nós 28, é o ID de nó conhecido mais próximo do ID de nó 30 e distribuir a mensagem.

Algoritmos de direcionamento descritos anteriormente podem ser utilizados também para direcionar a mensagem 1998 dentro de R["221"].

Quando uma mensagem é enviada para um nó de entrada identificado que é mem- bro de um anel antepassado ou anel de proximidade alvo, o método 2200 pode ser aplicado de forma recursiva no nó de entrada identificado. Isso é, o nó de entrada identificado no anel antepassado pode, por sua vez, tentar identificar um nó de entrada no anel de proximidade alvo. Por exemplo, como indicado por linhas pontilhas, pode ser que um aplicativo do méto- do 2200 faça com que a mensagem 1998 seja enviada para o nó de entrada N[12221] (um nó de entrada para R["221"] que é contribuído pelo sub-anel R["2221"]. N[12221] (da pers- pectiva de R["2221"]) pode então identificar um nó de entrada em R["1221"]. Dessa forma, um aplicativo recursivo do método 2200 em N[12221] pode fazer com que a mensagem1998 seja enviada para N[41221].

Se um nó de entrada identificado no anel antepassado não estiver ciente de um nó de entrada no anel de proximidade alvo, o nó de entrada identificado pode tentar identificar um nó de entrada em outro anel antepassado que está mais próximo da proximidade alvo. O nó de entrada no anel antepassado pode então enviar a mensagem para o nó de entrada do anel antepassado mais próximo do anel de proximidade alvo.

Por exemplo, como indicado por linhas pontilhadas, pode ser que um aplicativo do método 2200 faça com que a mensagem 1998 seja enviada para o nó de entrada N[4321] (um nó de entrada para R["21"] que é contribuído pelo sub-anel R["321"]. No entanto, N[4321] (da perspectiva de K["321"]) pode ser incapaz de identificar um nó de entrada em R["1221"]. Dessa forma, N[4321] (da perspectiva de R["321"] pode identificar um nó de en- trada em R["221"]. De acordo, um primeiro aplicativo recursivo do método 2200 em N[4321] pode fazer com que a mensagem 1998 seja enviada para N[12221]. Um segundo aplicativo recursivo do método 2200 em N[12221] pode então fazer com que a mensagem 1998 seja enviada para N[41221].

No entanto, se N[4321] tiver identificado um nó de entrada em R["1221"], o mesmo pode enviar a mensagem 1998 diretamente para o nó de entrada. Dessa forma, um nó de entrada em um anel antepassado pode enviar uma mensagem para o anel de proximidade alvo ou um nó de entrada de um anel antepassado mais próximo do anel de proximidade alvo (que está tipicamente no CRS do nó de entrada de envio) como adequado. Como des- crito, o nó de entrada no anel antepassado mais próximo pode então enviar a mensagem para o anel de proximidade alvo ou um anel antepassado mais próximo do anel de proximi- dade alvo (que está tipicamente no CRS do nó de entrada de envio "ainda mais próximo") como adequado. Esse processo pode ser repetido (por exemplo, através da aplicação re- cursiva do método 2200) até que o nó de entrada do anel de proximidade alvo tenha sido alcançado.

Quando o anel de proximidade alvo é alcançado, os algoritmos de direcionamento descritos previamente podem ser utilizados para direcionar a mensagem dentro do anel de proximidade alvo.

A figura 6 e a discussão a seguir devem fornecer uma descrição geral breve de um ambiente de computação adequado no qual a invenção pode ser implementada. Apesar de não ser exigido, a invenção será descrita no contexto geral de instruções executáveis por computador, tal como módulos de programa, sendo executados por sistemas de computa- dor. Geralmente, os módulos de programa incluem rotinas, programas, objetos, componen- tes, estruturas de dados, e similares, que realizam tarefas em particular ou implementam tipos de dados abstratos em particular. Instruções executáveis por computador, estruturas de dados associadas, e módulos de programa representam exemplos de meios de código de programa para execução de atos dos métodos descritos aqui.

Com referência à figura 6, um sistema ilustrativo para implementação da invenção inclui um dispositivo de computação de finalidade geral na forma de sistema de computador620, incluindo uma unidade de processamento 621, uma memória de sistema 622, e um barramento de sistema 623 que acoplam os vários componentes do sistema incluindo a memória do sistema 622 à unidade de processamento 621. A unidade de processamento621 pode executar as instruções executáveis por computador projetadas para implementar as características do sistema de computador 620, incluindo as características da presente invenção. O barramento de sistema 623 pode ser qualquer um dentre os vários tipos de es- truturas de barramento incluindo um barramento de memória ou controlador de memória, um barramento periférico, e um barramento local utilizando qualquer uma dentre uma variedade de arquiteturas de barramento. A memória de sistema inclui memória de leitura apenas ("ROM") 624 e memória de acesso randômico ("RAM") 625. Um sistema básico de entra- da/saída ("BIOS") 626, contendo as rotinas básicas que ajudam a transferir informação entre os elementos dentro do sistema de computador 620, tal como durante a inicialização, podem ser armazenados na ROM 624.

O sistema de computador 620 também pode incluir acionador de disco rígido mag- nético 627 para ler a partir de e escrever em disco rígido magnético 639, acionador de disco magnético 628 para ler a partir de ou escrever no disco magnético removível 629, um acio- nador de disco ótico 630 para ler a partir de ou escrever no disco ótico removível 631, tal como, por exemplo, um CD-ROM ou outra mídia ótica. O acionador de disco rígido magnéti- co 627, o acionador de disco magnético 628, e o acionador de disco ótico 630 são conecta- dos ao barramento do sistema 623 pela interface de acionador de disco rígido 632, interface de acionamento de disco magnético 633, e interface de acionamento ótico 634, respectiva- mente. Os acionadores e sua mídia legível por computador associada fornecem o armaze- namento não volátil de instruções executáveis por computador, estruturas de dados, módu- los de programa, e outros dados para o sistema de computador 620. Apesar de o ambiente ilustrativo descrito aqui empregar disco rígido magnético 639, o disco magnético removível629 e disco ótico removível 631, outros tipos de mídia legível por computador para o arma- zenamento de dados podem ser utilizados, incluindo fitas magnéticas, cartões de memória flash, discos versáteis digitais, cartuchos Bemoulli, RAMs1 ROMs, e similares.

Os dispositivos de código de programa compreendendo um ou mais módulos de programa podem ser armazenados em disco rígido 639, disco magnético 629, disco ótico631, ROM 624, RAM 625, incluindo um sistema operacional 635, um ou mais programas de aplicativo 636, outros módulos de programa 637, e dados de programa 638. Um usuário pode registrar comandos e informação no sistema de computador 620 através do teclado .640, do dispositivo apontador 642, ou de outros dispositivos de entrada (não ilustrados), tal como, por exemplo, um microfone, joy stick, console de jogo, digitalizador ou similar. Esses e outros dispositivos de entrada podem ser conectados à unidade de processamento 621 através da interface de entrada/saída 646 acoplada ao barramento do sistema 623. A inter- face de entrada/saída 646 representa logicamente qualquer uma dentre uma variedade de interfaces diferentes, tal como, por exemplo, uma interface de porta serial, uma interface PS/2, uma interface de porta paralela, uma interface de Barramento Serial Universal ("USB"), ou uma interface de um Instituto de Engenheiros Elétricos e Eletrônicos ("IEEE")1394 (isso é, interface FireWire), ou pode até mesmo representar logicamente uma combi- nação de diferentes interfaces.

Um monitor 647 ou outro dispositivo de monitor também é conectado ao barramen- to do sistema 623 através da interface de vídeo 648. Alto falantes 669 ou outro dispositivo de saída de áudio também são conectados ao barramento do sistema 623 através da inter- face de áudio 649. Outros dispositivos de saída periféricos (não ilustrados), tal como, por exemplo, impressoras, também podem ser conectados ao sistema de computador 620.

O sistema de computador 620 é conectável às redes, tal como, por exemplo, uma rede de computador empresarial, uma rede doméstica, uma intranet, e/ou a Internet. O sis- tema de computador 620 pode permutar dados com fontes externas, tal como, por exemplo, sistemas de computador remoto, aplicativos remotos, e/ou bases de dados remotas através de tais redes.

O sistema de computador 620 inclui interface de rede 653, através da qual o siste- ma de computador 620 recebe dados de fontes externas e/ou transmite dados para fontes externas. Como apresentado na figura 6, a interface de rede 653 facilita a permuta de dados com o sistema de computador remoto 683 através da conexão 651. A interface de rede 653 pode representar logicamente um ou mais módulos de software e/ou hardware, tal como, por exemplo, um cartão de interface de rede e uma pilha de Especificação de Interface de Acionador de Rede correspondente ("NDIS"). A conexão 651 representa uma parte de uma rede (por exemplo, um segmento Ethernet), e o sistema de computador remoto 683 repre- senta um nó da rede.

Da mesma forma, o sistema de computador 620 inclui uma interface de entra- da/saída 646, através da qual o sistema de computador 620 recebe dados das fontes exter- nas e/ou transmite dados para fontes externas. A interface de entrada/saída 646 é acoplada ao modem 654 (por exemplo, um modem padrão, um modem a cabo, ou modem de linha de assinante digital ("DSL")) através da conexão 659, através da qual o sistema de computador620 recebe dados de e/ou transmite dados para fontes externas. Como apresentado na figu- ra 6, a interface de entrada/saída 646 e o modem 654 facilitam a permuta de dados com o sistema de computador remoto 693 através da conexão 652. A conexão 652 representa uma parte de uma rede e o sistema de computador remoto 693 representa um nó da rede.

Enquanto a figura 6 representa um ambiente operacional adequado para a presente invenção, os princípios da presente invenção podem ser empregados em qualquer sistema que seja capaz de, com a modificação adequada se necessário, implementar os princípios da presente invenção. O ambiente ilustrado na figura 6 é ilustrativo apenas e de forma al- guma representa mesmo que uma pequena parte da ampla variedade de ambientes nos quais os princípios da presente invenção podem ser implementados.

De acordo com a presente invenção, nós, camadas de aplicativo, e outras camadas inferiores, além de dados associados, incluindo tabelas de direcionamento e IDs de nó po- dem ser armazenados e acessados a partir de qualquer mídia legível por computador asso- ciada com o sistema de computador 620. Por exemplo, partes de tais módulos e partes de dados de programa associados podem ser incluídas no sistema operacional 635, programas de aplicativo 636, módulos de programa 637 e/ou dados de programa 638, para o armazenamento na memória do sistema 622.

Quando um dispositivo de armazenamento em massa, tal como, por exemplo, disco rígido magnético 639, é acoplado ao sistema de computador 620, tais módulos e dados de programa associados também podem ser armazenados no dispositivo de armazenamento em massa. Em um ambiente em rede, os módulos de programa apresentados com relação ao sistema de computador 620, ou partes do mesmo, podem ser armazenados nos disposi- tivos de armazenamento em memória remota, tal como, a memória do sistema e/ou disposi- tivos de armazenamento em massa associados com o sistema de computador remoto 683 e/ou sistema de computador remoto 693. A execução de tais módulos pode ser realizada em um ambiente distribuído como descrito anteriormente.

A presente invenção pode ser consubstanciada em outras formas específicas sem se distanciar de seu espírito ou características essenciais. As modalidades descritas devem ser consideradas em todos os aspectos como ilustrativas e não restritivas. O escopo da in- venção é, portanto, indicado pelas reivindicações em anexo ao invés de pela descrição aci- ma. Todas as mudanças que se encontram dentro do significado e da faixa de equivalência das reivindicações devem ser englobadas em seu escopo.

Claims (39)

REIVINDICAÇÕES

1.Em um sistema de computador, um método para o envio de comunicação inter- proximidade em uma árvore de anéis (1900), o método CARACTERIZADO pelo fato de compreender: um ato de determinação de que um nó (1311) deve enviar uma mensagem (1903) para um anel colateral especificado (21) do nó (1311); um ato do nó (1311) acessar uma tabela de entrada de conjunto de anel colateral (1904) configurada para armazenar as entradas de conjunto de anel colateral para o nó (1311), cada entrada de conjunto de anel colateral configurada para indicar um anel colate- ral (21) do nó (1311) e pelo menos um nó de entrada correspondente (6521) no anel colate- ral (21) do nó (1311); um ato de identificação de pelo menos uma entrada de conjunto de anel colateral para o anel colateral especificado (21) a partir da tabela de entrada de conjunto de anel co- lateral do nó (1904), cada uma das pelo menos uma entradas de conjunto de anel colateral indicando pelo menos um nó de entrada (6521) do anel colateral especificado (21); e um ato de envio da mensagem (1903) para pelo menos um nó de entrada indicado (6521).

2.Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de o ato de determinar que um nó deve enviar uma mensagem para um anel colateral especificado do nó compreender um ato de recebimento de uma indicação de um aplicativo relacionado com o nó.

3.Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de o ato de determinar que um nó deve enviar uma mensagem para um anel colateral especificado do nó compreende um ato de receber uma indicação de outro nó na árvore de anéis.

4.Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de o ato de determinar que o nó deve enviar uma mensagem para um anel colateral especificado compreender um ato de o nó acessar um ou mais itens de nó de entrada/anel colateral.

5.Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de o ato de identificar pelo menos uma entrada de conjunto de anel colateral para o anel colateral especificado a partir da tabela de entrada do conjunto de anel colateral compreender um ato de identificação de um item de anel colateral/nó de entrada que identifica o anel colateral especificado e uma pluralidade de nós de entrada no anel colateral especificado.

6.Método, de acordo com a reivindicação 5, CARACTERIZADO pelo fato de com- preender adicionalmente: um ato de resolver a pluralidade de nós de entrada em um subconjunto adequado de nós de entrada.

7.Método, de acordo com a reivindicação 5, CARACTERIZADO pelo fato de com- preender adicionalmente: um ato de resolver a pluralidade de nós de entrada em um único nó de entrada a- dequado.

8. Em um sistema de computador, um método de envio de comunicação inter- proximidade em uma árvore de anéis (1900), o método sendo CARACTERIZADO pelo fato de compreender: um ato de um nó (1311) determinar que um nó de origem pretende direcionar uma mensagem (1998) para um nó de destino que está mais próximo de um ID de nó determina- do em um anel de proximidade alvo (1221) dentro da árvore de anéis (1900); um ato de identificar um ou mais nós de entrada (41221) conhecidos como sendo um nó membro de pelo menos um dos anéis de proximidade alvo (1221) e um anel antepas- sado (221) do anel de proximidade alvo (1221); e um ato de enviar a mensagem (1998) para um nó de entrada identificado (41221), a mensagem (1998) indicando que o nó de entrada identificado (41221) deve resolver a men- sagem (1998) para o nó que possui um ID de nó mais próximo de um nó de destino indicado no anel de proximidade alvo (1221).

9. Método, de acordo com a reivindicação 8, CARACTERIZADO pelo fato de o ato de um nó determinar que um nó de origem pretende direcionar uma mensagem para um nó de destino que está mais próximo de um ID de nó determinado em um anel de proximidade alvo dentro da árvore de anéis compreender um ato de o nó acessar uma indicação de que um nó de origem pretende direcionar uma mensagem para um nó de destino que está mais próximo de um ID de nó determinado em um anel de proximidade alvo dentro da árvore de anéis.

10. Método, de acordo com a reivindicação 9, CARACTERIZADO pelo fato de o ato de o nó acessar uma indicação de que um nó de origem pretende direcionar uma mensa- gem para um nó de destino que está mais próximo de um ID de nó determinado em um anel de proximidade alvo dentro da árvore de anéis compreender um ato de o nó receber uma indicação de que um nó de envio pretende direcionar uma mensagem para um nó de desti- no que está mais próximo de um ID de nó determinado em um anel de proximidade alvo que é um anel colateral do nó de envio.

11. Método, de acordo com a reivindicação 9, CARACTERIZADO pelo fato de o ato de o nó acessar uma indicação de que um nó de origem pretende direcionar uma mensa- gem para um nó de destino que está mais próximo de um ID de nó determinado em um anel de proximidade alvo dentro da árvore de anéis compreender um ato de o nó receber uma indicação de que um nó de envio pretende direcionar uma mensagem para um nó de desti- no que está mais próximo de um ID de nó determinado em um anel de proximidade alvo que é um sub-anel de um anel colateral do nó de envio.

12.Método, de acordo com a reivindicação 9, CARACTERIZADO pelo fato de o ato de acessar uma indicação de que um nó de origem pretende direcionar uma mensagem para um nó de destino que está mais próximo de um ID de nó determinado em uma proximi- dade alvo que é o anel colateral do nó compreender um ato de receber uma indicação a partir de um aplicativo relacionado com o nó.

13.Método, de acordo com a reivindicação 9, CARACTERIZADO pelo fato de o ato de acessar uma indicação de que um nó de origem pretende direcionar uma mensagem para um nó de destino que está mais próximo de um ID de nó determinado em um anel de proximidade alvo que é o anel colateral do nó compreender um ato de receber uma indica- ção em outra mensagem.

14.Método, de acordo com a reivindicação 13, CARACTERIZADO pelo fato de o ato de receber uma indicação em outra mensagem compreender um ato de receber uma indicação em uma mensagem de outro nó na árvore de anéis.

15.Método, de acordo com a reivindicação 9, CARACTERIZADO pelo fato de o ato de um nó acessar uma indicação de que um nó de origem pretende direcionar uma mensa- gem para um nó de destino que está mais próximo de um ID de nó determinado em um anel de proximidade alvo dentro da árvore de anéis compreender um ato de recebimento de uma indicação de que um nó de origem pretende direcionar uma mensagem para um nó de des- tino que está mais próximo de um ID de nó determinado em um anel colateral do nó de ori- gem.

16.Método, de acordo com a reivindicação 9, CARACTERIZADO pelo fato de o ato de acessar uma indicação de que um nó de origem pretende direcionar uma mensagem para um nó de destino que está mais próximo de um ID de nó determinado em um anel de proximidade alvo dentro da árvore de anéis compreender um ato de receber uma indicação de que um nó de origem pretende direcionar uma mensagem para um nó de destino que está mais próximo de um ID de nó determinado em um sub-anel de um anel colateral do nó de origem.

17.Método, de acordo com a reivindicação 8, CARACTERIZADO pelo fato de um nó determinado que um nó de origem pretende direcionar uma mensagem para um nó de destino que está mais próximo de um ID de nó determinado em um anel de proximidade alvo dentro da árvore de anéis compreender um ato de o nó de origem determinar que o nó de origem pretende direcionar uma mensagem para um nó de destino que está mais próxi- mo de um ID de nó determinado em um anel de proximidade alvo dentro da árvore de anel.

18.Método, de acordo com a reivindicação 8, CARACTERIZADO pelo fato de o ato de identificação de um ou mais nós de entrada conhecidos como sendo nós membros de pelo menos um dentre o anel de proximidade alvo e um anel antepassado do anel de proxi- midade alvo compreender um ato de referência ao conhecimento local no nó para identificar quaisquer nós no anel de proximidade alvo.

19. Método, de acordo com a reivindicação 8, CARACTERIZADO pelo fato de o ato de identificação de um ou mais nós de entrada conhecidos como sendo nós membros de pelo menos um dentre o anel de proximidade alvo e um anel antepassado do anel de proxi- midade alvo compreender um ato de identificação de um nó de entrada que é um membro do anel de proximidade alvo.

20. Método, de acordo com a reivindicação 8, CARACTERIZADO pelo fato de o ato de identificar um ou mais nós de entrada conhecidos como sendo nós membros de pelo menos um dentre um anel de proximidade alvo e um anel antepassado do anel de proximi- dade alvo compreender um ato de identificação de um nó de entrada que é um membro de um anel antepassado do anel de proximidade alvo.

21. Método, de acordo com a reivindicação 20, CARACTERIZADO pelo fato de o ato de identificar um nó de entrada que é um membro de um anel antepassado do anel de proximidade alvo compreender um ato de identificação de um nó de entrada que é um membro de um anel antepassado do anel de proximidade alvo que é o anel antepassado mãos próximo do anel de proximidade alvo.

22. Método, de acordo com a reivindicação 8, CARACTERIZADO pelo fato de o ato de identificar um ou mais nós de entrada conhecidos como sendo nós membros de pelo menos um dentre um anel de proximidade alvo e um anel antepassado do anel de proximi- dade alvo, compreender: um ato de o nó se referir a uma tabela de entrada de conjunto de anel colateral para identificar um nó em uma tabela de entrada de conjunto de anel colateral do nó remetente que está em um anel antepassado do anel de proximidade alvo; e um ato de enviar a mensagem par ao nó identificado no anel antepassado.

23. Método, de acordo com a reivindicação 22, CARACTERIZADO pelo fato de compreender adicionalmente: um ato de o nó no anel antepassado se referir ao conhecimento local para identifi- car quaisquer nós no anel de proximidade alvo.

24. Método, de acordo com a reivindicação 22, CARACTERIZADO pelo fato de compreender adicionalmente: um ato de o nó no anel antepassado se referir a uma tabela de entrada de conjunto de anel colateral para identificar um nó adicional no conjunto de anel colateral do nó identifi- cado que está no anel antepassado mais próximo do anel de proximidade alvo; e um ato de enviar a mensagem para o nó adicional.

25. Método, de acordo com a reivindicação 8, CARACTERIZADO pelo fato de o ato de identificar um ou mais nós de entrada conhecidos como sendo nós membros de pelo menos um dentre um anel de proximidade alvo e um anel antepassado do anel de proximi- dade alvo compreender um ato de o nó utilizar um mecanismo de diretório de nó de entrada para identificar um nó de entrada conhecido como sendo um nó membro do anel de proxi- midade alvo.

26. Método, de acordo com a reivindicação 25, CARACTERIZADO pelo fato de o ato de o nó remetente utilizar um mecanismo de diretório de nó de entrada para identificar um nó de entrada conhecido como sendo um nó membro do anel de proximidade alvo, com- preender: um ato de direcionamento de uma mensagem de solicitação de consulta de nó de entrada para um ponto de encontro; e um ato de recebimento de uma resposta de consulta de nó de entrada correspon- dente à solicitação de consulta, a resposta de consulta de nó de entrada incluindo uma plu- ralidade de nós de entrada.

27. Método, de acordo com a reivindicação 26, CARACTERIZADO pelo fato de o ato de receber uma resposta de consulta de nó de entrada correspondente à solicitação de consulta compreende um ato de receber uma resposta de consulta de nó de entrada do pon- to de encontro.

28. Método, de acordo com a reivindicação 26, CARACTERIZADO pelo fato de o ato de receber uma resposta de consulta de nó de entrada correspondente à solicitação de consulta compreender um ato de recebimento de uma resposta de consulta de nó de entra- da que inclui um ou mais nós de entrada que são registrados com um mecanismo de diretó- rio de nó de entrada.

29. Método, de acordo com a reivindicação 28, CARACTERIZADO pelo fato de o ato de receber uma resposta de consulta de nó de entrada que inclui um ou mais nós de entrada que são registrados com um mecanismo de diretório de nó de entrada compreender um ato de receber uma resposta de consulta de nó de entrada que inclui um ou mais nós de entrada que são registrados com o ponto de encontro.

30. Método, de acordo com a reivindicação 28, CARACTERIZADO pelo fato de o ato de receber uma resposta de consulta de nó de entrada que inclui um ou mais nós de entrada que são registrados com um mecanismo de diretório de nó de entrada compreender um ato de recebimento de uma resposta de consulta de nó de entrada que inclui um nó de entrada que se registrou com o ponto de encontro.

31. Método, de acordo com a reivindicação 28, CARACTERIZADO pelo fato de o ato de receber uma resposta de consulta de nó de entrada que inclui um ou mais nós que são registrados com um mecanismo de diretório de nó de entrada compreender um ato de receber uma resposta de consulta de nó de entrada que inclui um nó de entrada que foi re- gistrado com o mecanismo de diretório de nó de entrada por outra parte.

32. Método, de acordo com a reivindicação 31, CARACTERIZADO pelo fato de o ato de receber uma resposta de consulta de nó de entrada que inclui um nó de entrada que foi registrado com o mecanismo de diretório de nó de entrada por outra parte compreender um ato de receber uma resposta de consulta de nó de entrada que inclui um nó de entrada que foi registrado com o mecanismo de diretório de nó de entrada por outro ponto de encon- tro.

33. Método, de acordo com a reivindicação 26, CARACTERIZADO pelo fato de compreender adicionalmente: um ato de receber uma solicitação de registro de nó de entrada para um nó de en- trada; e um ato de registrar o nó de entrada com o ponto de encontro.

34. Produto de programa de computador para uso em um sistema de computador, o produto de programa de computador servindo para implementar um método de envio de comunicação inter-proximidade em uma árvore de anéis (1900), o produto de programa de computador sendo CARACTERIZADO pelo fato de compreender uma ou mais mídias de armazenamento legíveis por computador possuindo armazenadas nas mesmas instruções executáveis por computador que, quando executadas por um processador fazem com que um nó realize o seguinte: determine que um nó (1311) deve enviar uma mensagem (1903) para um anel cola- teral especificado (21) do nó (1311); acesse uma tabela de entrada de conjunto de anel colateral (1904) configurada pa- ra armazenar entradas de conjunto de anel colateral para o nó, cada entrada de conjunto de anel colateral configurada para indicar um anel colateral (21) do nó (1311) e pelo menos um nó de entrada correspondente (6521) no anel colateral do nó (21); identifique pelo menos uma entrada de conjunto de anel colateral para o anel cola- teral especificado (21) a partir da tabela de entrada de conjunto de anel colateral do nó (1904), cada uma das pelo menos uma entradas de conjunto de anel colateral indicando pelo menos um nó de entrada (6521) do anel colateral especificado (21); e envie a mensagem (1903) para pelo menos um nó de entrada indicado (6521).

35. Produto de programa de computador, de acordo com a reivindicação 34, CARACTERIZADO pelo fato de a mídia de armazenamento legível por computador com- preender memória de sistema.

36. Produto de programa de computador, de acordo com a reivindicação 34, CARACTERIZADO pelo fato de a mídia de armazenamento legível por computador com- preende um disco magnético.

37. Produto de programa de computador para uso em um sistema de computador, o produto de programa de computador servindo para implementar um método de envio de comunicação inter-proximidade em uma árvore de anéis (1900), o produto de programa de computador CARACTERIZADO pelo fato de que compreende uma ou mais mídias de ar- mazenamento legíveis por computador possuindo armazenada nas mesmas instruções exe- cutáveis por computador que, quando executadas por um processador, fazem com que um nó realize o seguinte: determine que um nó de origem pretende direcionar uma mensagem (1998) para um nó de destino que está mais próximo de um ID de nó determinado em um anel de proxi- midade alvo (1221) dento da árvore de anéis (1900); identifique um ou mais nós de entrada (41221) conhecidos como sendo um nó membro de pelo menos um dentre o anel de proximidade alvo (1221) e um anel antepassa- do (221) do anel de proximidade alvo (12221); e envie a mensagem (1998) para um nó de entrada identificado (41221), a mensa- gem (1998) indicando que o nó de entrada identificado (41221) resolva a mensagem (1998) para o nó que possui um ID de nó mais próximo de um nó de destino indicado no anel de proximidade alvo (1221).

38. Produto de programa de computador, de acordo com a reivindicação 37, CARACTERIZADO pelo fato de a mídia de armazenamento legível por computador com- preender memória de sistema.

39. Produto de programa de computador, de acordo com a reivindicação 37, CARACTERIZADO pelo fato de a mídia de armazenamento legível por computador com- preender um disco magnético.