-
Notifications
You must be signed in to change notification settings - Fork 13
Design
This is a high level design overview of the judge.
The choice to use Node.js in favour of Java (as in the previous version) was made because it allows one to write asynchronous IO applications easily. Surely the JVM is even more fast but since an online judge is an IO bound application it made more sense to use async IO. Node.js allowed us to do that easily.
All IO operations once the judge has started is asynchronous. There are no blocking calls anywhere for that.
This is based on the idea that it should be very simple to add a new database backend to the judge or write a new language support for the judge very easily without compiling the source code from scratch. We managed to abstract out APIs to certain extent to do that.
The previous judge used to compile and run all the program on the same machine. Here we have the concept of master and slave.
A master server is the one that is listening to requests from the outside world to compile programs. Slave is the server which takes orders from the master about compiling and then runs the program, does the output checking, writing to database, etc. There can be many slaves but only master. Once the master gets a request from outside it decides which slave to pass on the request to in a manner that the load is equally distributed among all slaves.