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; – Ser executados em diferentes tipos de máquinas; – Transmitir mensagens em diferentes camadas de protocolos (TCP, HTTP, Bluetooth). 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) 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 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 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. 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. 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. Peer Discovery Protocol 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 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 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. Requisição Peer Peer Broadcast Usando todos os Peer Endpoints conhecidos “JXTA://PDP/DiscoveryQueryMsg” Unicast Enviando para um Peer rendezvous “JXTA://PDP/DiscoveryQueryMsg” Unicast <PeerAdvertisement> or <PeerGroupAdvertisement> “JXTA://PDP/DiscoveryResponseMsg” Protocolos JXTA Peer Resolver Protocol (PRP) Protocolo fundamental Mensagens são pares pergunta-resposta Respostas assíncronas 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 Resolver Service 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:ResolverQuery xmlns:jxta=”http://jxta.org”> <HandlerName> . . . </HandlerName> <Credential> . . . </Credential> <QueryID> . . . </QueryID> <SrcPeerID> . . . </SrcPeerID> <Query> . . . </Query> </jxta:ResolverQuery> 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. 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. 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> Bibliografia http://www.brendonwilson.com/projects/jxta-book/ Capítulos 4 e 5. 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