EZSHARE: PEER-TO-PEER FILE SYSTEM

Transcription

1 COSC 4319: DISTRIBUTED OBJECT COMPUTING PROJECT DEVELOPMENT REPORT 29 TH OCTOBER 2003 EZSHARE: PEER-TO-PEER FILE SYSTEM ezshare Repository Peer PC Peer PC Peer PC ezshare Development Report 1

2 TEAM MEMBERS REMOVED ezshare Development Report 2

3 CONTENTS 1. Introduction 2. System Requirements 3. System Architecture 4. Analysis Model 5. Web Methods 6. Class Diagrams 7. Web Services Client (Peer) 8. Issues to be Addressed ezshare Development Report 3

4 1. INTRODUCTION We are developing a peer-to-peer file sharing application. The motivation of the project came from the fact that most of the file sharing systems currently available do not allow file transfers if peers are behind a firewall. In our system each peer will publish links to files that it wants to share to a global repository. Peers use the repository to browse the published files and select a file for download. The peers will then be able to connect to each other directly and transfer the files. We intend to overcome this problem by taking advantage of the web services architecture. ezshare is a virtual file system, which emulates a central repository of folder and file links (shortcuts) published by a multitude of computers, known as peers. A real file system on the internet could hardly exist, because of the variety of hardware and software platforms scattered around the world. ezshare Development Report 4

5 2. SYSTEM REQUIREMENTS User subscription A user of the ezshare system should be able to register into the system and establish a user ID and password to be used for future logins. User un-subscription A registered user should be able to unsubscribe from the system and free his user ID. Registered Users Information The system should be able to provide a list of users and summary outlining their activity history User login A user must be able to log in to the repository from any peer. At login the user must provide information regarding the identity of the peer from which the user logged in, the path to the shared directory (list of filenames to be published) and whether the peer is currently behind a firewall or not. Active Users The system must maintain a list of users that are currently logged into the system. These are the users that have published the shared files at any given time in the system. User Refresh In the case that the contents of the shared directory change, the variations must be reflected to the repository on the fly. User logout When desired, a user must be able to log out from the system. By doing so, the list of files published by that user will be removed from the system. Repository Search A user should be able to search through the list of currently published files in the repository and browse through the options. File Download A user should be able to select a file for download and initiate the file download by either connecting directly to the peer PC (if no firewall present), or by requesting the Repository to get the actual file contents (when firewall exists). User-friendliness The system should be user friendly and must guide the user by providing adequate and appropriate messages. ezshare Development Report 5

6 3. SYSTEM ARCHITECTURE The project is based on the Web Services Architecture. Hence the system can be viewed to comprise of the Web Services Server and the Web Services Client. Web Services Server Repository The web service is responsible for subscribing and un-subscribing users, logging in users and retrieving information about the peers from which the user logged in, publishing the files of a peer, searching through the shared files of all peers, revealing the identity of peers to each other when files are to be downloaded and serving as an intermediary when direct file transfer is hindered by the firewall. The repository provides all these tasks to the peers through the ezshare Web Service Interface. Web Services Client Peer The ezshare library handles the communication between the peer and the repository by initiating calls to the ezshare Web Service. It is also responsible for interpreting the response sent by the Web Service and taking appropriate action. The client also consists of the P2P Server, which handles the peer-to-peer communication. The P2P Server polls the repository at periodic intervals to find out if there are any pending requests (upload or download file) for this peer. ezshare Development Report 6

7 Repository Peer PC ezshare Web Service Web Service Calls (File Search/File Transfer) Peer PC ezshare Library P2P Server ezshare Library P2P Server ezshare Library P2P Server Peer-to-Peer File Transfer Calls ezshare Web Service manages the repository and the peer information ezshare Library component that communicates with the ezshare Web Service P2P Server handles peer-to-peer communication Peer PC Figure 1: Architecture of ezshare: peer-to-peer file system Since it is possible for the peers to be behind firewalls, there are 2 scenarios for file download that need to be handled in the ezshare system. The scenarios and the manner in which the system handles them are described below. In each of the cases, assume P1 to be the requestingpeer and P2 to be the ownerpeer. ezshare Development Report 7

8 File Download Scenarios: 1) None of the peers are behind firewall P1 gets the file path, file size, IP address and port number of P2 from the Repository. P1 connects to the P2P server running at P2. P1 receives file from P2. P1 closes connection to P2. 2) Both peers are behind firewall P1 posts an upload task for P2 at the repository. P2 retrieves its allotted tasks after a periodic interval. P2 uploads the file to the repository using the web service. After uploading, P2 posts a download task for P1 at the repository. After polling, P1 retrieves it s allotted task and initiates a file download from the repository using the web service. ezshare Development Report 8

