Hovedfunn

Nesta seção serão descritos os detalhes do sistema em funcionamento bem como da interação entre os componentes quando em operação. Uma breve descrição dos papéis desempenhados pelos participantes permitirá agrupá-los em duas categorias principais: a dos proprietários dos objetos da camada de aplicação e a dos usuários destes objetos. Obviamente, a relação entre os proprietários e usuários em uma arquitetura de nomes como esta é relativamente fluída, podendo-se admitir, de fato, dois papéis simultâneos para a maioria dos participantes. A partir desta categorização primária, três principais classes de operações são delineadas:

• Cenário I: Um proprietário de um objeto da camada de aplicação habilita seus serviços (i.e. disponibiliza seus serviços à comunidade de usuários).

• Cenário II: Um usuário acessa um objeto da camada de aplicação.

• Cenário III: Um objeto da camada de aplicação, já publicado e acessível, é movido ou replicado, ficando temporariamente inacessível.

Ainda que elementares estas definições cobrirão a absoluta maioria de operações desempenhadas na Arquitetura de Nomeação, restando outras operações complementares como gerenciamento dos componentes ou combinações lineares dos três

cenários ilustrados. Uma descrição detalhada destas operações juntamente com a função de cada componente ativo no processo será delineada a seguir.

5.5.1 Cenário I: Um proprietário de um objeto da camada de aplicação

deseja habilitar seu serviço

Almejando publicar suas aplicações, proprietários devem registrar seus identificadores (i.e. referências aos seus objetos) na infra-estrutura de nomeação. Vislumbrar- se um cenário em que nenhum de seus nomes esteja registrado (para finalidade de completude do caso ilustrado). Ou seja, este é o exemplo em que um proprietário pretende ingressar no mercado com uma nova “marca” desejando disponibilizar serviços em um novo servidor.

O primeiro passo a ser tomado por um proprietário consiste na obtenção de um EID para identificar seu servidor, que poderá, então, ser mapeado para o IP corrente atribuído ao seu nó (aquele que hospeda seus serviços). Em virtude da natureza de gerenciamento distribuída do subsistema de resolução de referências EID RRS implementado em uma DHT, todos os proprietários devem escolher/obter um identificador para seu EID. Então devem associá-lo a um ou mais endereços IP, assinar/certificar o mapeamento estabelecido para o objeto com a Autoridade Certificadora responsável (esta também será utilizada pelo SID) e submetê-lo à DHT EID.

O processo de seleção de um EID é bem definido, consistindo no hash criptográfico de um identificador de nó HI (Host Identifier), que representa a chave criptográfica pública de um par de chaves pública/privada (gerado aleatoriamente). A natureza de um EID, representado por um identificar opaco (i.e. sem semântica) compreendido por uma longa cadeia de bits (na ordem de centenas) com representação hexadecimal apresenta uma probabilidade de colisão (cenário em que dois proprietários escolhem o mesmo EID) muito baixa (da ordem de 2-100_{). Uma discussão mais apurada será}

delineada no próximo capítulo.

Em um cenário hipotético de colisão, a DHT somente reescreverá o EID no caso em que simultaneamente este e a senha do proprietário venham a ser iguais. Então, a dupla <IP, certificado> apontada por tal EID será atualizada, cenário em que o próprio proprietário deseje alterar seus dados, ou um atacante tenha obtido o êxito em furtar a senha e conhecer o hash da vítima. Não se pode descartar, em absoluto, uma terceira possibilidade que consiste na chance de isto acontecer por acaso, entretanto esta probabilidade seria representada pela combinação da chance de colisão do certificado gerado juntamente com a

probabilidade da escolha fortuita da mesma senha pelos dois proprietários, um cenário praticamente surreal.

