- Protocol and API
- JXTA Goals
- JXTA Peer and Java
- Overview of the JXTA Protocols JAVA API
- Summary of Java API for JXTA Protocols
- Where JXTA Applications Begin
- The Peer
- Starting JXTA
- Peer Discovery Protocol API
- Peer Resolver Protocol API
- Peer Information Protocol
- Peer Membership Protocol
- Pipe Binding Protocol API
- Peer Endpoint Protocol
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Peer Information Protocol
The peer information protocol is a specific implementation of a peer resolver query. When a peer is first initialized, it publishes its PeerAdvertisement that is picked up by at least one rendezvous. When a request for a specific peer's information is requested, a query is made to locate the PeerAdvertisement. Recall that the PeerAdvertisement contains endpoint information for contacting the peer. Using the endpoint, the peer is contacted directly to obtain its peer information.
PeerInfoService
The PeerInfoService interface is very simple and very complete. To compare it to the ResolverService, the interface has more methods, but this is because the behavior is more constrained. The only actions are to locate peer information and manage information. You may recognize some of the functionality as being similar to the DiscoveryService. The two services are very similar and manage data in the same way using the content manager to store advertisements. In the PeerInfoService, the only advertisement that is cached is the PeerInfoAdvertisement. The UML for this advertisement is shown in Figure 3.10.
){kind=link}
Figure 3.10 UML for PeerInfoService.
The PeerInfoAdvertisement
The PeerInfoAdvertisement is a bit different from the other advertisements in JXTA because it includes volatile data like uptime. The UML for the advertisement is shown in Figure 3.11.
){kind=link}
Figure 3.11 UML for PeerInfoAdvertisement.
The PeerInfoListener
The acquisition of a peer's info will vary according to how the information is finally accessed. Because you cannot predict the time it takes to get the peer info, the API uses a listener to notify the application when the information is available.
The interface of the listener is quite simple, with only one method. The PeerInfoResponse method passes a PeerInfoEvent to the listener. The PeerInfoEvent holds the peer info advertisement retrieved. The UML diagram in Figure 3.12 shows the specification for both the PeerInfoListener interface and the PeerInfoEvent.
){kind=link}
Figure 3.12 UML PeerInfoListener and PeerInfoEvent.
Flushing Advertisements
PeerInfoAdvertisement, like other advertisements, will automatically expire. However, you may want to remove peer info advertisements on a regular basis to ensure that the information is up to date. You should also remove the advertisements if your application accesses multiple peers because that may impact memory.
Why Use the Peer Info Protocol?
Of all the protocols, peer info probably seems the least useful in its current implentation. The protocol can help gauge the health of the network with uptime statistics and other information about messages. Overall, the protocol can provide interesting information, but not a lot.
You could write your own implementation of the protocol and use it in your custom groups. By implementing your own, the amount and richness of the data can be made to fit your requirements. The API may not lend its self to easy extension, so you are probably better off creating your own protocol.