Coffee Space

System Architecture

Here is a diagram of the system architecture:

This diagram was generated using draw.io, the XML file can be found here.

Now we will describe the purpose of each class…

Main.java: Here we accept the command line arguments and generally nurse the server into existence with it’s various settings that have been requested.

Server.java: This class is responsible for building the server up and sitting in several infinite loops, waiting for something exciting to happen. How fun.

Connection.java: Now we have code that reads the top of the request and decides whether it is a GET or POST request. If neither, then it gracefully kills itself like some shamed Japanese Samurai.

Get.java: This is where we either retrieve threads or generate new comment threads.

Post.java: This is where we append user data to an existing comment thread.

Hash.java: Here we have secure level hashing, but in this case for generating new filenames for the comment threads. Ideally we want to avoid double naming (there is a check just encase of this rare occurrence of a collision in the wild), but also we want to avoid crawlers trying to store all the user comments. It could take longer than the lifetime of the Universe to crawl through the different comment threads in a brute force fashion - in fact it’s unlikely you would ever randomly find one. This leaves only users who actually need the data making the request, or at least that’s the idea.

Comment Model

To avoid using some database model, I decided to simply use files and the disk. It should be relatively fast on a VPS SSD and ultimately should be simple to understand.

On the disk, each thread is represented by it’s filename. Inside is the following structure:

0001 <Submit Form> <Comment [0]> ... <Comment [N]>

Adding a comment is as simple as appending to the end of the file - a relatively simple operation to perform.

In hindsight, the form submit would have been added to the request itself - but in the case that the system was to be archived, I wanted each comment thread file to be viewable in a browser and served by a simple web browser. Potentially some important history could be captured by this system and it’s important we are able to preserve this.

[Feature] Link generation doesn’t include port

This bug is simply annoying, as links may have to be adapted if the service is running on a port other than port 80.

A detailed description can be found here.

[Security] No filtering for POSTs

This bug is a serious security issue. Any person can keep the server too busy to be used by other users, or in the worst case scenario can crash the server by using up all available disk space.

A detailed description can be found here.

[Security] Filter spam thread generation

This is another serious security issue for the same reason above - the server’s resources could be maximised and therefore eventually cause a denial of service. Another potential issue is that a third party may make more comment threads, a.k.a more files than the underlying filesystem can handle. Although rarely seen, most systems will have a maximum number of files that can be created with unexpected circumstances in those scenarios.

A detailed description can be found here.

[Security] No defence against resource usage

This is another security issue, not as problematic as the ones previous as it simply describes how the server ports may be taken up by an attacker by either performing slow loris or DoS/DDoS. This isn’t as important as the other two security issues, as the attack will eventually pass and leave the server perfectly stable and most VPS services will also defend your service against this.

A detailed description can be found here.