Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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