The Tale of Mandragore
P2P and Gnutella aficionado Ben Houston sounded the alarm in late February that Gnutella searches were turning up odd results: Windows-executable files consistently 8,192 bytes in size and with names that precisely matched any search a user initiated. After a user downloads and runs one of these files, it seems nothing happens. Behind the scene, however, a program known as Mandragore installs itself on the PC and hides.
There may be variants, but the version Clip2 studied on Windows 9x/ME comes out of hiding when a Gnutella servent listening on port 6346 is started. At that point, Mandragore initiates a connection to the servent - it's readily visible as an "incoming" connection in the servent's connection screen, with an address identical to that of the local host. From this point on, the Gnutella servent thinks Mandragore is another Gnutella host, and follows the usual procedure of forwarding all incoming queries to it from the network. Mandragore returns the aforementioned misleading response to each query and the unwitting servent passes these responses back out to the network. In this way, Mandragore advertises itself so that it will be downloaded again and thus propagate to new hosts. Although this is the extent of the known actions of Mandragore, and the program is therefore mostly harmless, it shines the way for substantially more malicious developments.
The first line of defense against programs like Mandragore is to heed the old refrain to not run any program that you do not have a basis to trust. The last line of defense is a good PC firewall. In Clip2's testing, Zone Labs' ZoneAlarm product detected Mandragore's initial attempt to establish communications and offered to block it.
Fortunately, not all Gnutella development in recent weeks has been nefarious.
The Reflective Defender
The scalability of Gnutella's approach to enabling the transient Web is a topic of much interest and frequent discussion. Clearly, a system involving broadcasting messages has the potential to easily become so thick with traffic as to overload the individual nodes on the network, and Gnutella has a history of such trouble.
One solution is to tier the network so that the more capable nodes carry more traffic and less capable ones carry less. To that end, Clip2 introduced the "super peer" concept of a Gnutella proxy-and-index server, embodied in the Clip2 Reflector program. Since the Reflector's introduction, a new wave of servent developers has discussed endowing their servents with Reflector-like capabilities. Recently, in a significant new development that might positively signal the arrival of a third generation of Gnutella applications and negatively signal the proprietary segmentation of the network, one developer has gone and done it.
BearShare 3.0.0, as of this writing available as an alpha build at BearShare.net, includes a new set of features collectively termed Defender. This version of BearShare can operate in three different modes: peer, client or server. In peer mode, it operates like any other Gnutella servent; you can think of this as BearShare Classic mode. The client and server modes are, however, rather different.
|Figure 1. BearShare lets you choose between Client, Peer, and Server modes.|
In client mode, BearShare broadcasts queries to discover BearShare hosts running in server mode, which might be called Defenders. The BearShare UI contains a Servers tab that lists currently known Defenders as discovered via the querying process. BearShare does not rely on a centralized listing of currently running Defenders. Instead, it relies on the same sort of decentralized ping-pong process normal Gnutella nodes use to discover each other.
These pings and pongs are encoded as special queries and query responses so that they will be relayed by other types of Gnutella applications and earlier versions of BearShare, although there is no guarantee that future versions of other applications will relay this BearShare-specific traffic. While in client mode, BearShare can make one outgoing connection to a Defender, and the client takes no incoming connections from other hosts. When it needs functionality not addressed by the Gnutella protocol, BearShare utilizes a closed, proprietary protocol for client-server communication. This enables clients connected to a given Defender to chat with each other, see how many other clients are currently connected, and so on.
In server mode, a BearShare user can define a server name and customize other characteristics of his Defender. In particular, he can configure it as a "public access" or "private access" Defender. In public-access mode, the Defender operator can specify a language for his chat room and a content subject for his server; these are relayed in the Defender's advertisement of itself to clients. Private-access servers can be secured with a password.
|Figure 2. Setting up a Defender.|
Just as with the Reflector, the operator can choose to have his Defender make outgoing connections to the public network, in which case it serves as a proxy for connected clients. Alternatively, he can run the Defender as the hub of an isolated client-server network. A key difference between the Defender and the Reflector is that the former is compatible with only BearShare clients, thereby maximizing client-server features, while the latter strives for open interoperability.
To stimulate the use of the client and server modes, the current alpha version defaults users with low-speed connections to client mode and users with high-speed connections to server mode. In other words, a BearShare user might run a Defender without necessarily realizing it. The objective is for there to be a large number of end-user-operated, transient Defenders running at any one time with many incoming connection slots available for BearShare users in client mode.
In November, Clip2 wrote that Gnutella network scalability would be aided by the regular use of Reflectors and adoption of improved connection logic. As I described more recently in Gnutella: Alive, Well, and Changing Fast, the second generation of Gnutella applications implemented connection logic that appears to have positively impacted network performance.
With the third generation of applications, we may see a meaningful number of distributed and transient Reflector-style nodes likewise produce additional positive impact on network performance. Through the self-organized tiering that results from connection logic and the distributed brokerization of Gnutella's originally fully decentralized P2P model, we see how a decentralized system can evolve to accommodate greater load.
Kelly Truelove is an independent research analyst who, via Truelove Research, covers peer-to-peer technology with a focus on P2P content search, storage, and distribution networks. He is regarded as a leading expert on consumer file-sharing systems, which he covers with a data-driven approach.