Protocolos PRP e PDP Aldo Carvalho e Marcos

  • Slides: 23
Download presentation
Protocolos PRP e PDP Aldo Carvalho e Marcos Lubas

Protocolos PRP e PDP Aldo Carvalho e Marcos Lubas

Protocolos JXTA Operações da rede virtual são definidas em termos de protocolos l Se

Protocolos JXTA Operações da rede virtual são definidas em termos de protocolos l Se dois peers querem se comunicar, só precisam entender o protocolo l Conseqüência: Peers podem: – Ser implementados em diferentes linguagens; – Ser executados em diferentes tipos de máquinas; – Transmitir mensagens em diferentes camadas de protocolos (TCP, HTTP, Bluetooth). l

Protocolos JXTA Estruturas de dados XML l Não precisa que peer tenha capacidade total

Protocolos JXTA Estruturas de dados XML l Não precisa que peer tenha capacidade total de processamento XML l Peer com pouco recurso: pré-compila mensagens na representação binária (não precisa processar XML) l

Protocolos JXTA Protocolos são expressos em termos de troca de mensagens l Em algum

Protocolos JXTA Protocolos são expressos em termos de troca de mensagens l Em algum ponto deve traduzir a mensagem (bind) na linguagem l Bindings: Java, C, C++, Perl, Python, Smalltalk. . . l Protocolo independente da linguagem l

Peer Membership Protocol Peer Group Peer Information Protocol Peer Binding Protocol Peer Discovery Protocol

Peer Membership Protocol Peer Group Peer Information Protocol Peer Binding Protocol Peer Discovery Protocol Peer Resolver Protocol Resolver Peer End. Point Protocol End. Point Transport

Peer Discovery Protocol l l Na maioria das vezes, os Peers, os grupos, e

Peer Discovery Protocol l l Na maioria das vezes, os Peers, os grupos, e as outras informações não são conhecidas até que um peer use o serviço de descoberta. As aplicações podem ter algum conhecimento interno, tais como grupos do peer e outras informações. Entretanto, a maioria de Peers sabem muito pouco sobre o que está disponível. No Java API, os advertisements que são descobertas são armazenados localmente. Por causa do cache local, há dois tipos de descoberta, a descoberta local e a descoberta remota. A descoberta remota usa o resolver para encontrar advertisements, quando a descoberta local usa o cache.

Peer Discovery Protocol l l O protocolo Peer Discovery Protocol é usado para descobrir

Peer Discovery Protocol l l O protocolo Peer Discovery Protocol é usado para descobrir todos os recursos publicados do peer. Os recursos são representados por advertisements. Um recurso pode ser um peer, um peergroup, um pipe, um módulo, ou qualquer outro recurso que tiver advertisements. Cada recurso deve ser representado por um advertisements.

Peer Discovery Protocol l O protocolo de descoberta do peer (PDP) permite a um

Peer Discovery Protocol l O protocolo de descoberta do peer (PDP) permite a um peer de encontrar advertisements em seu grupo. Os serviços feitos sob encomenda da descoberta podem escolher leverage PDP. Se um grupo do peer não necessitar definir seu próprio protocolo da descoberta, pode usar o peergroup PDP.

Peer Discovery Protocol l l A intenção é para que o PDP forneça a

Peer Discovery Protocol l l A intenção é para que o PDP forneça a infraestrutura essencial de descoberta para facilitar o trabalho de outros serviços de alto nível na descoberta. Em muitas situações, a informação da descoberta é melhor tratada por um serviço de alto nível, porque o serviço pode ter um conhecimento melhor da topologia do grupo.

Peer Discovery Protocol l O protocolo de PDP fornece um mecanismo básico para descobrir

Peer Discovery Protocol l O protocolo de PDP fornece um mecanismo básico para descobrir advertisements e possibilita também que serviços de alto nível e aplicações participem no processo de descoberta. Os serviços devem dar sugestões para melhorar a descoberta (se decidir que advertisements são mais valiosos ao cache). O protocolo de PDP utiliza o protocolo do resolver para distribuir perguntas e respostas.

Classes API de descoberta do Peer l A descoberta API é executada como um

