Report on the Main Project

Submitted in
partial fulfilment of the requirements for the award of the degree of

Bachelor of Technology
in

Computer Science and Engineering

By

Varghese Mathew ( Y2.049 )

and
Varun Tewari ( Y2.263 )

Under the guidance of

Prof. Dr. M.P. Sebastian,

( Head of the Department of Computer Engineering )

Department of Computer Engineering

National Institute of Technology, Calicut
Kerala – 673601
[ 2006 ]
 i

Certificate

This is to certify that this document entitled “TeakForest: An Organically Growing

Peer to Peer Social and Content Sharing Network”, is a bona fide record of the

project work done by “Mr. Varghese Mathew” ( Y2.049 ) and “Mr. Varun Tewari”

( Y2.263 ) in the year 2005-2006, under our supervision and guidance. This report

has been submitted to the Department of Computer Engineering, of the National

Institute of Technology, Calicut, in partial fulfilment of the requirements for the

award of the degree of Bachelor of Technology in Computer Science and

Engineering.

Dr. M.P. Sebastian

Project Guide
Professor and Head
Dept. of Computer Engineering
National Institute of Technology
Calicut
 ii

Abstract

We propose and prototypically implement a peer to peer network model and a

protocol which supports building a hierarchical, organically growing peer to peer
social and content sharing network.

The network imbibes the idea of a distributed social network with an organic growth
pattern. The human "friend" relationship has been transcended to the network as is
the central idea in a social network. Social activity goes on between peers in the
network through the process of message passing and friend associations.
Additionally, content sharing and content querying facilities akin to peer to peer
content sharing networks have been provided.

The network uses an application level addressing scheme and implements source
routing at the application level.
 iii

A dedication to four memorable years spent well..

And to the joys and sorrows shared together..

 iv

Acknowledgements

“There can be miracles, when you believe..” - Whitney Houston

It is said that the greater the effort, the greater the satisfaction.. And at this juncture,
having vibrantly completed our main project, we take a look behind to thank one and
all who have helped us, advised us, guided us, stood by us and given us the motivation
and faith to carry this project onto successful consummation.

First and foremost, we express our profound and heartfelt gratitude to our HOD, and
Project Guide, Prof. Dr. M.P. Sebastian, for his continued support, expert guidance
and limitless encouragement, throughout the course of our project.

We would like to thank all our teachers, for their guidance, prayers, and for all their
big and small helps in seeing our project to conclusion.

We would also like to thank all our friends and associates who have borne many
difficulties for us during the proceedings of our projects so that this project could be
brought to good completion.

We will always be indebted to you all..

Varghese Mathew
and
Varun Tewari
 Table of Contents

Certificate …i
Abstract …ii
Acknowledgements …iv

1. Introduction ...1
1.1. Motivation …1
1.2. Problem Specification …2
2. Network Organisation …3
3. Application Design …5
4. Protocol Specification …6
4.1. The Grammar for the Protocol …6
4.2. Request Messages …6
4.3. Request Types and Associated Responses …7
5. Implementation …14
6. Results …15
7. Conclusion …21
8. Future Outlook …22
8.1. Security Considerations …22
8.2. “file search” and Replica Identification …22

Appendix
References
 List of Figures

2.1. The Network Organisation …3

3.1. The Different Subsystems in the Application …5
6.1. Node Profile … 15
6.2. Friend List of the Remote Node … 16
6.3. Scrap Book of the Remote Node … 17
6.4. File / Content Share List of the Remote Node … 18
6.5. Downloading Content from the Network … 19
6.6. Download in Progress … 20
1. Introduction
Human nature is defined by an incessant urge to improve. This drive has brought us
from the wheel to the jetliners, caves to skyscrapers, and the abacus to computers.
And with each milestone in technology, man adapts himself to be more suited for
work with the novelty. The story has not been much different in the area of
computers. In fact, when it comes to computers, this adaptability of man becomes far
too prominent and pronounced.

Computers have come to change every walk of our lives, be it banking, purchases,
communication, entertainment, news.. everything..

Two concepts in the computer world, as mentioned below, have been the drive and
the anvil of our project.

1.1. Motivation
The concept of social networks has recently seen rapid growth in popularity over the
internet. A social network of man basically is his circle of family, friends and
associates. When transcribed to computers and the Internet, social networking is the
computer aided total solution to a person’s needs for maintaining his social network.

Stemming with SixDegrees.com and gaining popularity with the advent of Friendster,
social networking has been proliferating over the internet. Presently popular social
networking sites include orkut, hi5, myspcae, linkedin [1] etc.