De posse do EID registrado, o proprietário pode proceder agora para a obtenção de um SID registrado. Para tal, este deverá obter um SID (gerado aleatoriamente) e concatenar a este uma lista de elementos requeridos pelo sistema no acesso a objetos da camada de aplicação (e.g. disponibilidade, confiabilidade, latência, portas, rotas, protocolos, EIDs). Em seguida, deverá obter um certificado assinado pela organização certificadora do sistema e também poderá obter um terceiro certificado, designado por uma entidade externa (neste contexto, externa remete-se a uma terceira organização que possui autoridade e confiabilidade consagrada) para garantir a QoSC (Qualidade de Serviço de Conteúdo) dos seus objetos.

De posse destas informações, o proprietário encontra-se apto a registrar as entradas referente ao mapeamento do seu objeto da camada de aplicação no subsistema de resolução de referências RRS SID, que é implementado na forma de uma DHT. As mesmas considerações quanto à probabilidade de colisão de chaves EID podem ser feitas aqui, visto que o tamanho máximo das chaves deve ser o mesmo e a DHT utilizada também.

O processo pode ser finalizado com o registro das informações sobre seu serviço em um diretório da camada de aplicação de duas possíveis maneiras. O proprietário pode solicitar, ativamente, que este catalogo seja feito e publicado através da submissão de termos de pesquisa associados ao seu SID ou, passivamente, durante o processo proativo de catalogo realizado pelas máquinas de busca (i.e. search engines tais como Google, Altavista, Yahoo, Cadê [84; 85] e etc) em que termos semânticos serão associados ao seu SID. De maneira geral, este mecanismo não apresenta mudanças fundamentais quando comparado ao mecanismo de registro/publicação de informações realizado pelas máquinas de busca da Internet, sendo a única mudança relevante (e, positiva) o novo apontamento de objetos para SIDs ao invés de para IPs.

5.5.2 Cenário II: Um usuário acessa um objeto da camada de aplicação

Neste cenário um usuário obterá acesso a um objeto da camada de aplicação. Após três resoluções de nomes, localiza-se o endereço IP do servidor que hospeda o serviço procurado e possibilita-se, portanto, que a comunicação se estabeleça através da infra-

estrutura de roteamento da Internet, com mínimas ou nenhuma alteração (que se existirem, estarão localizadas nas aplicações, que tipicamente utilizarão o endereço IP em suas operações finais de conexão).

O primeiro passo, do ponto de vista dos usuários, consiste em obter o SID correspondente ao objeto procurado. Isto pode ser feito de duas formas, primeiro, e menos provável, memorizando-se o SID desejado (a diversidade de métodos passíveis de serem utilizados para publicar um SID não representa o objetivo principal deste trabalho, contudo, não se faz a suposição de que os usuários deverão decorá-lo, assim como os usuários hoje não memorizam freqüentemente os endereços IP), ou através da obtenção precedente de uma busca por termos similares em uma máquina de busca.

Obtido o SID procurado, o usuário pode submetê-lo ao subsistema de resolução de referências SID RRS almejando como resposta uma lista de informações de como acessar o objeto e suas informações de QoSC. Neste contexto, pode-se esperar que informações ilegítimas possam ser retornadas ao usuário fruto de colisões maliciosas ou acidentais. Em face destes problemas, o usuário pode requisitar à CA da arquitetura informações sobre a assinatura destas informações, podendo então, optar pelas tuplas legítimas.

Obtidas as informações legítimas, um dos campos desta tupla será uma lista de EIDs que o usuário submeterá ao subsistema de resolução de referências EID RRS almejando uma lista de endereços IP como resposta. A partir deste ponto, ambas as partes, servidor e cliente, do objeto da camada de aplicação podem iniciar uma conexão utilizando a infra- estrutura regular de roteamento IP da Internet. Obviamente, a resposta a uma consulta EID pode conter diversos endereços IPs ilegítimos e, de forma análoga, o usuário pode recorrer à CA da arquitetura para garantir que as informações são confiáveis (i.e. possuem uma assinatura válida) ou devem ser descartadas (i.e. não possuem assinatura correspondente).

5.5.3 Cenário III: Um objeto da camada de aplicação é movido ou

