This project aims to create a cloud-based system that provides secure and efficient image sharing among users. The critical aspects of the project include image encryption through steganography. This feature ensures the privacy and security of images shared on the cloud. Steganography is a technique where user images are concealed within other non-secret images, making the transmission secure against unauthorized access. The second aspect is creating a user-oriented discovery service that allows users to find and connect with their peers using the cloud. It facilitates the sharing and accessing of images among registered users in a secure and controlled manner. Another feature is implementing controlled image sharing with viewing limits in which users can share encrypted images with a specified number of views. Once the limit is reached, access to the image is restricted, enhancing control over how the content is distributed and viewed. Another feature is offline operation support, the system can operate in offline mode, with a mechanism to update the views and permissions once the users or image owners come back online. This feature ensures flexibility and continuity in the image-sharing process. An important aspect of load balancing and fault tolerance in cloud servers is that using a peer-to-peer (P2P) architecture, the cloud servers efficiently manage the load and handle faults to ensure optimal performance and reliability. In summary, the project aims to develop a cloud-based platform for secure, controlled, and efficient image sharing, leveraging steganography for encryption and a robust P2P architecture for managing user interactions and server load.
When all servers are operational, each server shares its current CPU load information with the others. This ensures that every server possesses comprehensive knowledge of its load and the loads of the remaining servers. Consequently, when a multicasted request is received from any client, all servers collaboratively determine the most suitable server to handle the request. A load balancing and election algorithm informs this decision, the details of which are elucidated below.
When a client becomes active in server-client communication, it broadcasts a wake-up multicast message to notify all servers of its operational status. This registration ensures that each server maintains a directory of active clients. As clients are unaware of each other's IP addresses, a client wishing to request an image from another client sends a multicast request to the servers, seeking information about available clients. The elected server responds with a list of running clients and their respective IPs, enabling the requesting client to choose a target for the image request. Subsequently, the client stores this information in its local registry. Suppose a client attempts to communicate with another client but receives no acknowledgment after three attempts. In that case, it sends a multicast request to the servers, asking any of them to attempt contact with the unresponsive client. If the elected server fails to establish communication, it records the client as offline and buffers the message until the client reconnects. When the offline client returns, the server forwards the request to the intended recipient. Additionally, if a server is requested for an image from another client, the client may request image encryption from the servers. The elected server performs the encryption and returns the secured image to the client, who forwards it to the requesting client for decryption if authorized to view it.
In client-to-client communication, a client can request an image from another client by first obtaining its IP address from one of the servers. In response, the targeted client provides a list of available images, each presented in low quality, allowing the requesting client to choose the specific image of interest. Once the requesting client selects, the client holding the desired image can decide whether to send it in decrypted form. The image is transmitted along with a predetermined number of views, indicating the limited number of times the receiving client can view the image. Beyond this set number, the image is automatically deleted. If the client holding the image wishes to update the view count, it can do so by sending an update view request. The image should be deleted from the recipient client's storage if the updated view count is zero.