These networks have an associated concept of Organic Growth. Organic Growth has
many connotations, but the gist of these is the idea of growth from within. For e.g.
Organic Growth of a company can be stated as the growth rate of a company,
excluding any growth from takeovers, acquisitions, or mergers [2]. These social
networks grow through forging of new interconnections between nodes.

Another concept that has motivated us is that of peer to peer content sharing networks
[3]. The idea behind these networks is to maximise content availability to its
subscribers. These content sharing networks usually are peer to peer networks which
delegate out / decentralise file-storage to enhance availability by avoiding bottlenecks

Varghese Mathew, Varun Tewari, “TeakForest: An Organically Growing Peer to Peer Social and Content Sharing Network”, Apr 2006 1
due to single server architecture as well as employing peripheral node resources.
Examples of these are Gnutella, BitTorrent, KaZaA [4], Freenet [5] etc.

We saw a synergy in these two concepts which formed our motivation behind this
project.

1.2. Problem Specification

A social network inherently has a potential to grow organically. This organic growth
forms the sustenance of the social network. A file-sharing network attempts to
maximise the content availability. This maximal content availability attracts more
subscribers to the network.

When these two ideas are combined, we see that the organic growth of the social
network results in greater and greater interconnections in the network thereby
enhancing the content availability. Additionally, these connections aid in file
indexing on the network. Likewise, newer avenues of published files drive individual
nodes to make more and more connections on the network. This aids in the organic
growth of a social network. Thus, we see enormous synergy in combining the two
concepts of social networking and content distribution networks.

Our objective is to develop a network which exploits the aforementioned synergy,

viz., an organically growing peer to peer social and content sharing network..

The network essentially should allow a user to maintain a friend-list browse-able by

other users, and a list of shared files available for retrieval by other users. The
network should also allow some form of communication between the users.

These three form the bare minimum requirements for the proposed network. What we
intend to develop is a protocol and a network organisation for realising a robust
organically growing peer to peer social content sharing network. Also part of the
problem is the requirement to build a demonstrative implementation of the above
mentioned protocol / network organisation.

Varghese Mathew, Varun Tewari, “TeakForest: An Organically Growing Peer to Peer Social and Content Sharing Network”, Apr 2006 2
2. Network Organisation
The network is organised as a forest of trees. The root nodes of each of these trees are
nodes which lie directly on the internet / highest-reachable-network whereas the non-
root nodes are the nodes which connect to the internet through other nodes. Each node
in the network is identified by a sequence of nodes starting from the root of the tree
containing the node, to the node itself. The roots of all trees in the forest are further
allowed to be interconnected, thereby providing complete routes between any two
nodes in the network.

Fig 2.1 The Network Organisation

Varghese Mathew, Varun Tewari, “TeakForest: An Organically Growing Peer to Peer Social and Content Sharing Network”, Apr 2006 3
Figure 2.1 depicts the naming convention. The highest level node’s address is its own
name (ABC). Its immediately lower level node gets the address of the parent node
name followed by its name separated by a dot (ABC.DEF) etc.

Now, in this organisation, each non-leaf node acts as a router / gateway between its
children nodes and its parent node. This forms the underlying hierarchical routing
overlay network for our P2P system. Over this, we implement the content sharing
and communication facilities mentioned before.

Routing any packet between any two nodes in the network requires knowledge of the
address of the remote host to which the packet is to be routed. And due to our
particular design of the network, the address of the node itself is the route from the top
level network to the node. Thus the source node has its own address as well as the
remote node'
s address, and the two addresses can be combined, pruning out common
nodes, to give the shortest or optimal path between the source and the destination
nodes. This can be easily implemented at the source node with the help of source
routing.

Varghese Mathew, Varun Tewari, “TeakForest: An Organically Growing Peer to Peer Social and Content Sharing Network”, Apr 2006 4
3. Application Design
The application structure of the deployment may be subcategorised into three:
• a routing subsystem
• a node daemon subsystem / back end
• a network browsing subsystem / front end

The routing subsystem is deployed on the non-leaf peers and caters to collecting the
packets from the previous hop and forwarding them to the next hop as specified in the
route information in the packet.

The node daemon subsystem listens for peer requests from other peers and caters to
them. It is this subsystem which responds to all actions / communications from a
remote peer.

The network browsing subsystem provides a facility to browse, download content,

communicate and make friends on the network. It basically forms the front end for
the implementation.