9 4. ANALYSIS MODEL Use Case 1: Registration Actor: User Precondition: 1) The user wants to connect to the web service. Basic Path: 1) The Application invokes registration with the ezshare Web Service. 2) Web Service checks if the user already exists. 3) If username not found register user. Alternate Path: 1) In step 2, if user already exists then notify user. Post condition: The User is registered with the Web Service. ezshare Development Report 9

10 Collaboration Diagram for Registration Use Case 1: subscibe : Sender : EZShare 2: subscibe 3: registeruser : Registration : DBManager Use Case 2: Uploading File Names Actor: Peer uploading file names Precondition: 1) User logged in and send list of filename, IP address and port number. 2) User wants to share his files by uploading them onto the Repository. ezshare Development Report 10

11 Basic Path: 1) The User invokes Refresh on the web server. 2) Web Server deletes file list for that user. 3) Web Server adds the updated files onto the web server. Alternate Path: 2) In step 2, if file list does not exist for the user web server adds the file list to the user. Post condition: Updated file list on the web server. Collaboration Diagram for Uploading file names 1: refreshfilelist : Sender : EZShare 2: refreshfilelist 4: AddFileList : FileListManager 3: DeleteFileList : DBManager ezshare Development Report 11

12 Use Case 3: P2P no fire wall Actor: Peer Precondition: 1) User logged in and send list of filename, IP address and port number. 2) Peer wants to download a file from another peer. Basic Path: 1) Peer calls the search file from the web service. 2) Web Service checks for the requested file name in its repository. 3) Web Service returns list of the peers who have the file. 4) Peer selects from the list and downloads file. Alternate Path: 1) If any of the peers are behind the firewall, jump to use case 4 Post condition: Peer gets the requested file. ezshare Development Report 12

13 Collaboration Diagram for No Fire wall 1: searchfile 2: searchfile : Sender : EZShare : FileSearchManager 3: searchfile : DBManager Use Case 4: P2P Behind Firewall Actor: Receiver Peer and Sender Peer Precondition: ezshare Development Report 13

14 1) Receiver Peer wants to get file from Sender Peer and both/either of them are behind a firewall. 2) Peer has the list of Sender Peers from whom he can download. Basic Path: 1) Receiver Peer posts a message on the web server requesting for the file. 2) Server stores the message in its repository. 3) Sender Peer checks the web server for his messages. 4) Sender Peer sends the requested file to the web server. 5) Web Server stores the file and posts the message to the Receiving Peer and deletes the message for Sender Peer. 6) Receiver Peer checks his messages. 7) Receiver Peer downloads his file. Alternate Path: 1) In Step 4, if the sender peer doesn t have any messages then there won t be a file transfer. 2) In Step 6, the Receiver Peer keeps checking for messages with the Web Server. Post condition: The receiver peer gets the file from the sender peer. Collaboration Diagram for With Firewall Use case 3: addtask 6: gettask : TaskManager 11: gettask : DBManager 10: gettask 1: posttask 2: posttask : Receiver 9: gettask 12: getfile 5: gettask 4: gettask 7: putfile : EZShare 8: putfile 13: getfile : Sender : FileTransferManager ezshare Development Report 14

15 5. WEB METHODS - EZSHARE WEB SERVICE The web service runs at the repository and it has methods to do the following tasks: 1. Registration a new peer can sign up using this method. The peer s id and password are stored in a SQL Server database. 2. Login When the peer logs in, it sends to the repository its id, password, and other information such as whether it is behind a firewall or not, shared directory path, list of filenames, IP address, and port number. After logging in, the peer can search through the list of files of all online peers. 3. Refresh This method is provided so the peer can send an updated shared file list to the repository if shared directory files are modified, added or deleted. 4. Search This method returns a list of all files matching the search string. File metadata, like file size, peer id, IP address, behind firewall or not is also retrieved. 5. Post Task This is necessary if one peer requests a file from another peer but the owner peer (which owns the file) is behind a firewall. So the requesting peer posts a task to the repository which has the following information: requestingpeer, ownerpeer, and filename. 6. Get Task If a peer is behind a firewall, it has to periodically poll the repository to find if any peers are requesting files from it. 7. Put File If the peer cannot send the file directly to a requesting peer, it puts it in the repository. 8. Get File If the peer cannot receive the file directly from an owner peer, it gets it from the repository. Note: We are still deliberating on approaches about firewall issues. The above technique of posting tasks to the repository and polling (in tasks 5 8 above), is an option but we are also considering using SMTP, JMS etc for firewall problems 9. Log Off The peer s file list is removed from the repository and session is terminated. ezshare Development Report 15

