DEMIGUISE STORAGE An Anonymous File Storage System VIJAY KUMAR RAVI PRAGATHI SEGIREDDY COMP 512

SYNOPSIS  Introduction  Abstract  Existing System  Proposed System  Architecture  Server  Client  Peer  Implementation

Introduction  DEMIGUISE Storage System  DEMIGUISE is a magical creature that makes itself invisible  Necessity for such System  Goal of the System  To ensure sender/receiver anonymity

EXISTING SYSTEM & PROPOSED SYSTEM Existing System:  The existing system focusses on anonymous communication  Achieved through various routing protocols  One such protocol is Onion Routing protocol  Used in peer to peer architecture Proposed System:  To achieve anonymous file storage in a network  Uses Client/Server architecture

ARCHITECTURE  Server/Client Architecture  Communication by Message passing

SERVER  Responsible for handling requests from Clients  Capable of connecting with multiple Clients  Uses Sockets for connection  Also responsible for load balancing in the network  Maintains a database

SERVER – DATABASE  Two Tables  File Store Table  Status Table  File Store Table  Origin, Destination, File Name of each file stored in the network  Both Origin & Destination are client ids.  Status Table  Contains information about the status of each client  Used for load balancing

CLIENT  Typically send requests to Server for service  Types of requests  Store a File  Retrieve a File  Delete a File  Maintains a database with list of files stored in the network

PEER  Peer is essentially each client in the network  Responsible for accepting requests from Server  Requests include  Store File  Retrieve File  Delete a File

Implementation  Request Reply Messages between Server/Client  Store a File – Client Requests  Request Server to Store a file  Send the File  Store a File – Server Actions  Request peer to store the file  Ask Client for File  Forward file to peer  Similar procedure to retrieve file

Socket Connections in Server  Two Sockets  Client connect  Peer Connect  Client Connect  Connects multiple clients  Used for communication with client – message passing  Peer Connect  Connects to the required peer to store/retrieve file  Used for communication with peer

Event Flow Diagram – Connected to Server

Event Flow – Store Request CLIENT  Client Sends “Request Store“  Receive Ack and if it is “Ok To Send” then send the file  Wait for Ack from Server SERVER  Receive “message”  Check if message is “Request Store” and reply with “Ok To Send”  Receive the File  Check from database which peer is available to store the file  Forward the file to peer  Insert File Name, Origin, Destination to File Store Table  Send “File Transfer Successful” to Client

Event Flow – Retrieve Request CLIENT  Client Sends “Retrieve Store along with Filename“  Wait for File from Server SERVER  Receive “message”  Check if message is “Retrieve Store”  Check from File Store Table the Destination  Forward the request to peer  Receive the file from peer  Send the file to client

Validation of Requests in Server  Validation of connection request done in Server  To ensure the identity of the Client  Uses a unique Client_Id while the client connects.

LOAD BALANCING  Server forwards the store request to the peer  Balanced load can be maintained in network  Server has information about load on each client  Uses this to decide which peer to forward the incoming file

FUTURE IMPROVEMENTS  Proxy Servers can be used to handle requests  Use of encryption/decryption mechanisms  Authentication based on users instead of client id  Replication of files in more than one system based for more robust system

Questions?

Thank You