P2P Multimedia File Sharing Application using Socket Programming

Transcription

1 1 von :47 Project 40% towards module grade Due date: Week 13 (the week of 13 th April to 17 th April) Team size: 5 members per team P2P Multimedia File Sharing Application using Socket Programming Project Description Your main goal for this project is to build a complete (i.e., the whole project should be completed and running) and scalable (i.e., not only for a limited number of PCs) P2P system for multimedia sharing. The computers comprising the P2P network should be able to exchange multimedia files among themselves, and play them from the same application. Implementation Details You can choose one of the following three options to build your P2P architecture: 1. Pure P2P: Completely distributed. Arbitrary pairs of peers can communicate directly with each other, without the need for any dedicated server. This architecture actually agrees with the P2P definition in true sense. Gnutella is a very popular and well-known example for pure P2P network. 2. Hybrid P2P: Server (not in the traditional sense) based distributed system. The clients are responsible for the files to be downloaded or shared. The server (or server farm), on the other hand, provides a centralized directory and handles client search requests. Napster is a well-known example for Hybrid P2P network. 3. Your own creativity: You are also free to use your knowledge and skills to build a P2P system yourself. For this option, you have to know the basic characteristics of P2P networks and should be confident enough to argue why your proposed network is actually P2P and different from the

2 2 von :47 aforementioned two architectures. For example, just being able to download music files from one computer to another and vice versa, isn t actually P2P there are intricate architectural issues that you should be careful of. Required Features Search: Each host should be able to issue search commands, and obtain the results for its query. From the retrieved results, the host should be able to connect to a peer that holds the requested file, and start downloading from it. It is up to the individual groups how they implement this feature, and how they choose the peer ("nearest" or any other suitable metric, e.g., creating less load/congestion in the network, etc.) to start downloading. -- At the minimum, the user should be able to search a resource file by its file name. -- Also, the system should be able to upload/download multiple files at the same time to/from different peers. Browse: A host should be able to browse the sharable files of other hosts. It is up to the individual groups how they would like to implement this feature. For instance, one host can request for a list of IP addresses of other peers in the network, and then select one of them to browse. Another possible way to implement this feature, which may be more convenient to implement, is to browse the sharable files at a peer when you are downloading a file from that peer. While browsing, the user should also be able to select one of the browsed entries, and start downloading the file immediately from that peer. In addition, each host is free to make the browsable attribute for its shared directory ON or OFF, which means if the browsable option of one host is OFF, no other host will be able to browse its contents. Chat: A node should be able to chat with another node. If a peer is uploading or downloading to or from multiple nodes, then it should be able to chat with a subset or all of these nodes at the same time. Any node found within the upload or download window can be selected to instigate chatting. If multiple nodes are selected, then a conference with the selected nodes should take place. Multiple conferences with different sets of peers in different windows should also be supported. In addition, each node is free to make the chat attribute ON/OFF, which means if the chat option of one node is OFF, other nodes will not be able to send messages to it. Embedded Player: One media player should be incorporated into your application in order to play the downloaded multimedia files. Note that the player must be embedded; you are not allowed to call Microsoft Windows Media Player or any other Media Player from your application to play the files externally. Error Checking Mechanism: A peer should be able to check the integrity of the file downloaded. Look & Feel: When one node is providing a file to another node, the status (the percentage of the file already transferred, and the IP address or ID of the node which is downloading the file) should be shown in that node s upload window.