replicado.

Um objeto da camada de aplicação mudará sua localização sempre que mudar seu endereço IP (i.e. seu ponto de acesso à rede registrado dentro do EID) ou qualquer informação de acesso (EID, rota, porta, informações de QoSC) do SID. Em ambos os casos é assumido que o usuário já obteve o SID e o EID correspondente e que a comunicação, ou já esta estabelecida (o que significa que o usuário terá que submeter o EID novamente para obter o novo endereço IP ou o SID para obter as novas informações), ou irá ser estabelecida. Neste

último caso, o usuário deverá obter o EID, SID ou IP correspondente de um cache local, o que implicará no mesmo processo de nova submissão de informações precedido de uma falha no acesso a um objeto (com a informação local).

Pode-se inferir, baseando-se em uma variedade de fatos, que os endereços IP apresentarão mudanças mais freqüentes que as referências EIDs, que por sua vez, apresentarão mudanças mais freqüentes que os SIDs. Um argumento concreto nesta direção consiste na própria natureza de cada identificador, haja vista que endereços IP são muito mais efêmeros em virtude de fatores advindos dos protocolos DHCP/NAT, da mobilidade de nós ou de cenários de multihoming. Os identificadores EID, por sua vez, só apresentarão mudanças no momento em que um objeto da camada de aplicação for movido de nó para outro, cenário muito menos freqüente do que o primeiro dados os aspectos tecnológicos e práticas arquiteturais na implantação de aplicações, tais como: o uso crescente de máquinas virtuais, a replicação de conteúdo e a adoção de balanceadores de carga. Vale ressaltar aqui que o objetivo do Princípio 3# era comportar naturalmente a inserção de middleboxes na Arquitetura de Nomes Com Múltiplas Camadas, fato que pode ser vislumbrado agora neste ambiente. Além disso, ao analisar a natureza do SID que possui informações detalhadas sobre o objeto da camada de aplicação referenciado (as quais podem ser alteradas livremente), um cenário ainda mais improvável de sofrer mudanças se estabelece.

Diante das considerações supracitadas, a nova arquitetura apresentará um dinamismo diferente em virtude da ocorrência de mobilidade de objetos da camada de aplicação. A nova prática adotada pelos usuários quando for detectada a interrupção de uma conexão consiste em primeiro contatar o subsistema EID RRS para obter um novo endereço IP, e então, na persistência da ruptura da comunicação, contatar o subsistema SID RRS por novas informações. Se ainda assim, a interrupção na comunicação persistir, o subsistema de Canonização RRS deverá ser explicitamente acessado (i.e. uma intervenção humana ativa será necessária).

Nesta conjuntura, a questão remanescente versa sobre a transparência apresentada pela aplicação que sofreu a ruptura de comunicação. Obviamente, algumas aplicações, tais como as que possuem requisitos de tempo real (i.e. aplicações isócronas, como transmissões de vídeos online ou voz sobre IP), apresentarão perdas perceptíveis aos usuários devido à sua natureza inerente que requer a provisão de dados instantânea. Aplicações interativas, bem como as do tipo requisição/resposta (request/response) e em lote (batch applications) podem lançar mão de diversos artifícios para contornar esta ruptura, ou

seja, para tornarem-se mais transparentes, tais como o armazenamento em memórias ágeis (bufferization), a compactação e o uso de códigos de recuperação.

Para ilustrar este cenário, podemos citar a Rede Virtual Overlay HIP que estabelece conexões TCP baseadas não mais em endereços IP, mas em identificadores de nós análogos ao EID apresentado. Combinando este recurso com temporizadores adequados em uma aplicação, o HIP criou cenários em que a mobilidade de IPs é tolerada nas comunicações já em trânsito sem causar-lhes uma quebra de semântica. Desta forma, rupturas temporárias seguidas de um novo processo de resolução de referências finito (i.e. inferior aos limites de tempo dos temporizadores), tornam-se transparente aos usuários.