Peer-to-Peer Publish-Subscribe System

To implement a publish-subscribe (Pub-Sub) system on top of a peer-to-peer (P2P) file sharing system. The goals of project are: to understand how to design and implement layered Internet protocols, learn to develop complex distributed applications as multi-threaded programs that communicate using the socket API. The implementation will be done in three phases. Detailed information/requirements will be provided for each phase. Pub-Sub systems are used for asynchronous communication between producers of information (i.e., publishers) and consumers of information (i.e., subscribers). These systems allow entities that do not know each other to exchange information based on the type of information; data is exchanged when publishers produce data of the type desired by subscribers. Additionally, the communicating entities do not have to be on-line simultaneously because the communication is managed by a centralized component (broker). Traditionally, the publishers store, at the broker, the data they produce together with meta-data describing its type. Subscribers, on the other hand, store at the broker their interests (i.e., types of data). The broker matches the subscribers’ interests with the published data. 3 phases: Phase 1: Phase 1 Description: In this phase, you are required to implement a multi-threaded peer program that acts as both client and server. The implementation consists of the following steps: Write two programs, a TCP client and an iterative TCP server (i.e., very similar to the ones provided in the lecture slides). The server starts by reading from the command line a port number on which it listens for client requests. The client starts by taking two parameters from the command line: the IP address and port number of the server. Then, the client enters an infinite loop and waits for user commands. The user can enter three commands: o publish file_type file_name o search file_type o retrieve file_name The file_type is a string specified by the user (e.g., music, politics). The file_name is the name of a local file in publish or the name of a remote file in retrieve (located at the server). In response to a publish command, the client reads the file from the disk and sends it to the server along with the string specifying its type; the server stores the file on its disk and creates or adds a new entry in a data structure that keeps track of the files and types it has stored. In response to a search command, the client asks the server what files of that type it has. The server returns the names of those files, if any. In response to a retrieve command, the client asks the server to download the specified file; the client stores the downloaded file on its disk. The TCP connections between the client and the server are transient (they are created and terminated for each command). Turn the iterative server built above into a multi-threaded server. Each time a new client request is received at the server, a new thread is created to process the request and send back the appropriate response. Test the user commands from several clients in parallel to make sure the server can deal with concurrent requests. Create a program that incorporates both the multi-threaded server and the client into a “peer node”. Instantiate several peers and test the user commands at each of them. Phase 2 and phase 3 after completion of phase 1