From 826cf6f8d83d4ef61727329695ab9760861f7fc4 Mon Sep 17 00:00:00 2001 From: Petr Stefan Date: Mon, 20 Jun 2016 15:23:55 +0200 Subject: [PATCH] Updated Communication (markdown) --- Communication.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/Communication.md b/Communication.md index 6befdef..434e322 100644 --- a/Communication.md +++ b/Communication.md @@ -13,7 +13,7 @@ Communication between the two worker threads is split into two separate parts, each one holding dedicated connection line. These internal lines are realized by ZeroMQ inproc PAIR sockets. In this section we assume that the thread of the worker which communicates with broker is called _listening thread_ and the other -one, which is evaluating incoming jobs is called _job thread_. _Listening +one, which is evaluating incoming jobs is called _execution thread_. _Listening thread_ is a server in both cases (the one who calls the `bind()` method), but because of how ZeroMQ works, it's not very important (`connect()` call in clients can precede server `bind()` call with no issue). @@ -22,9 +22,9 @@ clients can precede server `bind()` call with no issue). Main communication is on `inproc://jobs` sockets. _Listening thread_ is waiting for any messages (from broker, jobs and progress sockets) and passes incoming -requests to the _job thread_, which handles them properly. +requests to the _execution thread_, which handles them properly. -Commands from _listening thread_ to _job thread_: +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 @@ -32,7 +32,7 @@ Commands from _listening thread_ to _job thread_: - `job_url` - URI location of archive with job configuration and submitted source code - `result_url` - remote URI where results will be pushed to -Commands from _job thread_ to _listening thread_: +Commands from _execution thread_ to _listening thread_: - **done** - notifying of finished job. Requires 2 message frames: - `job_id` - identifier of finished job @@ -46,7 +46,7 @@ path. The configuration could be linked there under some well-known name. ### Progress callback -Progress messages are sent through `inproc://progress` sockets. This is only one way communication from _job thread_ to the _listening thread_. +Progress messages are sent through `inproc://progress` sockets. This is only one way communication from _execution thread_ to the _listening thread_. Commands: @@ -69,7 +69,7 @@ Commands from broker to worker: Commands from worker to broker: -- **init** - introduce yourself to the broker. Useful on startup or after reestablishing lost connection. Requires at least two arguments: +- **init** - introduce yourself to the broker. Useful on startup or after reestablishing lost connection. Requires at least 2 arguments: - `hwgroup` - hardware group of this worker - `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. - **done** - job evaluation finished, see **done** command in [[Communication#main-communication]]. @@ -116,10 +116,10 @@ server, its IP address and port is configurable in frontend. Commands from frontend to broker: -- **eval** - evaluate a job. Requires 4 frames: +- **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) - - `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. + - `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 - `result_url` - remote URI where results will be pushed to