Figures

Figure Caption
1.1 P2P interpreted as “person-to-person”. Person A in a room full of people wishes to communicate with B. A therefore locates and approaches B and establishes a direct connection.
1.2 Basic p2p connectivity implies each node can connect directly to any other. The number of possible connections increases rapidly with the number of nodes.
1.3 In practical networks, direct p2p connectivity is usually consigned to an abstract routing layer, so that the physical connections (solid arrows) can be made much simpler and tractable.
1.4 Comparing infrastructure, telephony and Internet, with respect to how representational naming is used to address a given end-point.
1.5 Simple comparison of a true peer network (as in early Internet) to a more server-centric model with hierarchical connectivity down to user clients (as in later Internet, especially World Wide Web).
1.6 Comparing the Internet TCP/IP model with the OSI reference model. While data physically flows between the physical layer, higher level layers logically appear to be directly interconnected.
2.1 Simple illustration of how data transfer between Internet routers is accomplished by asynchronous forwarding of individual packets along whatever path each router at that moment deems suitable.
2.2 An atomistic p2p network is constructed from an arbitrary number of nodes. Each typically maintains contact with several others, although virtual direct connectivity can be established between any two.
2.3 Simple illustration of either user-centric or data-centric p2p. Even though clients usually connect using the traditional infrastructure, the user sees a different, peer-oriented namespace with new services unavailable in the underlying physical network.
2.4 Simple illustration of traditional distributed processing. Typically little or no communication occurs between nodes. Data is owned by the central server(s), and tasks sent out to nodes that sent back results.
2.5 Microsoft Networking models the network as three layers and two bindings, here compared to the OSI model. The user must configure one or more appropriate binding paths Client-Protocol-NIC for each application and network used.
3.1 Storage models. In the distributed model, shown at right, one often calls the service-managed store a virtual distributed filesystem.
3.2 File-sharing clients generally have the ability to identify identical files stored at several nodes, and try each in turn until a download connection is established. A host can also be substituted (skipped) in mid transfer for performance reasons.
5.1 In practical networks such as the Internet, physical connectivity between individual nodes is limited to higher-level “hosts” that are in turn connected to high-capacity “backbones” between hosts.
5.2 Principle functionality blocks of the flow control algorithm solution. The aggregate flow control performs a simple receipt check on receiving nodes, prevents overloading, and arbitrates fair connection usage.
5.3 Napster’s server-mediated p2p model. User A connects to the “first available” server assigned by a connection host. The initial user/file list presented is based on the users recently connected to the same server.
5.4 Conceptual difference between traditional TCP-connected nodes and the multiplexed UDP scheme implemented by the Alpine protocol. The addressable broadcast in the latter can provide an unreliable endpoint connection for simple control and query messages.
6.1 Typical indirection in modern Internet-transported e-mail.
6.2 A comparison between IM and IRC chat architectures
6.3 Installing ICQ requires passing a number of registration dialogs first, but eventually you’re online and are welcomed with a first, system message. Shown is the simple, default interface.
6.4 Selecting Advanced Mode (left capture in this composite) provides more functionality up front, and the ICQ button gives a popup (middle capture) with access to Preferences among other things. An icon popup on the taskbar (far right) lets you disable or enable ICQ as a whole.
6.5 Opening Owner Preferences provides access to a plethora of settings, thankfully also details of ICQ behavior and initial activity, along with security, proxy settings, and just plain visual tweaks. This is the Advanced Mode view—Simple Mode has far fewer settings.
6.6 AIM messaging is schematically like IRC, as messages must always be relayed by a message server. Clients have no location information about each other and can’t connect directly p2p, unlike the case in ICQ.
6.7 Jabber architecture is client-server, but the server core is small enough that servers could be embedded on the client machines. Servers form the p2p network and exchange message and presence between connected clients. Servers also host extensible services (transports).
6.8 A typical status page from jabber.org showing up- or down-times for the common transports being tested as they are developed. Note in particular the problem transports aim and recently icq, both to AOL.
6.9 Configuration dialog for WinJab, the popular Windows version of a Jabber client. Different profiles are possible for different purposes.
6.10 Browsing Jabber services in WinJab, all of which are implemented as server components. At bottom left in the roster window pane, icon shortcuts activate common p2p functions for conversations with a selected user: send message, open chat, send URL, and send file.
6.11 Psst is a minimalistic p2p open source client for strongly encrypted IM sessions. Typing a row of gibberish in the console version seeds the key generation for the session, after which you just connect and type.
6.12 Psst 0.2 provides a GUI version. On each session start, random mouse movements provide the seed used for subsequent encryption.
6.13 Trillian is an effective and useful multiprotocol IM client that’s very configurable for the user. Seen in this capture is the main, resizable status interface in its default skin, plus two concurrent session windows; one in ICQ and the other to the same user’s Windows Messenger client.
6.14 Windows Messenger main interface to left, and a session window opened to right. Opening the latter has extended the options available in the interface. The client has a familiar “I want to” help system.
7.1 Napster’s server-mediated p2p model. User A connects to the “first available” server assigned by a connection host. Lists of users and files are based on the users recently connected to the same server.
7.2 Composite from Bearshare Gnutella client illustrating both the way your immediate connections change over time, and the global cross section of nodes that make up a local web of “neighbor” nodes.
7.3 How decrementing TTL (and discarding duplicates) ensures that a relayed message eventually stops spreading through the network.
7.4 Composite from Gnucleus client showing varying network reach as a function of how well each connected node branches to others.
7.5 Summed statistics for client connectivity, where previously analyzed node trees converge. Identifying node numbers are masked in the capture for the purposes of this illustration.
7.6 Example of connection map created from node responses and visualized to depth 4 in Gnucleus using the GraphViz package.
8.1 A rough model of the different architectural layers in Mojo Nation (the Broker). Correspondence with OSI is approximate because the transaction layer uses TCP/IP for Broker interaction over the Internet.
8.2 Calling in a micropayment debt in Mojo Nation initiates a real transfer of a signed Mojo token to normalize credit status.
8.3 Publishing a file in the Mojo Nation network. This schematic is a simplification that shows only major stages.
8.4 Retrieving a file in the Mojo Nation network. This schematic is a simplification that shows only major stages.
8.5 Outgoing and incoming messages seen in terms of the Mojo Nation protocol layers. This is an expansion of the middle layers in the OSI comparison in the previous figure.
8.6 A relay service allows firewalled participation in the Mojo Nation network by caching blocked initiating messages. The shielded Broker initiates periodic connections to fetch stored messages for processing.
8.7 Requesting clients form informal swarms or meshes based on common content. Within each mesh, clients rebroadcast packets to other peers requesting the same information, thus offloading the main server.
8.8 Redundant forward error correction encoding works by allowing recovery of original data as long as a sufficient number of redundancy encoded packets are received and correctly decoded.
9.1 Screenshot from the Freenet Frost client showing a list of files matching a search pattern, based on the built-in index shared among all active Frost clients. Note the hash key for each file, which is the identity needed to retrieve the file from the distributed storage.
9.2 Freenet links to the normal Web are formulated in a special way and invoke this click-through warning page, here seen from a local gateway.
9.3 Composite views from the Freenet Frost client showing both upload and download sessions. Note the hash key for each file, which is the identity needed to retrieve the file from the distributed storage.
9.4 Two ways to access (or publish) content on Freenet. At left, the user runs own trusted node with connections to other Freenet nodes and uses Freenet client software to access own node. The user to the right uses a normal Web browser to access a gateway on a remote machine.
9.5 The Freenet node popup menu from the taskbar icon in Windows.
9.6 The Freenet 0.4 node gateway’s default page accessed with stock Web browser from the installation’s localhost proxy. Note the forms for retrieval requests and browse-insertion of files from the local system.
9.7 Frost implements News Boards, which is an encrypted and anonymized form of newsgroup discussions internal to Freenet. The drop-down shown activated lists the current boards detected.
9.8 FreeWeb client in Windows is for easy management of Freenet-published Web sites. The Site menu shows typical useful commands.
10.1 Groove clients share a virtual workspace between members of a group, where all changes (such as user actions) in any client’s representation are replicated by change messages sent to the other members. This schematic ignores the role of the transparent relay server.
10.2 All Groove connectivity is dependent on the central relay server in one way or another, even if peers normally communicate directly. The fallback for firewalled clients is to pass messages through the relay.
10.3 Tools (applications in the workspace) are handled transparently and downloaded from a trusted source when required by a change.
10.4 A simple graphical interface in myJXTA allows a JXTA peer user to easily access chat, group chat, search, and share functionality.
10.5 Gnougat is an atomistic, Gnutella-like file-caching and file-sharing client for JXTA. Still very much in development, the implementation does showcase a number of interesting network-optimizing features.
A.1 An indication of what kind of communication occurs at particular levels in the OSI model, and some examples of relevant technologies that function at the respective levels. The top four are “message based”.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
13.58.132.97