Reference no: EM133289720
Create a private repo for your team and start working. You will be assigned a repo for your team in a couple of days.
MiniProject
Background
In this mini-project, you will work towards building a messaging and content curation service for people to interact with content on Twitter. You will build a time-sensitive queuing data structure and use it to implement a publish-subscribe model for data sharing. You will use
public Twitter application programming interface (API) to access and port content into your service. Finally, you will make your service accessible to users by implementing a client-server paradigm. You will also incorporate basic cryptographic schemes to ensure a degree of security.
Goals
The goals of this mini-project are to:
- Implement sophisticated interactions between different data types;
- Apply principles of safe multithreaded programming to implement thread-safe data types;
- Implement the client-server pattern to support communication between multiple processes or threads, and to use network sockets to communicate across devices; and
- Use application programming interfaces (APIs) provided by modern web systems to build [simple] multi-user applications.
Overview
TimeDelayQueue
You will start by implementing the TimeDelayQueue datatype that can store items that implement the TimestampedObject interface. Whereas in a generic queue data structure, objects are returned in the same order by which they were added, a TimeDelayQueue returns objects in an order that is determined by their individual timestamps and a delay parameter specified when initializing the TimeDelayQueue (hence the name). The delay parameter characterizes the minimum duration of time between the timestamp of an item in the TimeDelayQueue and when it can be accessed. The next item in the TimeDelayQueue is accessed and removed from the queue by the getNext method.
Let's explore the policy of a TimeDelayQueue a bit further in depth. Suppose δ ≥ 0 is the value of the delay parameter of the queue. Let o be the object in the TimeDelayQueue with the smallest (earliest) timestamp τ . Suppose getNext is called at time t. If t - τ ≥ δ, then the TimeDelayQueue returns a reference to o. Otherwise - explicitly put, if t - τ < δ - then no object in the TimeDelayQueue is ready to be served, and the getNext call returns a special NO_MSG object reference. This is the same behaviour as when the TimeDelayQueue is empty.
However, between this method call to getNext at time t and the next call to getNext at t' > t , it is possible that an object with an earlier timestamp than τ has been added.
Each instance of TimeDelayQueue also retains a count of the total number of objects added to the queue over the lifetime of the queue (obtained using the getTotalMsgCount method) and a history of TimeDelayQueue operations ( add and getNext ) to identify peak workload.
Given a time window length (as parameter ), the method getPeakLoad takes the length of a time window (in milliseconds) and returns the maximum number of operations performed in any time window of that length (over the lifetime of the TimeDelayQueue ).
Objects in a TimeDelayQueue may be either persistent or transient. Persistent objects stay in the queue until they are removed. In contrast, transient objects have a timeout duration and should be removed from the queue if they time out before they are accessed and removed.
A complete TimeDelayQueue implementation will support this behaviour of TransientTimestampedObject .
You will make TimeDelayQueue thread-safe so that multiple threads can add or remove items without problematic [unsafe] behaviour.
TwitterListener and PhemeService
The next part of this mini-project is to use the public API for Twitter to obtain posts made by a specific user, which may also have to match a given pattern. We will call the service that interacts with Twitter as TwitterListener . The TwitterListener service should be able to add new posts to an instance of TimeDelayQueue .
Your TwitterListener implementation should use caching (retaining data that was retrieved earlier) to avoid repeated requests to Twitter if multiple requests consume the same tweets. Your caching strategy should retain, at the least, all the tweets obtained in a 5-minute window.
You will use the twitterd library to work with Twitter's public API. You will need to sign up for a developer account with Twitter to get keys and tokens.
instance allows multiple users to subscribe to specific Twitter posts and to communicate among each other. New users are added to a PhemeService instance using the addUser method that includes, as a parameter, a hashed version of the user's password. Use the provided
Salting Passwords
Passwords are used for authentication, but we should never store passwords as plain text because this makes them easy targets for hackers. An alternative approach is to salt the passwords, which is an approach to creating a one-way function. Given the true password, passwd , we compute salt(passwd) and store this value. When a password is provided then we compute its salt and verify that it matches what is stored. Salting is intended to be one-way so it is computationally hard to obtain the password given the salt.
PhemeServer
The third part of this mini-project is to implement a client-server mechanism to route relevant messages/posts to specific users. A PhemeServer wraps an instance of PhemeService . Users can connect to the instance of PhemeServer using their own clients. Your implementation should
support multiple simultaneous connections.
PhemeServer s should support almost all of the operations supported by PhemeService . We will use JSON as the format for communication, and we will use G son as the Java library for working with JSON formatted data.
When communicating with the server, a user's password is sent directly (although it would have originally been encrypted using AES) and the salted hash should be computed at the server- side and used.
The operation corresponds directly to the method name in PheneService . Similarly, the parameters correspond directly to the names in the appropriate method.
The request identifier is a unique per-client identifier (requests from different clients may have the same identifier) that tracks the request. The server should cache its response to a request so that the response can be replayed in case a duplicate request is received within a 2-minute
window.
The request id in the response should match the id of the request. The success field could be "false" if the operation did not succeed. If the operation returns a boolean and the operation succeeded then "success" should be "true" and "response" should indicate the result of
the operation.
For the entirety of this mini-project, everyone should use the following text as the key to set up an instance of AESCipher :
Many years later, as he faced the firing squad, Colonel Aureliano Buendía was to remember that distant afternoon when his father took him to discover ice.
In this setup, Twitter feeds and individual users are data publishers. Individual users are also subscribers to data that matches specific requirements.
The PhemeService is stateful and should preserve its state across shutdown and restarts. The state of the server should be stored in the configuration directory provided when the service is setup. State, when saved to disk, should be stored in encrypted format. You should also
consider compressing the file when writing to disk.
Primary-Backup Mechanism
You should implement a primary-backup mechanism such that one should be able to continue with operations of PhemeServer even if the primary instance should fail (the machine it is running on fails or clients lose their network connection to that instance). When failures occur, we may lose some data but the focus will be on goodput (the number of successful requests
per second).
Tasks
Task 1 Basic TimeDelayQueue implementation with support for add , getNext and getTotalMsgCount .
Task 2 Ensure that TimeDelayQueue supports getPeakLoad , is thread-safe, and can handle transient objects.
Task 3 Use the Twitter API and add posts to a TimeDelayQueue . Implement PhemeService , with the exception of saving and restoring state.
Task 4 Implement PhemeServer as well as saving and restoring state in PhemeService .
Task 5 Support the primary-backup fault tolerance mechanism for PhemeServer.
Attachment:- Message Queues Project.rar