Submission flow - broker point of view

Overall-architecture.md

@@ -676,12 +676,13 @@ with the test and then runs it against different configurations of `msim`.
 
 
 ## Submission flow
+
 This article will describe in detail execution flow of submission from the point of submission into web application to the point of evaluation of results from execution. Only hot path is considered in following description.
 
 
 ### Web Application
 
-First thing user has to submit his/hers solution to web application. Generally web application has to store submitted files and hand over all needed information about submission to broker. More detailed description follows:
+First thing user has to submit his/hers solution to web application. Which provides interface to upload multiple files and then submit them. More detailed description follows:
 
 - user submits his solution to web application
 - T
@@ -693,6 +694,12 @@ First thing user has to submit his/hers solution to web application. Generally w
 - .
 - .
 
+### Web API
+
+After user submit solution then web application has to hand over all needed information about submission to broker. More detailed description follows:
+
+- todo
+
 ### Broker
 
 Broker gets information about new submission from web application. At this point broker has to find suitable worker for execution of this particular submission. When worker is found and is jobless, then broker send detailed submission to worker to evaluation. More detailed description follows:
@@ -744,16 +751,30 @@ Broker gets done message from worker and basically only mark submission as done
 - broker gets "done" message from worker after successfull execution of job
 - appropriate `worker` structure is found based on its identification
 - some checks of invariants (current job identification, right amount of arguments) are executed
+- job results arrived with status "OK"
+    - frontend is notified that job ended successfully
     - deletion of current execution request in `worker` structure follows and appropriate worker is now considered free
     - if worker execution queue is not empty than next waiting request is taken and given as current one
         - after that only missing thing is to send that request to worker and loop back to worker execution
     - if worker queue is empty then appropriate worker remains free and waiting for another execution request
+- job results arrived with status "INTERNAL_ERROR"
+    - current request is retrieved and deleted from current worker
+    - request can be reassigned then it is assigned to another worker
+    - request was assigned too many times
+        - frontend is notified about it and request is thrown away
+- job results arrived with status "FAILED"
+    - frontend is notified through REST API call that job with particular identification failed
+    - request is canceled and if there is some other waiting it is assigned to worker
+
+### Web API
+
+Web API is notified about job status through simple http calls originated from broker. After that API is deciding if evaluated submission will be evaluated immediatelly or on demand. More detailed description follows:
 
-// TODO: broker -> api job_done message
+- todo
 
 ### Web Application
 
-Only remaining part is evaluation of results. Results are obtained from fileserver and evaluated. More detailed description follows:
+Web Application has only a simple work to do. If results is obtained on demand then proper API call is executed and results are obtained and shown to user. More detailed description follows:
 
 - T
 - O