@ -27,8 +27,7 @@ requests to the _execution thread_, which handles them properly.
Commands from _listening thread_ to _execution thread_:
- **eval** - evaluate a job. Requires 3 message frames:
- `job_id` - identifier of this job (in ASCII representation -- we avoid endianness issues and also
support alphabetic ids)
- `job_id` - identifier of this job (in ASCII representation -- we avoid endianness issues and also support alphabetic ids)
- `job_url` - URI location of archive with job configuration and submitted source code
- `result_url` - remote URI where results will be pushed to
@ -153,8 +152,7 @@ server, its IP address and port is configurable in frontend.
Commands from frontend to broker:
- **eval** - evaluate a job. Requires at least 4 frames:
- `job_id` - identifier of this job (in ASCII representation -- we avoid endianness issues and also
support alphabetic ids)
- `job_id` - identifier of this job (in ASCII representation -- we avoid endianness issues and also support alphabetic ids)
- `header` - additional header describing worker capabilities. Format must be `header_name=value`, every header shall be in a separate message frame. There is no maximum limit on number of headers. There may be also no headers at all.
- empty frame (with empty string)
- `job_url` - URI location of archive with job configuration and submitted source code