The Jockey Hub intentionally keeps several of the core peer-to-peer concepts out of scope. By providing only application level API's we are able to provide a simpler interface to the end programmer.
Although there isn't a uniform description for a peer-to-peer system, a survey of peer systems reveals the following major feature categories:
The ability to find other peers as well as other resources on the network is a critical part of a peer framework. Typically, peer networks will assign certain peers to have more responsibility about capturing neighborhood information. These nodes may be elected or be pre-assigned. Either way, providing some mechanism for finding resources is a common component of every peer framework.
After another peer has been found on the network, the next logical step is to communicate with it. A peer system will facilitate general messaging between nodes. Usually the framework will provide a request/response mechanism.
[Note: In Jockey, only the Directory and Messaging Services API's are provided to the application programmer.]
Most peer-to-peer systems strive toward having a highly decentralized structure. From an implementation perspective, this obviously means that sole reliance on central servers to provide routing and network topology are not a preferred means. Instead, a peer network will attempt to map out neighborhood topologies and give peers and routers special intelligence on moving information from one peer to the next. Adaptive peer networks will use the network flow information to make "smarter" routes between peers.
People will often use the phone as an analogy for a peer-to-peer system. A phone call might hop through several nodes in the process of linking the callee and the caller. Once this "call setup" is accomplished, the two parties will engage in a conversation. Sessions are optional components that are found in many p2p systems, but not all.
New P2P systems like JXTA are providing transport abstraction. This service allows the framework to plug-in new network transport protocols like TCP/IP, IPX/SPX, SNA, etc. The goal is for the peer-to-peer framework to provide independence from the networking protocol. Due to the vast differences in network protocol capabilities, this feature provides some abstraction (as well as bridging), but does not deliver transport ubiquity.
Network management deals with the process of managing and monitoring a peer network. This includes problem diagnosis & resolution, configuration management and change management.
A peer usually has some semi-static information that is associated with it. A peer might have a default user, a static IP address, settings on bandwidth throttles or other configurable settings. This information will usually reside in a text file on the peer computer or be accessible through a GUI interface. Additionally, it is common to have this information managed through a service provider API.
[Note: API's to services like Configuration and Transport are typically presented in a special "service provider interface".]