1 / 23

Protocolos PRP e PDP

Protocolos PRP e PDP. Aldo Carvalho e Marcos Lubas. Protocolos JXTA. Operações da rede virtual são definidas em termos de protocolos Se dois peers querem se comunicar, só precisam entender o protocolo Conseqüência: Peers podem: – Ser implementados em diferentes linguagens;

solada
Download Presentation

Protocolos PRP e PDP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Protocolos PRP e PDP Aldo Carvalho e Marcos Lubas

  2. Protocolos JXTA • Operações da rede virtual são definidas em termos de protocolos • Se dois peers querem se comunicar, só precisam entender o protocolo • 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).

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

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

  5. Peer Membership Protocol Peer Membership Protocol Peer Group Peer Group Peer Information Protocol Peer Information Protocol Peer Binding Protocol Peer Binding Protocol Peer Discovery Protocol Peer Discovery Protocol Peer Peer Peer Resolver Protocol Peer Resolver Protocol Resolver Resolver Peer EndPoint Protocol Peer EndPoint Protocol EndPoint EndPoint Transport

  6. Peer Discovery Protocol • 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.

  7. Peer Discovery Protocol • 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.

  8. Peer Discovery Protocol • 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.

  9. Peer Discovery Protocol • A intenção é para que o PDP forneça a infra-estrutura 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.

  10. Peer Discovery Protocol • 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.

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

  12. Requisição Peer Peer • BroadcastUsando todos os Peer Endpoints conhecidos “JXTA://PDP/DiscoveryQueryMsg” • Unicast Enviando para um Peer rendezvous “JXTA://PDP/DiscoveryQueryMsg” • Unicast <PeerAdvertisement> or <PeerGroupAdvertisement> “JXTA://PDP/DiscoveryResponseMsg”

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

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

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

  16. XML da pergunta <?xml version=”1.0” encoding=”UTF-8”?> <jxta:ResolverQuery xmlns:jxta=”http://jxta.org”> <HandlerName> . . . </HandlerName> <Credential> . . . </Credential> <QueryID> . . . </QueryID> <SrcPeerID> . . . </SrcPeerID> <Query> . . . </Query> </jxta:ResolverQuery>

  17. HandlerName: 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. • QueryID: Opcional, contém um long int(porém no formato de string) para a identificação da mensagem.

  18. SrcPeer: 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.

  19. XML da resposta <?xml version=”1.0” encoding=”UTF-8”?> <jxta:ResolverResponse xmlns:jxta=”http://jxta.org”> <HandlerName> . . . </HandlerName> <Credential> . . . </Credential> <QueryID> . . . </QueryID> <Response> . . . </Response> </jxta:ResolverResponse>

  20. Bibliografia • http://www.gta.ufrj.br/seminarios/semin2003_1/william/Tecnologia.htm • http://www.samspublishing.com/articles/article.asp?p=28514&seqNum=11 • http://spec.jxta.org/nonav/v1.0/docbook/JXTAProtocols.html • http://www.gta.ufrj.br/grad/04_1/p2p/index.html • http://www.brendonwilson.com/projects/jxta-book/ • Capítulos 4 e 5.

More Related