From 207e414b7b5d8056911cecef33d42ba8ff58790d Mon Sep 17 00:00:00 2001 From: Martin Polanka Date: Sat, 22 Oct 2016 11:09:14 +0200 Subject: [PATCH] Change wiki URL --- Overall-architecture.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Overall-architecture.md b/Overall-architecture.md index 407f39f..562a0cb 100644 --- a/Overall-architecture.md +++ b/Overall-architecture.md @@ -4,7 +4,7 @@ **ReCodEx** is designed to be very modular and configurable. One such configuration is sketched in the following picture. There are two separate frontend instances with distinct databases sharing common backend part. This configuration may be suitable for MFF UK -- basic programming course and KSP competition. Note, that connections between components are not fully accurate. -![Overall Architecture](https://github.com/ReCodEx/GlobalWiki/blob/master/images/Overall_Architecture.png) +![Overall Architecture](https://github.com/ReCodEx/wiki/blob/master/images/Overall_Architecture.png) **Web app** is main part of whole project from user point of view. It provides nice user interface and it's the only part, that interacts with outside world directly. **Web API** contains almost all logic of the app including _user management and authentication_, _storing and versioning files_ (with help of **File server**), _counting and assigning points_ to users etc. Advanced users may connect to the API directly or may create custom fronends. **Broker** is essential part of whole architecture. It maintains list of available **Workers**, receives submissions from the **Web API** and routes them further and reports progress of evaluations back to the **Web app**. **Worker** securely runs each received job and evaluate it's results. **Monitor** resends evaluation progress messages to the **Web app** in order to be presented to users. @@ -13,7 +13,7 @@ Detailed communication inside the ReCodEx project is captured in the following image and described in sections below. Red connections are through ZeroMQ sockets, blue are through WebSockets and green are through HTTP(S). All ZeroMQ messages are sent as multipart with one string (command, option) per part, with no empty frames (unles explicitly specified otherwise). -![Communication Img](https://github.com/ReCodEx/GlobalWiki/raw/master/images/Backend_Connections.png) +![Communication Img](https://github.com/ReCodEx/wiki/raw/master/images/Backend_Connections.png) ### Broker - Worker communication @@ -231,7 +231,7 @@ Job is a set/list of tasks (it is generally a set, but order of tasks have some Tasks are executed sequentially -- by the linear ordering of the task graph. Parallel tasks (tasks, which are not directly dependent and thus their linear ordering may be arbitrary) are ordered first by their priority (higher number => higher priority) and second by their order in the configuration file. Priority is important for specifying evaluation flow. See sample picture for better understanding. -![Picture of task serialization](https://github.com/ReCodEx/GlobalWiki/raw/master/images/Assignment_overview.png) +![Picture of task serialization](https://github.com/ReCodEx/wiki/raw/master/images/Assignment_overview.png) Each task has a unique ID (alphanum string like _CompileA_, _RunAA_, or _JudgeAB_ in the picture). These IDs are used to identify tasks (for dependency references, in the log, ...). Numbers in bottom right corner are priorities of each task. Higher number is greater priority. It means, that if task _RunAA_ is done, next must be _JudgeAA_ and not _RunAB_ (that will be also valid linear ordering, but _RunAB_ has lower priority).