[p2p-hackers] Project Announcement: P2P Sockets
Hi everyone. I just posted the web site, source code, and two tutorials for the Peer-to-Peer Sockets Project at http://p2psockets.jxta.org. The source code represents a working, 1.0 beta 1 release, with several pieces of software, such as Jetty and XML-RPC Client and Server libraries, already ported onto this new API. I have spent the last month and a half working full time on this. Here are some more details on the project: ------------------------ Are you 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? * easily adding peer-to-peer functionality to your Java socket and server socket applications? * having your servlets and Java Server Pages work on a peer-to-peer network for increased reliability, easier maintenence, and exciting new end-user functionality? * playing with a cool technology? If you answered yes to any of the above, then welcome to the Peer-to-Peer Sockets project! The Peer-to-Peer Sockets Project reimplements Java's standard Socket, ServerSocket, and InetAddress classes to work on a peer-to-peer network rather than on the standard TCP/IP 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, Network Address Translation (NAT) devices, and political and technical issues with the Domain Name System (DNS). The P2P Sockets project deals with these issues by re-implementing the standard java.net classes on top of the Jxta peer-to-peer network. Jxta is an open-source project that creates a peer-to-peer overlay network that sits on top of TCP/IP. Ever 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 which store special information such as how to reach peers, how to join sub-groups 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 a peer wishes to become a server 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. 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, they 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 analagous to DNS round-robining, 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 them to. 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. Two tutorials are available: * Introduction to Peer-to-Peer Sockets - http://www.codinginparadise.org/p2psockets/1.html * How to Create Peer-to-Peer Web Servers, Servlets, JSPs, and XML-RPC Clients and Servers - http://www.codinginparadise.org/p2psockets/2.html Download P2PSockets-1.0-beta1.zip, (released 9-5-2003) which contains the core package and extensions both compiled and in source form, at http://www.codinginparadise.org/p2psockets/P2PSockets-1.0-beta1.zip Thanks, Brad GNUberg bkn3@columbia.edu _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences ----- End forwarded message ----- [demime 0.97c removed an attachment of type application/pgp-signature]
participants (1)
-
Brad Neuberg