\documentclass{article}

\setlength{\textwidth}{6.0in}

\setlength{\textheight}{9.0in}

\setlength{\headheight}{0.0in}

\setlength{\headsep}{0.0in}

\setlength{\parskip}{1.5ex plus 0.5ex minus 0.5ex}

\setlength{\topmargin}{0.5in}

\setlength{\topskip}{0.0in}

\setlength{\evensidemargin}{0.5in}

\setlength{\oddsidemargin}{0.5in}

\newcounter{exercise}

\newcounter{problem}

\newcounter{step}[problem]

\newcounter{subproblem}[problem]

\newcommand {\exercise}[1]{\bigskip\noindent{\large\bf Exercise \stepcounter{exercise} \arabic{exercise}: {#1}}}

\newcommand {\problem}[1]{\bigskip\noindent{\large\bf Problem \stepcounter{problem} \arabic{problem}: {#1}}}

\newcommand {\step}{\par\noindent{\bf Step \stepcounter{step} \arabic{step}: }}

\newcommand {\heading}[1]{\bigskip\par\noindent{\bf #1 }\par}

\usepackage[dvips]{graphics,color}

\begin{document}

\begin{center}

\LARGE

Object-Oriented Programming in Java

\end{center}

\bigskip

{\noindent\Large\bf Problem Set 3 \hfill Due: Jan 17, 2001}

\hrule

\bigskip

\noindent{\Large\bf Group Project: Gnutella}

\bigskip

Gnutella is a peer-to-peer networked file sharing program.

Its functionality is

similar to that of Napster from the user's point of view, except that it

is not specific to audio files, and the index and search capabilities

are not centralized as in Napster, but distributed among all the Gnutella

nodes.

Each Gnutella program is both a client that can initiate searches and download

files, and a server that can upload local files and perform searches

on behalf of clients. The term {\it servent} is often used to

describe this sort of client-server combination (Note

that this is different from {\tt servant} in both spelling and connotation).

Each Gnutella servent running on an individual machine is connected via

the network to some small set of other servents (also called nodes to

emphasize their being part of a network graph). This interconnected

set of servents is the Gnutella network. The nodes of the network work

together to operate as one large search engine.

The properties that make Gnutella an suitable project for this class are:

\begin{itemize}

\setlength{\parskip}{0pt}

\item Functional requirements that demand network, stream IO, GUI,

and multi-threaded programming techniques,

\item Sufficient complexity for a challenging short-term group project,

without being overwhelming,

\item An operational network architecture,

\item A published and well-defined protocol specification to implement,

\item A collection of reference clients to test against,

\item A number of Web sites devoted to it provided documentation and

reference implementations, and

\item An active network to connect to once the project is complete.

\end{itemize}

\heading{Gnutella Servent Operation}

When the Gnutella servent is started, it is configured with a directory

on the users machine containing files to share, a directory

to store downloaded files, and the IP address

of a Gnutella node to initially connect to.

Once the servent program is connected, the

user can initiate keyword-based searches. The servent forwards

search requests onto the network and displays results as they filter back.

Unlike a centralized search engine like Google, a Gnutella node checks an

incoming query against the files it is sharing and then forwards the

query to the other nodes it is directly connected to.

Also unlike Google, search is based only on file name, not content.

When a search is successful, the user

can request to download any of the files matching the search. This causes

the Gnutella servent to directly connect to the node sharing that

file and request a download. If the request is successful, it downloads the

file, displaying the progress of the download as it proceeds.

While it is operating, the Gnutella servent is also functioning as a server:

matching query requests against the files it is sharing, uploading requested

files to remote nodes, and forwarding search requests through the network.

\heading{The Gnutella Network}

The nodes in the Gnutella network communicate via the Gnutella protocol,

which defines the behavior of a Gnutella servent.

Because the Gnutella servents are connected via this protocol, the individual

servent programs do not have to be the same. Any program that implements

the Gnutella protocol can be a legitimate node in the Gnutella network.

In fact there are several servents that are available on the Internet,

including several for Windows and two written in Java.

The Gnutella network is actively used on the Internet and there are several

thousand nodes active at any given time. The distributed nature of the

Gnutella network and its search algorithms make it an interesting

study in network architecture. It has shown some interesting effects

as the network has scaled in size. The architectural issues,

however interesting, are beyond the scope of this class

(there are several papers on the Web discussing these issues

if you are interested).

\heading{Resources}

A copy of the Gnutella protocol specification is available on our

Web site. (Note: This PDF is apparently only viewable from acroread.)

The master site for information on Gnutella is

{\tt http://gnutella.wego.com/}. This site lists pointers to other sites

with additional information and/or clients. A Web search on "Gnutella"

will turn up more information. Use the Web and the attached protocol

document as your main sources of information for this project.

The staff will set up a number of Gnutella servents downloaded from the

Web on the TA machines. These servents can be used to test against as well

as for UI inspiration.

\heading{Servent Functionality}

The functionality we expect you to support includes:

\begin{itemize}

\setlength{\parskip}{0pt}

\item Full implementation of the network protocol as both a client and server,

sufficient to be a functioning node in the Gnutella network.

\item Maintenance of user configuration information, such as node to connect

to on startup, directory to share for upload and share, directory in which

to download files. This configuration should be kept in a file and be

persistent between program executions.

\item The ability to connect to a set of nodes on startup.

\item A GUI that allows the user to change the configuration info, connect to

a node, initiate

a search, display the results of a search (a list of files with associated

node data), download a file from a search result, and monitor who is uploading

what from this node.

\item A certain amount of security on the file sharing. In particular, that

the servent does not permit access to files outside of the upload directory.

(Be careful of paths such as {\tt ../../yourfile} which will allow

outside access if you are not careful).

\end{itemize}

\heading{Plan}

This is a major implementation effort involving several people. It is

an exercise is group organization and project management (without an actual

manager!) as well as a programming challenge. We highly recommend following

these steps.

\step

Take a deep breath, stop, and think.

\step

Read the protocol spec thoroughly. Read any documentation available on the

Internet, and check out the reference clients.

\step

In your groups, develop your design from the top down. Decide first on

what the major modules or sub-systems are and how they communicate. Define

the interfaces between them and what data is shared. Document these decisions.

\step

Decide how the project is to be divided among the group members. It could be

one sub-system per person, or multiple people working together on a single

piece (the proponents of Extreme Programming believe in pair programming; two

people working together on the same code, one typing and one watching,

to check each other's errors and design decisions).

\step

Decide on how the group is going to coordinate and share files, data,

and testing.

\step

Come up with a plan for testing each sub-system independently and a plan for

testing the entire program.

\step

Each sub-group should then design their sub-system, again top down.

Following the steps from PS2, define the major classes and interfaces,

and the methods by which they interact. The design the data representations

and any utility classes and methods. Document these decisions. You should have

substantial Javadoc written and working before actually implementing

any methods.

\step

Finally, start implementing bottom-up, testing each new set of methods

and each new functionality as it get developed.

Consider an implementation strategy that would allow partial sub-system

testing and early testing of the integration of these into the

overall program in order to validate your design.

\step

Complete sub-system testing and combine into the complete program.

\step

Test the program. Connect with other nodes in ADU and search for interesting

files to download. Host some files on your machine (keep it legal, please)

for others to upload.

\step

Once you have verified your program against the reference client (and those

of other groups), try to connect to the Gnutella network outside of ADU.

\bigskip

Good Luck

\end{document}