Fig 3.1 The Different subsystems in the application

Varghese Mathew, Varun Tewari, “TeakForest: An Organically Growing Peer to Peer Social and Content Sharing Network”, Apr 2006 5
4. Protocol Specification
The first version of the protocol we have developed for this Peer to Peer network is
specified in this section of the document. Section 4.1 gives the grammar for the
protocol. The remaining sections discuss the different request messages and their
associated responses.

4.1. The Grammar for the Protocol

The Protocol grammar is as defined below

<Message> := <Request> | <Response>

<Request> := MAGIC '\n' <F-V-Pairs> '\r' <Data>

<F-V-Pairs> := nil | <F-V> '\n' <F-V-Pairs>
<F-V> := <Field> ':' ' ' <Value>

<Response> := <Response-Code> '\n' <Explanation>

'\n' <F-V-Pairs> '\r' <Data>

MAGIC := "TeakForest"
<Data> is specific to the request/response message

4.2. Request Messages

There are five “Field”s specified for request messages
Version
Request-Type
Hop-List
This-Hop
Data-Length

4.2.1. Version
The current version we have developed has been released as version ‘1’ and
thus ‘1’ is the only value supported for this field presently.

Varghese Mathew, Varun Tewari, “TeakForest: An Organically Growing Peer to Peer Social and Content Sharing Network”, Apr 2006 6
4.2.2. Hop-List
The hop list is a '
.'separated list of node names including the source and
destination nodes and forming the path between the source and destination
nodes. This field along with the This-Hop field are used for routing in the
network.
4.2.3. This-Hop
The value of this field is an integer representing the index of the current node
in the Hop-List. ‘0’ specifies the source node.
4.2.4. Data-Length
The value of this field gives the length of data in the <Data> section of the
request message
4.2.5. Request-Type
The Request-Type field specifies what specific query is made of the
destination node by the source node. The various possible values for this field
are explained in the next section ( 4.3 )

4.3. Request-Types and associated responses

The current implementation supports the following request types. Each request
entails a response from the remote node, and these response codes have been
discussed here along with the requests. The reader may please note that a response
code of ‘0’ always means success.

“reg request” “profile friend list”

“sess init” “profile friend count”
“ping” “profile scrapbook”
“am i up” “file get”
“profile photo” “file getbytes”
“profile data” “message scrap”

4.3.1. “reg request”

This stands for registration request. This is the request message using which a
node attempts to register itself under a node one step higher in the tree
structure mentioned in Section 2. When the request is a "reg request", there
can be only two hops, the source and the destination, in the Hop-List.

Varghese Mathew, Varun Tewari, “TeakForest: An Organically Growing Peer to Peer Social and Content Sharing Network”, Apr 2006 7
 In this case, the “ Data” field of the request message is as follows
<Data> := (<F-V> '\n'){2} '\r'
The two F-V values are:
"Node-Name: <user_suggested_node_name>"
"Node-Pass: <password>"
The Response-Codes possible with this Request message type are
0 - Registration Successful
This response also contains the Field-Value-Pair
"My-Path: <parent'
s path/address>\n"
8 - Invalid Reg Info
3 - Node Name Already Registered
13 - You Are My Parent / Parent attempting to register with child

4.3.2. "sess init"

This stands for session initiation. This is the request message used by the
lower node in the hierarchy to inform its parent that it is up and running.
Again, like "reg request", there can only be two hops in the Hop-List for this
request.
The “Data” field of the request message, in this case, is
<Data> := (<F-V>){3|4} '\r'
The F-V values are
"Node-Name: <node_name_registered>"
"Node-Pass: <corresponding-password>"
"Node-Port: <listening-port-on-the-node>"
"Node-Address-Type: <only value presently defined is '
TCP/IP'
>"
of these, the Node-Address-Type may be deprecated in subsequent
releases of the protocol
The Response-Codes possible with this request message type are
0 - Session Initiation Successful
0 - Session Already Initiated
These two responses also contain the Field-Value-Pair
"My-Path: <parent'
s path/address>\n"
11 - Invalid Sess Info
10 - Sess Init Failed / Username - passwd mismatch

Varghese Mathew, Varun Tewari, “ TeakForest: An Organically Growing Peer to Peer Social and Content Sharing Network” , Apr 2006 8
 12 - You Are My Parent / Parent attempting to initiate session

