Introduction to the Peer-to-Peer Sockets Project

The Peer-to-Peer (P2P) Sockets Project reimplements Java's standard Socket, ServerSocket,
and InetAddress classes to work on the JXTA peer-to-peer network, rather than on the standard TCP/IP network. It also includes ports of many popular web packages, such as the Jetty web server, the Apache XML-RPC client and server
libraries, and the Apache Jasper JSP engine, to run on the Peer-to-Peer
Sockets framework.

By the end of this article, you will understand the motivation and
need for the P2P Sockets package, how to configure and set up the P2P
Socket libraries to run on your system, how to create and run P2P
server and client sockets, how to work with the P2P InetAddress
class, and security issues and limitations in the framework.

Motivation

The P2P Sockets project is designed for developers interested in:

Returning the end-to-end principle to the Internet.

An alternative peer-to-peer domain name system that bypasses ICANN and Verisign, is completely decentralized, and responds to updates much quicker than standard DNS.

An Internet where everyone can create and consume network services, even if they have a dynamic IP address or no IP address, are behind a Network Address Translation (NAT) device, or blocked by an ISP's firewall.

A Web where every peer can automatically start a web server, host an XML-RPC service, and more, and quickly make these available to other peers.

Having servlets and Java Server Pages work on a peer-to-peer network for increased reliability, easier maintenance, and exciting new end-user functionality.

Playing with a cool technology.

The P2P Sockets project reimplements the standard java.net classes on top of the JXTA peer-to-peer network. "Aren't standard TCP/IP sockets and server sockets already peer-to-peer?" some might ask. Standard TCP/IP sockets and server sockets are theoretically peer-to-peer, but in practice are not, due to firewalls, NAT devices, and
political and technical issues with the Domain Name System (DNS). First, many of the peers on the Internet are given dynamic IP addresses through DHCP, shared or filtered IP addresses through NAT devices, or IP addresses that are very
hard to reach due to firewalls. Creating server sockets under such
conditions is either impossible or requires elaborate application-level
ruses to bypass these restrictions. Second, TCP/IP sockets and
server sockets depend on DNS to resolve
human-friendly host names into IP addresses. DNS is theoretically
semi-decentralized, but on an administrative level, it is centralized
under ICANN, an unresponsive, non-innovative organization. Further, standard DNS does not deal well with edge-peers that have filtered or dynamic IP addresses, and updates take too long to
propagate and have no presence information. Developers who wish to create exciting, new applications that extend DNS into new directions, such as storing instant messaging usernames and presence info in DNS, are
stymied by the DNS system's technical and political issues.

JXTA is an open source project that creates a peer-to-peer overlay network that sits on top of TCP/IP. Every
peer on the network is given an IP-address-like number, even if they are
behind a firewall or don't have a stable IP address. Super-peers on the JXTA network run application-level routers that store special information such as how to reach peers, how to join subgroups of peers,
and what content peers are making available. JXTA application-level relays can proxy requests between peers that would
not normally be able to communicate due to firewalls or NAT devices. Peers organize themselves into peer groups, which scope all search requests and act as natural security containers. Any peer can publish and create a peer group in a decentralized way, and other peers can search for and discover these peer groups using other super-peers. Peers communicate using pipes, which are very similar to Unix pipes. Pipes abstract the exact way in which two peers
communicate, allowing peers to communicate using other peers as intermediaries if they normally would not be able to communicate due to network partitioning.

JXTA is an extremely powerful framework. However, it is not an easy framework to learn, and porting existing software to work on JXTA is not for the faint-of-heart. P2P Sockets effectively hides JXTA by creating a thin illusion that the peer-to-peer network is actually a standard TCP/IP network. If peers wish to become servers, they simply create a P2P server socket with the domain name they want, and the port other peers should use to contact them. P2P clients open socket connections to hosts that are running services on given ports. Hosts can be resolved either by domain name, such as www.nike.laborpolicy, or by IP address, such as 44.22.33.22. Behind the scenes, these resolve to JXTA primitives, rather than
being resolved through DNS or TCP/IP. For example, the host name
www.nike.laborpolicy is actually the NAME
field of a JXTA peer group advertisement. P2P sockets and server sockets work exactly the
same as normal TCP/IP sockets and server sockets. For the technically inclined and those who already understand JXTA, a table exists illustrating how standard TCP/IP concepts such as host name, IP address, etc., map to their JXTA equivalents.

The benefits of taking this approach are many-fold. First, programmers can easily leverage their knowledge of standard TCP/IP sockets and server sockets to work on the JXTA peer-to-peer network without having to learn about JXTA. Second, all of the P2P Sockets code subclasses standard java.net objects, such as java.net.Socket, so existing network applications can quickly be ported to work on a
peer-to-peer network. The P2P Sockets project already includes a
large amount of software ported to use the peer-to-peer network, including a web server (Jetty) that can receive requests and serve
content over the peer-to-peer network; a servlet and JSP engine (Jetty and Jasper) that allows existing servlets and JSPs to serve P2P
clients; an XML-RPC client and server (Apache XML-RPC) for accessing and exposing P2P XML-RPC endpoints; an HTTP/1.1 client (Apache Commons HTTP-Client) that can access P2P web servers; a gateway (Smart Cache) to make it possible for existing browsers to access P2P web sites; and a WikiWiki (JSPWiki)
that can be used to host WikiWikis on your local machine that other peers can access and edit through the P2P network. Even better, all of this software works and looks exactly as it did before being ported. The P2P Sockets abstraction is so strong that porting each of these pieces of software took as little as 30 minutes to several hours. Everything included in the P2P sockets project is open source, mostly under BSD-type licenses, and cross-platform due, to being written in Java.

Because P2P Sockets are based on JXTA, they can easily do things that
ordinary server sockets and sockets can't handle. First, creating server sockets that can fail-over and scale is easy with P2P Sockets. Many different peers can start server sockets for the same host name and port, such as www.nike.laborpolicy on port 80. When a client opens a P2P socket to www.nike.laborpolicy on port 80, it will randomly connect to one of the machines that is hosting this port. All of these server peers might be hosting the same web site, for example, making it very easy to partition client requests across different server peers or to recover from losing one server peer. This is analogous to DNS round-robin,
where one host name will resolve to many different IP addresses to help with load balancing. Second, since P2P Sockets don't use the DNS system, host names can
be whatever you wish. You can create your own fanciful endings, such as www.boobah.cat or www.cynthia.goddess, or application-specific host names, such as Brad GNUberg or Fidget666 for an instant messaging system. Third, the service ports for a given host name can be distributed across many different peers around the world. For example, imagine that you have a virtual host for www.nike.laborpolicy. One peer could be hosting port 80 to
serve web pages, another could be hosting port 2000 for instant messaging, and a final peer could be hosting port 3000 for peers to subscribe to real-time RSS updates. Hosts now become
decentralized coalitions of peers working together to serve requests.