As the era of Big Tech monopolies looms over consumers like an invisible shadow, Internet freedom fighters have sought to expedite the development of Web3 and bring its conception into the mainstream. Therefore, it is critical that engineers have a deep understanding of how decentralized protocols – and subsequently the applications built on these foundations – operate. Thus, our group seeks to educate ourselves by creating a peer-to-peer (P2P) chat application in python that will allow two clients to communicate after logging into/looking up users in a directory server. This application will give us experience in basic username/password authentication, HTTP features, and P2P protocols. Ensuring security is a pillar of Web3, and thus we will encrypt our passwords and sensitive information so they are not sent “in-the-clear” over the network. Overall, this project provides many educational experiences, and allows us to dip our toes into the world of decentralized applications.
https://drive.google.com/file/d/1keD73nwK7cVr1lMl4EpD4y9LE9MP1BUp/view?usp=sharing
Common.py
The Common.py class is used by a variety of the other files in our project. Its purpose is to set some variables, such as the server's IP address and port, and to define types of packets that can be sent across our P2P network. First, a configuration message can be sent. A configuration message can be of several types, which correspond to actions users can do. These include registering, logging in, getting the active user, request to connect, agreeing to a connection, and pinging a user. Next, the server can respond with a message, which correspond to a successful login, a successful/failure to connect, getting a list of users, requesting to connect, performing a UDP ping and punch. Next, a child process can send a command of a couple types- punch, send and close. Finally, we define the different types of chat messages that can be sent which include a simple message, a heartbeat, sending data, and punching.
Chat.py
The Chat.py class is how we configure the messages to be sent across our P2P chat system. In this file, we establish a socket connection and then have an event loop that basically listens for incoming packets. It then processes each of the messages in this queue and then performs the action corresponding to the type of message in the queue. The types of messages that this event loop can process include UDP hole punching, sending data, sending a message, and sending a heartbeat. The data is then sent over the UDP socket that was established.
Server.py The ServerUDP.py file contains the UDPRequestHandler class that handles UDP message requests on alternate threads within the Server.py module. Specifically, it takes requests, parses them for the user's JWT for authentication, and then stores the client's IP and port data within the appropriate Redis cache.
ServerUDP.py The Server.py file creates a ServerHandler class that contains all the functions necessary for handling login, sending client lists, and connecting clients for peer-to-peer chat. The server initially sets up a TCP Websocket connection with the client to ensure that data is guaranteed to be sent. When a client logs into the server, their info is fetched from a Mongo database containing a hashed/salted version of their credentials. Session data is stored in two Redis caches in the server's memory, with the first being used to store tokens and the second storing port and IP information. If validated, the client will be given a JWT for their session, allowing them to perform all other operations where login is required. When requested, the server will send a list of all users currently logged in to the client.Clients wanting to peer with another are routed via the server in an initial connection request to the target. If the reply is successful, the server forwards each clients port and IP information to each other, allowing them to perform UDP hole-punching and establish a connection. If multiple messages for peering arrive simultaneously, they are split along our protocol's EOF delimiter from Common.py and then each message is parsed individual. When clients close their connection, or if heartbeats are not received, the server will remove them from the list of logged in users and delete their session data from the Redis cache.
We face a couple of key challenges while completing this project. Given the time constraints of the end of the semester, we were able to overcome some of the challenges, but for the others, we have decided to leave for future work. The first difficulty that we had to overcome was working under different environments. Two of us have Mac computers, while the others were working in a linux environment. As a result, some of the code of the project was not compatible across environments. We understand that this puts a constraint on the ability for everyone to use our P2P network, but we were unable to expand compatibility in such a short time period. This will be one of the primary focuses for the future. Similar to this environment issue, we also had to adjust based off of the network we each used. The Duke wifi network blocked UDP packets, and as a result, we had to make sure to work on our project with a hotspot or off campus. While we initially planned on implementing file sharing over the P2P network, we were not able to get this done in conjunction with the messaging system. We decided that the base functionality of sending messages and encrypting connections to the network was more important. Finally, as this project was more of a proof of concept, we made some concessions on the scalability of our network. In particular, we decided to use a simple dictionary of user's connected to the network instead of a proper database. Another scalability improvement would be the ability to compress messages in order to further decrease the load on the network. These scalability features will need to be fixed in the future in order to expand our P2P network.