1 P2P File-Sharing Solution CS654 – Software Architecture course project Guide: T V Prabhakar Members: S Pavan Kumar – Y1306 D V Janardhan Rao – Y

2 Contents Functional Requirements Non Functional Requirements Brief description of the solution How we arrived at the solution

3 Functional Requirements User should be able to Share files Search for files based on keywords Download files Online Relay Chat

4 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

5 Module View P2P File Sharing s/w Peer Network Adapter Web AdapterUIController Search Engine Online Relay Chat Engine Decentralized Structured File Mapper Centralized Structured Network Modules Metadata Handler Download and Upload Manager

6 Allocation View Web browser Java Servlets And JSP’s Controller Web Adapter Peer network Adapter Hard disk Meta data files P2P network P2P network Centralized Index server ( Application server ) XML database

7 Web browser Web A D A P T E R Application Server Search engine File mapper Metadata handler Hard disk of the machine NETWORKMODULENETWORKMODULE Peer network Adapter Stub Upload manager Download manager Chat engine Controller Create JSP Upload servlet Create and upload Create servlet Meta data files

8 Web browser Web A D A P T E R Application Server Search engine File mapper Metadata handler Hard disk of the machine NETWORKMODULENETWORKMODULE Peer network Adapter Stub Upload manager Download manager Chat engine Controller View JSP Display JSP View servlet Local Browsing Meta data files

9 Web browser Web A D A P T E R Application Server Search engine File mapper Metadata handler Hard disk of the machine NETWORKMODULENETWORKMODULE Peer network Adapter Stub Upload manager Download manager Chat engine Controller Search and Download Search.jsp Download. jsp Search servlet Display Results.jsp Meta data files

10 Web browser Web A D A P T E R Application Server Search engine File mapper Metadata handler Hard disk of the machine NETWORKMODULENETWORKMODULE Peer network Adapter Stub Upload manager Download manager Chat engine Controller Chat Relay post.jsp Recvmsg servlet Sendmsg servlet Display.jsp Meta data files

11 Web browser Web A D A P T E R Application Server Search engine File mapper Metadata handler Hard disk of the machine NETWORKMODULENETWORKMODULE Peer network Adapter Stub Upload manager Download manager Chat engine Controller Meta data files

12 Switching between the network modules P2P Networ k XML database Centralized Index server Structured Centralized network module Structured De- centralized network module Networking Module Routing table info 1 Echo req 2 Echo req Echo reply 3 Echo reply 4 Switching of Network module

13 Architecting the solution Architectural decision at the top level and the tradeoffs – structured or unstructured network

14 Unstructured Networks Ad-hoc topology Queries are flooded for bounded number of hops No guarantees on queries Probs: Fast Resource discovery Availability Query: “xyz” xyz User Interface Metadata Handler and File Handler Peer Network Adapter P2P Networ k Hard disk Metadata Files

15 Structured networks (centralized) Centralized index servers O(1) hops for resource discovery Guarantees on queries – availability Probs: Scalability, Fault tolerance and implicit security Query Response User Interface File Handler Peer Network Adapter P2P Networ k Hard disk Centralized Index server ( Application server ) XML database

16 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 Structured Networks (decentralized) K I put(K 1,I 1 ) (K 1,I 1 ) get (K 1 ) I1I1

17 Tradeoff Structured (decentralized) Structured (centralized) Fast Resource discovery and availability So why not use a combination of both Fault Tolerance, Scalability and Implicit security

18 Switching between the network modules (Polling) P2P Networ k XML database Centralized Index server Structured Centralized network module Structured De- centralized network module Networking Module Routing table info 1 Echo req 2 Echo req Echo reply 3 Echo reply 4 Switching of Network module

19 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

20 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

21 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

22 Architecture Web browser Java Servlets And JSP’s Controller Web Adapter Peer network Adapter Hard disk Meta data files P2P network P2P network Centralized Index server ( Application server ) XML database

23 Quality attributes and tactics Modifiability Use an intermediary – Use of a web adapter removes tight coupling between the modules

24 Quality attributes and tactics … Availability Fault detection  Ping/echo Recovery  Active redundancy  Switching between the network modules Security

25 Questions?