Download power-point slides

P2P File-Sharing Solution
CS654 – Software Architecture course project
Guide: T V Prabhakar
Members:
S Pavan Kumar – Y1306
D V Janardhan Rao – Y4111053
1
Contents
Functional Requirements
Non Functional Requirements
Brief description of the solution
How we arrived at the solution
2
Functional Requirements
User should be able to



Share files
Search for files based on keywords
Download files
Online Relay Chat
3
Non-Functional Requirements
Fast resource discovery
Availability – If a resource is shared by
some user, then a search query for that
resource should always succeed
Scalability of the solution
Solution should be fault tolerant
Implicit Security in terms of the extent
of damage in case of compromise
4
Module View
P2P File
Sharing s/w
Controller
Search
Engine
File
Mapper
Metadata
Handler
Peer Network
Adapter
UI
Online Relay
Chat Engine
Network
Modules
Centralized
Structured
Web Adapter
Download and
Upload Manager
Decentralized
Structured
5
Hard disk
Allocation View
Controller
Web browser
Java
Servlets
And
JSP’s
Web Adapter
Meta data
files
Peer network
Adapter
P2P
network
XML database
Centralized Index server
( Application server
)
6
Controller
Metadata
handler
Web browser
Search
engine
Meta data
files
File
mapper
Hard disk of the machine
Create
and
upload
Create
JSP
Create
servlet
Upload
servlet
Application Server
Web
Stub
A
D
A
P
T
E
R
Upload
manager
Download
manager
Chat
engine
N
E
T
W
O
R
K
M
O
D
U
L
E
Peer network Adapter
7
Controller
Metadata
handler
Web browser
Search
engine
Meta data
files
File
mapper
Hard disk of the machine
Local
Browsing
View JSP
View servlet
Display JSP
Application Server
Web
Stub
A
D
A
P
T
E
R
Upload
manager
Download
manager
Chat
engine
N
E
T
W
O
R
K
M
O
D
U
L
E
Peer network Adapter
8
Search
and
Download
Controller
Metadata
handler
Web browser
Search
engine
Meta data
files
File
mapper
Hard disk of the machine
Search.jsp
Search
servlet
Display
Results.jsp
Download.
jsp
Application Server
Web
Stub
A
D
A
P
T
E
R
Upload
manager
Download
manager
Chat
engine
N
E
T
W
O
R
K
M
O
D
U
L
E
Peer network Adapter
9
Controller
Metadata
handler
Web browser
Search
engine
Meta data
files
File
mapper
Hard disk of the machine
Chat
Relay
post.jsp
Sendmsg
servlet
Display
.jsp
Recvmsg
servlet
Application Server
Web
Stub
A
D
A
P
T
E
R
Upload
manager
Download
manager
Chat
engine
N
E
T
W
O
R
K
M
O
D
U
L
E
Peer network Adapter
10
Controller
Metadata
handler
Web browser
Search
engine
Meta data
files
File
mapper
Hard disk of the machine
Application Server
Web
Stub
A
D
A
P
T
E
R
Upload
manager
Download
manager
Chat
engine
N
E
T
W
O
R
K
M
O
D
U
L
E
Peer network Adapter
11
Switching between the network
modules
Centralized Index
server
Networking Module
Structured
Centralized
network
module
Structured
Decentralized
network
module
Routing
table info
1
Echo req
Echo reply
4
2
Echo req
P2P
Networ
k
Switching of
Network module
Echo reply
3
XML database
12
Architecting the solution
Architectural decision at the top level and the
tradeoffs – structured or unstructured
network
13
Unstructured Networks

Hard
disk
Metadata
Handler and
File Handler
Ad-hoc topology
Queries are flooded for
bounded number of hops
No guarantees on queries
Probs:

Metadata
Files
User
Interface
Peer
Network
Adapter
Fast Resource discovery
Availability
P2P
Networ
k
xyz
xyz
Query: “xyz”
14
Structured networks
(centralized)
Centralized index servers
O(1) hops for resource discovery
Guarantees on queries – availability
Probs: Scalability, Fault tolerance
and implicit security
Hard
disk
File Handler
User
Interface
Peer
Network
Adapter
P2P
Networ
k
Query
Response
XML database
Centralized Index serve
( Application 15
server )
Structured Networks (decentralized)
Distributed Hash Tables (DHTs)
Hash table interface: put(key,item), get(key)
O(log n) hops – some what problematic; not so fast
Guarantees on search queries, fault tolerant, scalable
K I
(K1,I1)
K I
K I
K I
K I
I1
K I
K I
put(K1,I1)
K I
get (K1)
K I
16
Tradeoff
Structured
Structured
(decentralized)
(centralized)
Fault Tolerance,
Scalability and
Implicit security
Fast Resource
discovery and
availability
So why not use a combination of both
17
Switching between the network
modules (Polling)
Centralized Index
server
Networking Module
Structured
Centralized
network
module
Structured
Decentralized
network
module
Routing
table info
1
Echo req
Echo reply
4
2
Echo req
P2P
Networ
k
Switching of
Network module
Echo reply
3
XML database
18
Architectural Decisions
Why are we switching between various
network modules and not using a single
centralized index server or a totally
decentralized structured network? – fast
resource discovery, scalability, load
balancing, fault tolerance and security
Why are we not using multiple central
index servers? – consistency and cost
19
Storage of metadata
At central index server use XML Database –
heavy loads, faster processing (indexing
becomes important because of huge number
of metadata files), dynamism (index files are
updated every now and then)
For local meta data files use flat file system –
very few files, light loads, number of updates
are small
20
Decisions
Technology – use JSP’s and Servlets for
UI (easy build, modify and run)
Web Server – Open source and free
Decouple functionality from networking
to ensure smooth fault detection and
recovery
21
Hard disk
Architecture
Controller
Web browser
Java
Servlets
And
JSP’s
Web Adapter
Meta data
files
Peer network
Adapter
P2P
network
XML database
Centralized Index server
( Application server
)
22
Quality attributes and tactics
Modifiability

Use an intermediary – Use of a web
adapter removes tight coupling between
the modules
23
Quality attributes and tactics …
Availability

Fault detection
 Ping/echo

Recovery
 Active redundancy
 Switching between the network modules
Security
24
Questions?
25