|
|
@ -1311,15 +1311,15 @@ course so it might be written and integrated in future.
|
|
|
|
|
|
|
|
|
|
|
|
### Fileserver
|
|
|
|
### Fileserver
|
|
|
|
|
|
|
|
|
|
|
|
The fileserver provides access to a shared storage space that contains files
|
|
|
|
The fileserver provides access over HTTP to a shared storage space that contains
|
|
|
|
submitted by students, supplementary files such as test inputs and outputs and
|
|
|
|
files submitted by students, supplementary files such as test inputs and outputs
|
|
|
|
results of evaluation. In other words, it acts as an intermediate storage node
|
|
|
|
and results of evaluation. In other words, it acts as an intermediate storage
|
|
|
|
for data passed between the frontend and the backend. This functionality can be
|
|
|
|
node for data passed between the frontend and the backend. This functionality
|
|
|
|
easily separated from the rest of the backend features, which led to designing
|
|
|
|
can be easily separated from the rest of the backend features, which led to
|
|
|
|
the fileserver as a standalone component. Such design helps encapsulate the
|
|
|
|
designing the fileserver as a standalone component. Such design helps
|
|
|
|
details of how the files are stored (e.g. on a file system, in a database or
|
|
|
|
encapsulate the details of how the files are stored (e.g. on a file system, in a
|
|
|
|
using a cloud storage service), while also making it possible to share the
|
|
|
|
database or using a cloud storage service), while also making it possible to
|
|
|
|
storage between multiple ReCodEx frontends.
|
|
|
|
share the storage between multiple ReCodEx frontends.
|
|
|
|
|
|
|
|
|
|
|
|
For early releases of the system, we chose to store all files on the file system
|
|
|
|
For early releases of the system, we chose to store all files on the file system
|
|
|
|
-- it is the least complicated solution (in terms of implementation complexity)
|
|
|
|
-- it is the least complicated solution (in terms of implementation complexity)
|
|
|
@ -1337,11 +1337,15 @@ A simple solution to this problem is storing supplementary files under the
|
|
|
|
hashes of their content. This ensures that every file is stored only once. On
|
|
|
|
hashes of their content. This ensures that every file is stored only once. On
|
|
|
|
the other hand, it makes it more difficult to understand what the content of a
|
|
|
|
the other hand, it makes it more difficult to understand what the content of a
|
|
|
|
file is at a glance, which might prove problematic for the administrator.
|
|
|
|
file is at a glance, which might prove problematic for the administrator.
|
|
|
|
|
|
|
|
However, human-readable identification is not as important as removing
|
|
|
|
A notable part of the fileserver's work is done by a web server (e.g. listening
|
|
|
|
duplicates -- administrators rarely need to inspect stored files (and when they
|
|
|
|
to HTTP requests and caching recently accessed files in memory for faster
|
|
|
|
do, they should know their hashes), but duplicate files occupied a large part of
|
|
|
|
access). What remains to be implemented is handling requests that upload files
|
|
|
|
the disk space used by CodEx.
|
|
|
|
-- student submissions should be stored in archives to facilitate simple
|
|
|
|
|
|
|
|
|
|
|
|
A notable part of the work of the fileserver is done by a web server (e.g.
|
|
|
|
|
|
|
|
listening to HTTP requests and caching recently accessed files in memory for
|
|
|
|
|
|
|
|
faster access). What remains to be implemented is handling requests that upload
|
|
|
|
|
|
|
|
files -- student submissions should be stored in archives to facilitate simple
|
|
|
|
downloading and supplementary exercise files need to be stored under their
|
|
|
|
downloading and supplementary exercise files need to be stored under their
|
|
|
|
hashes.
|
|
|
|
hashes.
|
|
|
|
|
|
|
|
|
|
|
|