In my final semester of my Masters of Science at Northeastern University, I helped design and implement a simple chatroom application with three other students. The aim was to provide location transparency, replication transparency, failure transparency, and migration transparency within the distributed system such that the client need not concern themselves with the low-level details of interfacing with a distributed system. To achieve this, we used a centralized server, which acted as a coordinator for 2 phase commit, a master time server for clock synchronization, and a load balancer for resources. The central server managed failures at both chat nodes and data nodes, and allowed for the dynamic creation of new chat server nodes in the system.
Chatroom Design Diagram
Our chat nodes were designed to facilitate communication transiently between users in a chatroom using the Publish/Subscribe paradigm. Users would learn about available chatrooms from the central server, and then using the data provided by the central server, locate and subscribe to a chatroom at a separate chat node. They could then publish messages and have them broadcast to the other members in the chatroom and similarly receive broadcasts from other members of the room.
Our data nodes were responsible for holding the state of the application, tracking user information, existing chatrooms, and logs for those chatrooms. We elected to track logs for each chatroom to showcase our implementation of 2 phase commit and for future work where logs may be made available for download to clients. However, due to the short time frame allotted for the project, we could not explore the consequences of making such data available to any given client, and thus this mechanism primarily showcased our ability to facilitate 2 phase commit from multiple sources.
A successful 2 Phase Commit for a message sent within the system, depicted in logs
The central server (i.e. the coordinator for the system) managed the state of the distributed system, tracking which clients were a part of which chatroom so that, in the event of a failure at a chatnode, the state of the chatroom could be regenerated at any remaining chat node. So long as a single chat server was available, our system could react to user requests to join or create chatrooms, though ideally, there should be some minimum number of chat server nodes available depending on the overall usage in the system.
The client interface ran primarily from the command line for simplicity, while users interacted with the chatrooms themselves using a window generated using the Java Swing library. This window allowed users to asynchronously generate their own chat messages while still receiving messages from other users in the chatroom. Although the design was very minimal, it met the requirements laid out in our project proposal.
The command line interface for a logged-in user
The chatroom window, created with the Java Swing library
While our chat service was lightweight and designed to facilitate casual communication between a group of users, it considered many challenges faced in a real-world chat application. For example, it accounted for firewalls, network address translators, and proxy servers that clients might use to connect to chat servers in the system. It also attempted to be resilient to failures of certain nodes, accounting for the inevitable occurrence of partitions in a distributed system when one or more nodes either crashes or becomes unavailable due to network failures.
However, due to the lack of encryption and the method by which we stored user data, it was not recommended that users supply any sensitive information while using our application. Concerns related to encryption and data storage would be addressed in future work.
Chat services have been a significant part of the Internet's ecosystem, starting from the early adoption of the Internet for private users in the 1990s and early 2000s. Even today, we still have many messaging services, including Signal, WhatsApp, and Facebook Messenger, among others. Our chat room project mimicked what is a very real and pervasive type of application in the modern world that holds great relevance to distributed computing.
For further inspection of this project, please go to the following link where there is additional documentation and a link to a Youtube video demonstrating the features of our project:
Comments