3 3 von :47 The download-progress should also be shown in the download window at the other node. You will be graded on your ultimate application s look & feel as well, so these things are no less important. Possible Optional Features 1. Advanced searching capability based on file type, music/movie author, and other keywords. 2. Continuation of interrupted file transfers from the point of interruption (may be from a different peer). 3. Mechanism that penalizes a selfish peer that only downloads from others, but never uploads. 4. Use your imagination! Points to Note 1. Our minimum requirement for this project is to be able to see a P2P network running (in a minimum of 4 laptops the larger the number the better), exchanging multimedia files, chatting and viewing them playing with your embedded media player. 2. People generally find Hybrid P2P network (i.e., with a centralized directory server) easier to understand and implement. 3. Groups that successfully implement a PURE P2P network, or their own P2P network architecture, will get bonus points. However, incomplete implementations of any minimum requirements would obviously not be acceptable to get these bonus points. 4. You are free to choose C/C++ or Java to implement the project. Even those with just C/C++ background may consider switching to Java socket programming since some of the requirements for this project can be very quickly achieved with Java (e.g., the embedded media player). Moreover, Java s byte-code should run in any machine irrespective of platforms. Groups that are able to run their application in both Windows and UNIX type machines simultaneously would obviously score some extra points. 5. The NetBeans IDE is a free, open-source Integrated Development Environment for developing Java/C++ software. You are strongly encouraged (suggested) to make use of this tool. 6. You should validate that your design exhibits P2P architecture characteristics. 7. You are not allowed to use open-source codes for the P2P architecture implementation and chatting mechanism. However, it is fine to use them for embedded media player and error-checking mechanism (with proper

4 4 von :47 acknowledgement). Required Experience/Skills 1. Solid background in programming with C/C++ or Java 2. Socket and multithreading programming Interim Reports In order to help ensure that no group is falling behind in meeting the project schedule, two interim reports will be required from each team. Although the reports will not count directly towards your final project marks, they are mandatory requirements to keep track of your progress, and more importantly, to let the TAs help spot any serious issues and give suggestions. There is no format requirement on the interim reports as long as they cover the issues described below. Please the reports to our TA, Jin Yunye, g @nus.edu.sg Report 1: Due by 22nd of February, 11:59PM Each team must submit a report (maximum 3 pages): 1. Briefly describe your system architecture. Use multiple block diagrams if you find it necessary to illustrate each part of your system. Note that the architecture description you have written can still be altered after this. 2. Show the distribution of the workload among group members. 3. Give a summary of work done so far. 4. Give a clear working schedule/timeline for project execution. 5. Identify the difficulties and problems so that the TAs can give their suggestions. Report 2: Due by 22nd of March, 11:59PM Each team must submit a report (maximum 5 pages): 1. Show the system block diagram, indicating clearly the flow of control messages, handshakes, and queries between the peers. Use multiple diagrams if you find it necessary to illustrate each part of your system. Also, describe briefly how you have implemented (or planned to implement) the required features. Try to write it in such a way that you can reuse them in your final report.

5 5 von :47 2. Show the distribution of the workload among group members. 3. Give a summary of work done so far. 4. Give a clear working schedule/timeline for the remaining project execution. 5. Identify the difficulties and problems so that the TAs can give their suggestions. Final Submission and Demo At the end of the project, you are required to: Submit all your source codes on a CD v The deadline will be about 1 or 2 days before the actual demo; date to be announced later Submit a team report (just a softcopy will do; it to Jin Yunye: g @nus.edu.sg) v You can find a description of the report requirements here Give a demo v Every team member needs to speak about the part that he/she has implemented v Each team will be given 20 minutes for the demo, plus a 5-minute setup time. Plan your 20 minutes properly! v Each team s demo will be closed to other teams (to ensure fairness) v Note: We are not expecting PowerPoint presentations. The flow will be much better if you can talk and demo at the same time. Of course, if you feel that having one or two PowerPoint slides could aid your demo, you are welcome to show them. Do a P2P evaluation of your peers contribution in the project v You can find the P2P evaluation form here More details about the final submission and the demo will be provided towards the project due date. For the demo, remember to backup previous working versions if you intend to make any last minute modifications. It will be pointless to claim that the program was working before the demo!

6 6 von :47 Academic Integrity Plagiarism will not be tolerated. Any form of plagiarism will be reported to the University, and will result in serious consequences. Useful Resources Tutorial on P2P Architecture (MS Word document; consolidated from a Wiki originally posted on UIUC website) Wikipedia s entry on P2P networks NetBeans Integrated Development Environment Documentation for NetBeans IDE Java SE Development Kit The Java Tutorials The Java Media Framework Creating Hello World! with Java TCPClient.java and TCPServer.java from Kurose Section 2.7 UDPClient.java and UDPServer.java from Kurose Section 2.8 WebServer.java from Kurose (3 rd edition) Section 2.9 Download the following from the IVLE Workbin, under Project Materials. These are good self-study materials for learning Socket Programming using Java: Multi-Threaded Web Server programming exercise from Kurose, and its Solutions Mail Client programming exercise from Kurose, and its Solutions Web Proxy Server programming exercise from Kurose, and its Solutions Questions? Please direct your questions to our Teaching Assistants, Jin Yunye (g @nus.edu.sg) and Mahtab Hossain (g @nus.edu.sg). Good Luck & Work Hard!