16 6. CLASS AND PACKAGE DIAGRAMS 6.1 CLASS DIAGRAM ezshare Development Report 16

17 6.2 PACKAGE DIAGRAM WebServicePackage + EZShare AuthorizationPackage + Authorization + Registration FileManagerPackage + FileListManager + FileSearchManager AlternateFTManagerPackage + FileTransferManager + TaskManager DataBaseManagerPackage + DBManager + DBManagerFactory + SQLDBManager Classes that provide a common functionality have been grouped together to form package. By doing so, the reusability of each package has been enhanced. Care has been taken to avoid cyclic dependency between packages. ezshare Development Report 17

18 7. WEB SERVICES CLIENT - PEERS Peer provides user interface to register, login, and search for a file and download a file. Peer uses the central repository web services through proxy to provide these functionalities. Peer registers to the system using Subscribe web method. Peer logs in to the system using Login web method. It logs out of the system using LogOut web method. Peer also updates its list of files in the shared directory to the repository using refreshfilelist web method when shared directory content changes. Peer allows searching for files using searchfile method. It returns a current list of files matching the search string. File metadata include file size, peer id, IP address and whether the peer is behind firewall. The peer polls the repository for any incoming messages using gettask web method. This helps transferring a file from a peer to another when one of the peers is behind firewall. If the peer is not behind a firewall, the peer listens on a port for the file download requests from other peers. Peer allows downloading a selected file from the search results. The method of transferring a file varies with whether one of the peers is behind firewall or none of the peers is behind firewall. If the sender and receiver peers are not behind firewall, the file is transferred using sockets. Receiver peer requests for the file on the listening port of the sender peer. After receiving the request, the sender peer sends the file back to receiver peer. In the other case when one of the peers is behind firewall, the peer calls posttask to post the task request for the receiver peer to transfer a file. If the receiver peer sees any message requests for the file download request from another peer during polling, it uploads the file to the repository using putfile method and posts a new message using posttask method to the receiver peer to download the file from repository. When the receiver peer sees a message (during polling) to download the file calls the getfile method to download from repository. ezshare Development Report 18

19 1: RequestFile : Peer : RemoteFileTransferManager 2: ListenFileRequests 3: OnRequest 4: GetFile : SocketListener : FileManager COLLABORATION DIAGRAM FOR PEER-PEER FILE TRANSFER If a peer is not behind firewall, ListenFileRequests method of an instance of SocketListener class is called on peer s startup. This listens for remote file requests from other peers. On the user s request to fetch a file from another peer, peer calls RequestFile method of an instance of RemoteFileManager class. This method creates a socket connection to remote peer and sends a file request. At remote peer, the active ListenFileRequests method of SocketListener class listens the file request from the peer. This routes the file request to OnRequest method and continues listening for any more file request. The OnRequest method calls GetFile method on an instance of FileManger class, which sends the file to the peer. ezshare Development Report 19

20 RemoteFileTransferManager Reques tfile() SocketListener ListenFileRequests() OnRequest() FileManager GetFile() CLASS DIAGRAM FOR PEER-PEER FILE TRANSFER ezshare Development Report 20

21 8. ISSUES TO BE ADDRESSED In the current system design, each peer is required to poll the repository at regular interval to check the task list for any pending tasks. This design can result in a performance block, because, it requires the peer to send constant queries to the repository. There are two faces to this performance hindrance: If the time period between two consecutive querying/polling is small, it results in a lot of CPU cycles being consumed at the peer level, and may result in slowing down other processes running on the same peer. If the time period between two consecutive querying/polling is large, then it may result in a longer lag time, between the download request was received and the actual download of file took place. We are in the design phase of overcoming this block, by considering the option of having the SMTP server running on the peer, so that if the firewall is configured correctly, it will not block the SMTP port. That way, the repository can send a hint indicating to the peer, that the file is ready to download. This will avoid the peer from querying the repository on a constant basis. We are also looking at the possibility of using Java Message Service (JMS) API, which can provide reliable and flexible service for the asynchronous exchange data. ezshare Development Report 21