Store and Forward

“Store and Forward” peer-to-peer systems are those that act as both client and server for communication between peers over the Internet. If discussion is limited to

applications that exist on the Internet, and not spiral recursively back to the Internet itself and to UUCP9 _{before that, two popular early core applications of the Internet}

were very peer-to-peer in their nature without actually being remarked as such explicitly (certainly at the time anyway). One is NNTP and the other is SMTP and both are discussed here.

3.1.2.1 NNTP

The NNTP is the protocol used by the USENET which is one of the first widely used distributed systems that has been lately generally accepted as an early example of P2P. The USENET, conceived in 1979, is a public message system that allows users to post and read messages under a variety of different categories. Each USENET server is a peer on the USENET network and messages posted to a peer are shared or replicated around to all of the other accepting peers on the network. In modern USENET each peer speaks a protocol called NNTP which allows a message to be uploaded in one place and then quickly propagated over the entire USENET network. It is to be noted that while the system and network itself is very P2P, the access of it

9 Unix to Unix Copy Program (UUCP) was an early application that allowed for commands to be run remotely and for files to be transferred between computers. It is a classic example of a store and forward architecture. See RFC976 (Horton 1986).

is not. At the fringes of the network users interact with the USENET server using a separate client application in a very client/server (read: non P2P) manner. This can also be compared with electronic mail.

3.1.2.2 SMTP

Email, at its core, is a group of servers quite similar to USENET which forward email messages between servers with client applications being involved only at the fringes. The Simple Mail Transfer Protocol (SMTP) is the enabling technology. Each email server acts as both a server and a client to all of the other email servers on the Internet, accepting email messages and forwarding them along to the next closest server to the addressee.

See RFC821 (Postel 1982) and RFC5321 for the original SMTP and Extended SMTP (Klensin 2008) respectively for an exhaustive definition of these protocols.

3.1.3 Centralised

Some peer-to-peer systems are only partly peer-to-peer, that is they contain a significant centralised component without which they could not operate at all. The most classic example of this is Napster.

3.1.3.1 Napster

Napster was an infamous file sharing application that was first released in mid 1999. It allowed users to host their files, search for files hosted by other users and

subsequently trade files between each other. The Napster network was predominately used for sharing MP310 _files.

Napster's design was not very decentralised from a P2P perspective. The file transfer is between peers, however the searches are submitted to central servers. This provided a simple solution to the problems of distributed search (by avoiding it altogether) but created a single point of failure. When this central index was shut down, as it was in July 2001, it rendered the system inoperable.

3.1.4 Decentralised

Decentralised peer-to-peer systems are those that try to avoid all centralised elements as much as possible. Gnutella is the most obvious example of a decentralised peer-to- peer network.

3.1.4.1 Gnutella

The second generation of P2P file sharing networks evolved as a response to the weakness of the centralised elements of Napster. The natural focus was to remove the central search servers that made Napster vulnerable. Gnutella was the first such example.

Gnutella is a protocol for distributed file sharing and search. The file exchanges work much the same as Napster, with peers exchanging files between

10 MPEG-1 Audio Layer 3 is a common audio file format that employs lossy compression techniques to reduce the size of recorded audio at the cost of removing very high and very low frequencies that typically cannot be heard by humans.

each other, however the search functionality is decentralised. Early versions of Gnutella worked by having searches propagate across the network. Nodes submit searches (usually just a search term string) and then pass this search packet on to all of the other nodes that they are connected to. This flooding approach allows nodes to see all of the search packets that come their way and notify the originating node (search packets also contain address information) if a match occurs. The approach, whilst very hard to “kill”, has several other obvious design limitations. The flooding approach to search does not scale very well and the open nature of search term propagation is open to malfeasance. Enormous amounts of bandwidth can be generated across the network as nodes forward one packet to every connected node and then they forward it to every node they are connected to and so on (Ritter 2001). 3.1.4.2 Server Message Block

Another ubiquitous protocol is the Server Message Block (SMB) protocol which is more commonly regarded as the network protocol used by Microsoft Windows for peer networking or “Workgroups” between machines. Each machine that is

registered on the network acts as a peer to all others. File can be requested or served from each machine. Its management is decentralised as each machine can largely choose what is to be shared and what is not. This contrasts with many other file protocols, which are strictly client server such as the File Transfer Protocol (FTP).

SMB was originally developed at IBM and widely implemented by Microsoft and is very much in common use. The Microsoft implementation has been

subsequently reverse engineered by the SAMBA team making it widely available and interoperable with other platforms (Ts et al 2003).