/**************************e -EventMQ Protocol Specification -**************************** -The status of this document is alpha and subject to heavy change
+EventMQ Protocol Specification¶
+The status of this document is alpha and subject to heavy change
License¶
+License¶
This Specification is free software: you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation, either version 2.1 of the License, or (at your option) any later version.
This Specification is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.
Language¶
+Language¶
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119[[1](http://tools.ietf.org/html/rfc2119)].
Architecture¶
+Architecture¶
insert pretty picture here
Topology¶
+Topology¶
eMQP connects a set of client applications (e.g. web servers), a broker, and a pool of workers. Clients connect to the broker as well as the workers.
‘Clients’ is defined as application issuing requests and ‘workers’ as applications that process these requests. (Workers consist of a JobManager and a pool of Worker resources where the job executes.)
The EventMQ broker handles a set of named queues. The broker SHOULD serve clients on a fair request and MAY deliver requests to workers on any basis, including 0MQ’s built-in round robin or least-recently used.
ROUTER Addressing¶
+ROUTER Addressing¶
In the case of request-reply, the broker MUST use a ROUTER socket to accept requests from both clients and workers. The broker MAY use a seperate socket implementing a subset of eMQP, or MAY use a single socket implementing all of eMQP.
From the 0MQ manual[[2](http://api.zeromq.org/master:zmq-socket)] > When receiving messages a ROUTER socket shall prepend a message part containing the identity of the originating peer to the message before passing it to the application. When sending messages a ROUTER socket shall remove the first part of the message and use it to determine the identity of the peer the message shall be routed to.
This extra frame is not shown in the specifications below.
Global Frames¶
+Global Frames¶
An ACK command consists of a 4-frame multipart message, formatted as follows.
eMQP / Client¶
+eMQP / Client¶
A REQUEST command consists of a 7-frame multipart message, formatted as follows.
eMQP / Scheduler¶
+eMQP / Scheduler¶
An INFORM command consists of a 6-frame multipart message, formatted as follows.
eMQP / Worker¶
+eMQP / Worker¶
An INFORM command consists of a 5-frame multipart message, formatted as follows.
Heartbeating¶
+Heartbeating¶
- HEARTBEAT commands are valid at any time after an INFORM command
@@ -646,7 +648,7 @@ EventMQ Protocol Specification
REQUEST Headers¶
+REQUEST Headers¶
Headers MUST be 0 to many comma seperated values inserted into the header field. If there are no headers required, send an empty string MUST be sent where headers are required.
Below is a table which defines and describes the headers.