But some P2P applications can be useful in a corporate setting. AOL Instant Messenger and similar applications reside happily on corporate desktops and easily traverse network firewalls. They enable immediate collaboration and instant file sharing. And they do so without the administrative overhead required to set up file shares and file permissions.
The popularity of instant-messaging applications and Napster means that P2P networking is a reality for most networks. In fact, Gartner predicts that by 2003, 30 percent of enterprises will have investigated P2P solutions for content distribution. The research firm also says that half of vendors offering server-based content-management solutions will add P2P functionality to their product offerings by 2005. And the Forrester Group predicts that 24 million consumers will enhance their online activities with P2P services by 2005. In other words, P2P is here to stay.
How P2P Works
In P2P systems, peers communicate symmetrically and operate as both clients and servers. In this way, the peers can make the most of enterprise computing resources. Beefy desktop computers and laptops boast of CPU, RAM and storage resources sufficient to off-load central server processes to desktops. With P2P applications, desktop PCs can become application, communication and file servers, and act as peers on your network.
Many P2P applications, including IM and Napster, rely on a central server. Napster makes use of one to store pointers and resolve addresses. IM uses a central server to initiate P2P communication and maintain a database of registered users. Other applications, including Gnutella and Morpheus, rely on peers to "bootstrap" their presence onto the network.
Pure P2P systems have no need for central servers, though, and fully use a decentralized architecture. There's the rub. Conventional IT wisdom dictates that sharing secure, central resources provides a high degree of resource availability and data integrity. Today's enterprises support fault-tolerant, load-balancing systems that tout 99.999 percent uptime. Most enterprises are beyond supporting a server as a single source of failure.
But there are some very real advantages to decentralized computing when it comes to P2P applications. Decentralized computing resources lie outside the data center, at the edge of the network. Because most enterprises use client/server systems in an n-tier architecture, P2P is decentralized. But this doesn't have to lead to a decentralized-versus-centralized computing war. Decentralized systems often work with centralized systems. For example, centralized mail servers deliver mail to clients but operate in a decentralized manner when moving mail among themselves. Also, BGP (Border Gate Protocol) enables "peering" links among disparate, autonomous systems. In this same way, many P2P applications work within centralized computing environments to deliver content and enable collaboration.
And that's a good thing. Most corporate sites will make greater use of P2P applications over the coming years because of the increase of unstructured data with which employees will work. Unstructured data or data that doesn't fit into a database, data warehouse or data mart is difficult to organize, search and distribute. It can reside on central Web, e-mail and file servers, or on remote desktops. Knowledge workers may store critical files on the local PC for speed and efficiency; remote users may do the same out of necessity. Accessing and distributing content requires collaborative and content-management solutions.
The methods for transferring files and information between computers are as old as the Internet. But these methods primarily are limited to file exchanges between central servers and clients using HTTP, Samba and NFS. These centralized servers have dictated enterprise resource- and file-sharing techniques that ensure security and reliability.
Enterprise file stores are often set up in a hierarchical fashion where users are members of groups organized by department or workgroup. Users have dedicated file stores, and they share files with other users in the same group. This works fine if your enterprise has autonomous, independent workgroups that rarely have a need to share information. But enterprises looking to form collaborative teams across departments will look to decentralized strategies, which may include P2P applications.
Spreading Gnutella
The archetype for decentralized P2P applications is Gnutella. Instead of using central servers, a Gnutella Network (gNet) leverages peers. For example, when a computer named Alfa executes Gnutella's "servant" application, it acts as both client and server. Alfa's servant broadcasts its state of the union ("Alfa is alive") to nearby Gnutella servants. Those servants echo Alfa's affirmation to all the servants connected to them. This pattern continues until the TTL (time to live) constraint has expired (Gnutella servants reject network messages with high TTL numbers).
Once Alfa is alive, it can search the contents of the shared directories on peer machines. The search request goes to all gNet members, starting with the computers closest to Alfa. Those computers, in turn, send the request to other connected servants. If one of the computers in gNet has a file that matches the search request, it transmits the file information back through all the computers in the pathway to Alfa. Alfa collects a list of files matching the search request, selects the file and downloads it directly from the target computer.
In this way, Gnutella eliminates reliance on a central server and removes it as a central point of failure. This method also relieves the indexing burden. Central indexing servers can crater under their own weight and make searching a long and tedious task. For example, the old IRC system tracked all channels and users registered by all servers in the system. The servers were so busy passing their indexes back and forth they became unavailable for other tasks.
But gNets and P2P file sharing have some pitfalls. First, they require large amounts of bandwidth at the edge of the network, where the bandwidth may not support the multiplicity of file transfers. Other potential problems include unsatisfactory response times and lack of QoS (Quality of Service) criteria for resource availability. If a target machine is not online, it is not an available resource. This file sharing also permits unmitigated access to indexing services on servants.
RSS