Classes API de descoberta do Peer l A descoberta API é executada como um serviço para peer groups. O API consiste nas seguintes peças chaves: Ø Discovery. Service - Esta é a interface base que é usada acessar as funcionalidades do núcleo do PDP. Discovery. Listener – É usado para esperar as mensagens remotas da descoberta. Discovery. Event - O evento passou ao listener que contém a informação sobre os advertisements descobertos. Discovery. Response. Msg - O Payload real dos dados que contém as informações sobre os advertisements descobertos Discovery. Service. Impl - Execução da interface do Discovery. Service. Ø Ø

Requisição Peer l Broadcast Usando todos os Peer Endpoints conhecidos “JXTA: //PDP/Discovery. Query. Msg”

Requisição Peer l Broadcast Usando todos os Peer Endpoints conhecidos “JXTA: //PDP/Discovery. Query. Msg” l Unicast Enviando para um Peer rendezvous “JXTA: //PDP/Discovery. Query. Msg” l Unicast <Peer. Advertisement> or <Peer. Group. Advertisement> “JXTA: //PDP/Discovery. Response. Msg”

Protocolos JXTA Peer Resolver Protocol (PRP) l Protocolo fundamental l Mensagens são pares pergunta-resposta

Protocolos JXTA Peer Resolver Protocol (PRP) l Protocolo fundamental l Mensagens são pares pergunta-resposta l Respostas assíncronas

Protocolos JXTA Outros protocolos que precisam de mecanismo pergunta-resposta usam PRP l Pergunta não

Protocolos JXTA Outros protocolos que precisam de mecanismo pergunta-resposta usam PRP l Pergunta não é endereçada ao peer, mas a um handler (tratador) l Peer registra um handler, que pode responder perguntas l Perguntas e respostas podem se perder l

Resolver Service l l Permite que sejam trocadas mensagens(perguntas e respostas) entre os membros

Resolver Service l l Permite que sejam trocadas mensagens(perguntas e respostas) entre os membros do peer group Registra e desregistra handlers

XML da pergunta <? xml version=” 1. 0” encoding=”UTF-8”? > <jxta: Resolver. Query xmlns:

XML da pergunta <? xml version=” 1. 0” encoding=”UTF-8”? > <jxta: Resolver. Query xmlns: jxta=”http: //jxta. org”> <Handler. Name>. . . </Handler. Name> <Credential>. . . </Credential> <Query. ID>. . . </Query. ID> <Src. Peer. ID>. . . </Src. Peer. ID> <Query>. . . </Query> </jxta: Resolver. Query>

l l l Handler. Name: Elemento obrigatório que contém um nome único do tratador

l l l Handler. Name: Elemento obrigatório que contém um nome único do tratador que o serviço Resolver deve chamar para executar a pergunta. Credential: Elemento opcional, elemento que contém uma identificação do peer de origem e se ele tem autorização para enviar mensagens ao grupo. Query. ID: Opcional, contém um long int(porém no formato de string) para a identificação da mensagem.

l l Src. Peer: Obrigatório, contém a ID do peer que envia a pergunta

l l Src. Peer: Obrigatório, contém a ID do peer que envia a pergunta (no formato JXTA URN). Query: Obrigatório, contém uma string que será enviada para um tratador remoto. Essa string pode ser qualquer coisa é responsabilidade do tratador entender, processar e, se possível, gerar uma resposta.

XML da resposta <? xml version=” 1. 0” encoding=”UTF-8”? > <jxta: Resolver. Response xmlns:

XML da resposta <? xml version=” 1. 0” encoding=”UTF-8”? > <jxta: Resolver. Response xmlns: jxta=”http: //jxta. org”> <Handler. Name>. . . </Handler. Name> <Credential>. . . </Credential> <Query. ID>. . . </Query. ID> <Response>. . . </Response> </jxta: Resolver. Response>

Bibliografia http: //www. brendonwilson. com/projects/jxtabook/ l. Capítulos 4 e 5. l l l http:

Bibliografia http: //www. brendonwilson. com/projects/jxtabook/ l. Capítulos 4 e 5. l l l http: //www. gta. ufrj. br/seminarios/semin 2003_1/william/Tecnologia. htm http: //www. samspublishing. com/articles/article. asp? p=28514&seq. Num=11 http: //spec. jxta. org/nonav/v 1. 0/docbook/JXTAProtocols. html http: //www. gta. ufrj. br/grad/04_1/p 2 p/index. html