4.3.3. "ping"
This is analogous to the concept of ping in any other protocol. It is used by one
node to determine if another node is up and running at the present moment.
In this case "Data" is empty
The Response-Codes possible with this request message type
Technically only a success response can be the direct response to this
message
0 - I'
m Alive
Error responses are generated as a result of failed rerouting attempts
and will therefore be discussed along with rerouting.

4.3.4. "am i up"

This request message is used by a lower level node to query its parent to see if
its session is still in the initiated state.
The "Data" Field is empty in this case
The Response-Codes possible in this case are
0 - Yes, You are !!
14 - Am I Up allowed only with parent / node attempting am i up with
a node other than its parent
15 - No, You are Not :(

4.3.5. "profile photo"

This request message is used by a node to request a remote node for an
image/photo identifying/representing the remote node.
The "Data" field in this case too is empty
The Response-Codes possible in this case are
0 - Success / Here it comes
In this case the response contains two Field-Value-Pairs followed by
the byte stream of the image file; these Field-Value-Pairs are
"Photo-Ext: <.jpg/.bmp/etc.>"
"Photo-File-Size: <filesize>"
18 - No Photo
Varghese Mathew, Varun Tewari, “ TeakForest: An Organically Growing Peer to Peer Social and Content Sharing Network” , Apr 2006 9
4.3.6. "profile data"
This request message is used by a node to request textual data about a remote
node.
The "Data" field in this case too is empty
The Response-Codes possible in this case are
0 - Success / Here it comes
In this case the response contains a Field-Value-Pair followed by the
byte stream of textual data; this Field-Value-Pair is
"Data-File-Size: <filesize>"
19 - No Profile Data

4.3.7. "profile friend list"

This request message is used by a node to retrieve the friend list of a remote
node.
The "Data" field of the request message in this case too is empty
The Response-Codes possible in this case are
0 - Success / Here comes the friend list
In this case the response contains two Field-Value-Pairs followed by
the friend list with the friend list formatted by using '
\n'as the separator
character; these Field-Value-Pairs are
"Friend-Count: <number of friends>"
"Data-Length: <length of data area of response>"

4.3.8. "profile friend count"

This message finds use when it is needed to enumerate the number of friends a
node has without actually retrieving the friendlist.
The “ Data” field of the request message in this case too is empty
The Response-Codes possible in this case are
0 - Success
In this case the response contains one Field-Value-Pair
"Friend-Count: <number of friends>"

Varghese Mathew, Varun Tewari, “ TeakForest: An Organically Growing Peer to Peer Social and Content Sharing Network” , Apr 2006 10
4.3.9. "profile scrapbook"
This request message is used by a node to retrieve the scraps from a remote
node. There are two ways of operating this request message. In the first
method, a scrapID is specified, in which case that scrap contents is returned by
the remote node. In the second method, no scrapID is specified, in which case
the remote node just returns the number of scraps.
The scrap id is specified using an optional Field-Value-Pair in the Data section
of the request message
"Scrap-Requested: <scrap id>"
The "Data" field in this case is terminated by '
\n\r'
The Response-Codes possible in this case are
0 - Success [ case of method 2 above ]
"Scrap-Count: <no of scraps>"
0 - Success [ case of method 1 above ]
"Data-Length: length of scrap object", followed by byte stream
containing the scrap object
22 - Invalid Scrap ID

4.3.10. “file get"

This request is used to get directory listings or file statistics of the file
specified. In this case the "Data" field contains a Field-Value-Pair containing
the pathname of the file/directory requested
"File-Name: <filename>"
The Response-Codes possible in this case are
0 - Success
In this case the response will have two Field-Value-Pairs
"File-Type: <file|dir>"
"Data-Length: <length of data area of response>"
if the File-Type is “ dir” , then the Data area contains the list of entries
in the directory
if the File-Type is “ file” , the Data area contains a Field-Value-Pair
"File-Size: <size of file requested>"
20 - No file name parsed
21 - File not found
Varghese Mathew, Varun Tewari, “ TeakForest: An Organically Growing Peer to Peer Social and Content Sharing Network” , Apr 2006 11
4.3.11. "file getbytes"
This request is used in the case where the target in the previous request was
identified as a file. In this case, this request retrieves the bytes between a
specified start offset and a specified stop offset. The start offset and stop offset
may be omitted in which case they default to the starting and ending of the
file.
The "Data" field of the request contains three Field-Value-Pairs
"File-Name: <file name>"
"Start-Offset: <starting byte>"
"Stop-Offset: <ending bytes>"
The Response-Codes possible in this case are
0 - Success / Here comes the bytes
In this case, the "Data" area of the response contains the bytes
requested for.
24 - Invalid offsets
23 - The file is a directory
20 - No file name parsed
21 - File Not found

4.3.12. "message scrap”

This request type is used by a node to send a scrap message to the remote host.
In this case, the "Data" area contains a scrap object
The structure of the scrap object has Three Field-Value-Pairs
"Scrap-Time: <time>"
"Scrap-Author: <set to scrap author'
s path>"
"Scrap-Message: <contents of the scrap>"
The Response-Codes possible in this case are
0 - Success
25 - Error parsing the scrap

Varghese Mathew, Varun Tewari, “ TeakForest: An Organically Growing Peer to Peer Social and Content Sharing Network” , Apr 2006 12
4.3.13. Routing
In the case that the hop list specified in the request message contains more
nodes after the current hop, it means the system has to forward the request
message to the next hop. In this case, the routing subsystem looks up its list of
nodes that have initiated sessions with it, and its parent and sees if any of these
is the next hop specified. If that is the case, the routing subsystem opens a
connection with the next hop, forwards the request to that hop, then receives
the response from the next hop and passes it back to the previous node.
The possible errors arising in this phase and the associated Response-
Codes are enumerated below
7 - Node Unavailable / Session not initiated
16 - No Such Node Registered
17 - Connection Failed

4.3.14. Other general Response-Codes

1 - Invalid header / Magic not found
2 - Un-Supported Version
4 - Header too long (might be deprecated in subsequent releases)
5 - Header Parse Error
6 - Unsupported Request

Varghese Mathew, Varun Tewari, “ TeakForest: An Organically Growing Peer to Peer Social and Content Sharing Network” , Apr 2006 13
5. Implementation
The proposed peer to peer network was successfully implemented using the Python
programming language [6] [7]. The implementation was done in a multithreaded
manner to enhance availability and performance and reduce response time. The same
was subsequently tested out on the hostel network of NITC.
At this point, we take a detour to explain how the front end has been implemented,
albeit the fact that the front end / user interface does not exactly come under the
purview of the network / protocol.
Our particular implementation uses HTTP [3] [8] [9] to enable a web browser
interface to our backend. We run an HTTP server on the “localhost” to listen to a
specified port. The end user connects to this server as http://localhost:<port> and
then issues URLs of the form:
http://localhost:<port>/request=<request>&path=<path>&file=<file>
where
<port> : is the port on which the server listens
<path> : is the address/path of the remote node consisting of hops from
the root downwards
<file> : this field is used only for requests which specify a file, under
other cases, its value is ignored
<request> : is the field by which the user specifies what action to perform
on the remote node
The <request> field can have the following options.
profile : tells the server to fetch the remote user’s profile
scrapbook : tells the server to fetch the remote user’s scrapbook
friendlist : tells the browser to fetch the remote user’s friendlist
fileget : tells the server to fetch a remote file / list a remote directory
addfriend : tells the server to add the remote user to this node’s friendlist
photo : tells the server to fetch the remote user’s profile photo
scrap : tells the server to send the contents coming as POST-data as a
scrap to the remote user
Once the user connects to the server, the pages returned by the server contain
links/URLs in the above format so that all further browsing can happen at the click of
the mouse, just as we have it with the world-wide-web

Varghese Mathew, Varun Tewari, “TeakForest: An Organically Growing Peer to Peer Social and Content Sharing Network”, Apr 2006 14
6. Results
Here we present as results, some of the screen-shots of pages generated by the
network browsing subsystem.

Fig 6.1 Node Profile

Varghese Mathew, Varun Tewari, “TeakForest: An Organically Growing Peer to Peer Social and Content Sharing Network”, Apr 2006 15
 Fig 6.2 Friend List of the remote node

Varghese Mathew, Varun Tewari, “TeakForest: An Organically Growing Peer to Peer Social and Content Sharing Network”, Apr 2006 16
 Fig 6.3 Scrap Book of the remote node

Varghese Mathew, Varun Tewari, “TeakForest: An Organically Growing Peer to Peer Social and Content Sharing Network”, Apr 2006 17
 Fig 6.4 File/Content share list of remote node

Varghese Mathew, Varun Tewari, “TeakForest: An Organically Growing Peer to Peer Social and Content Sharing Network”, Apr 2006 18
 Fig 6.5 Downloading Content from the network

Varghese Mathew, Varun Tewari, “TeakForest: An Organically Growing Peer to Peer Social and Content Sharing Network”, Apr 2006 19
 Fig 6.6 Download in progress

Varghese Mathew, Varun Tewari, “TeakForest: An Organically Growing Peer to Peer Social and Content Sharing Network”, Apr 2006 20
7. Conclusion
The objective behind this project is to develop a peer to peer network protocol and
organisation which exploits the synergy between the ideas of social networking and
Peer to Peer content sharing networks.

We have been able to develop a protocol and an organisation which achieves the
objective. The deployment of the prototype application has corroborated with
anticipated results and has successfully conjoined the two ideas together. The organic
growth of the social network aids the content sharing aspect by enhancing file
availability, and the rewards in terms of enhanced availability promotes further
growth of the network.

Varghese Mathew, Varun Tewari, “TeakForest: An Organically Growing Peer to Peer Social and Content Sharing Network”, Apr 2006 21
8. Future Outlook
What is presented in this document is a first version of the P2P protocol and its allied
network organisation. Even though we have been successful at exploiting the
potential synergy in the concepts of social networking and content sharing networks,
we are only at the beginning of a long journey.

The following aspects have been identified as potential future enhancements possible
to the proposed protocol.

8.1. Security Considerations

The node registration and session initiation phases involve the transmission of a node
password to the node’s parent. Therefore these phases will benefit by the use of a
secure communication scheme like “Secure Sockets Layer (SSL)” [10] [11].

8.2. “file search” and Replica Identification

As of this writing, the protocol “file get” request message returns with the size of the
file. This can be augmented to return the MD5 checksum [12] for the file too, and
then a new “file search” request type may be introduced, which sends out this check-
sum and file size to the parent node on the routing overlay. The parent node in turn
propagates the request to its parent and all of its children until a specified depth ‘n’.
All nodes which share files of same size and matching checksum can then respond
with the respective file names.

This search process may be carried out in an iteratively deepening manner. The
requesting node can then retrieve the file as splits simultaneously from many peers,
based on some peer performance metrics as well as number of hops separating the
requesting node and the publishing peer.

This enhances the response time for file get requests as well as localises traffic on the
P2P network.

Varghese Mathew, Varun Tewari, “TeakForest: An Organically Growing Peer to Peer Social and Content Sharing Network”, Apr 2006 22
 Appendix
An Aside on Terminology
1. Organic Growth: Growth of an entity (including abstract entities) by itself / on
its own.
2. Friend: A node which has formed an association with the node in question.
3. Users: People who work on the specified node. For our purposes, users may be
used synonymously with nodes / peers.
4. Nodes / Peers: Any one of the computers / hosts participating in the network.
5. Parent Node / Parent: A node which is on the immediately higher level of
hierarchy of the node in question and forms the node’s portal to the higher level
networks
6. Child Node / Child: A node which is on the immediately lower level of the
hierarchy of the node in question and which is registered with the node in
question.
7. Source Routing: Routing methodology where the source provides all information
required for routing along with the packet / message itself.
 References
[1] Wikipedia page on social networks: http://en.wikipedia.org/wiki/Social_network
[2] http://www.investopedia.com/terms/o/organicgrowth.asp
[3] James F. Kurose, Keith W. Ross, Computer Networking: A Top-Down Approach
Featuring the Internet, Pearson Education Asia, 2/e, 2005
[4] Jian Liang, Rakesh Kumar, Keith W. Ross, “Understanding KaZaA,”
Polytechnic University, Brooklyn
[5] I. Clarke, O. Snadberg, B. Wiley, T. W. Hong, “Freenet: A Distributed
Anonymous Information Storage and Retrieval System,” University of Texas at
Austin, Imperial College of Science, Technology and Medicine, London
[6] Swaroop C.H., A Byte of Python, electronic volume,
http://www.byteofpython.info
[7] Wesley J. Chun, Core Python Programming, Pearson Education Asia, 2001
[8] RFC 1945: Hypertext Transfer Protocol -- HTTP/1.0. T. Berners-Lee, R.
Fielding, H. Frystyk. May 1996.
[9] RFC 2616 Hypertext Transfer Protocol -- HTTP/1.1. R. Fielding, J. Gettys,
J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee. June 1999.
[10] SSL 2.0 Protocol Specification:
http://www.netscape.com/eng/security/SSL_2.html
[11] SSL 3.0 Protocol Specification
http://www.netscape.com/eng/ssl3/3-SPEC.HTM
[12] RFC 1321 The MD5 Message-Digest Algorithm. R. Rivest. April 1992.