1. DESIGN PATTERN

   Model View Controller design pattern was followed for building this entire project.

2. IMPLEMENTATION DETAILS

   MODELS

   User and Room model, represents the backbone schema of this website. User model consists of User information (username and password) and Room model consists of Room information (room title,socket Id and User Id of all users that connect to that room).

   VIEWS

   There are 3 primary views. Login, Signup, Collection of all the rooms, view for specific rooms. A 404.htm file is also embedded within, which the controller returns to the client is there is any 404 error.

   MODULES USED:

   Node.js, Express.js, MongoDB, Socket.io, Passport.js, Redis Server.

3. FEATURES

   Any company would need an internal messaging tool that would help the teams to connect better even if they are working remotely. A proper website dedicated to messaging can be a better option than a seperate web based mobile application, below are the listed reasons:

   1. Inexpensive – usually included in the price of designing your website
   2. Works on all devices – you dont need a separate site for iOS/Android
   3. Easy to setup – no submitting to app stores, you just need a domain and hosting
   4. A remotely working team will often prefer to share codes, documents, etc. which are mostly stored in computer.

   How does this website works in the given scenario ?

   (a) It does not stores any data in the server, as it assumes that a conversation amongst a team is discreet and is subjected to privacy. Once all the users are connected simultaneously, they can have a conversation at real-time. Once the last user disconnects, all the data in that chatroom is erased.

   (b) Since this is a demo version, it only consists of features like creating rooms and chatting. With further modifications we can use file-system module of nodejs to share files, WebRTC for screen sharing, etc. The security can be further improvised by generating one-time password for entering any room and generating a specific url through which selected users can access to that room using the otp.

4. HOW DOES IT WORKS

   1. Socket.io uses websockets to establish client-server connection. With slight adjustments it can be used for creating chat rooms where multiple users can chat at real-time.

   2. A user can create an account and then he can log in into the website. Passport.js is used to authenticate a user. Redis Server is used to store the user details in the session, so that if a user disconnects then he can reconnect without logging in. Redis Server is an adaptor for Socket.io and acts like a fast cache like storage which can store session details as well as socket details.

   3. User id and Socket id are aggregated together to generate a unique id for every user that logs into a specific chatroom. This ensures that every user entering the chatroom is unique and the server does not confuses between two different users, which would have caused the server to broadcast a same message multiple times into the chatroom.

   4. Socket.io works perfectly if both of the users are connected to same instance of the server. But if two clients are running on different instances of the server then, we must use PubSub model of Redis-Server, which acts as a common bridge between all the server instances, which makes it scalable.

5. TEST CASES :

   1. User Authentication - Only authenticated users can access the website, passwords are hashed using sha512 hashing algorithm and is also salted. A user, after logging in can directly access the content page even if he closes the tab, since his authenticated credentials are stored in session. On the otherhand, a user who hasn't logged in, can't access the web content without logging in.

   2. Adding Users to Room - Every user is assigned a unique id, which is generated by aggregating their socketid as well as their userid. This allows us to remove redundancy anomaly in the room schema, allowing every individual to participate in the room chat without facing any connection related issues.

   3. Disconnected User - If a user gets disconnected, he can simply join the room again without logging in, although the previous chats before he disconnected would have been erased.

   4. Server Shutdown and Restart - when the server goes down, we will make a dummy HTTP GET call to index.html every 4-5 seconds. If the call succeeds, we know that the (Express) server has already set sessionid in the response. So, then we will call socket.io reconnect function. This time because sessionid is set, socket.io handshake will succeed and the user will get to continue chatting happily.