gearman_protocol.txt

Gearman Protocol Gearman 协议
-----------------------------

The Gearman protocol operates over TCP, port 4730 by default. It
previously operated on port 7003, but this conflicted with the AFS
port range and the new port (4730) was assigned by IANA. Communication
happens between either a client and job server, or between a worker
and job server. In either case, the protocol consists of packets
containing requests and responses. All packets sent to a job server
are considered requests, and all packets sent from a job server are
considered responses. A simple configuration may look like:

Gearman 协议是建立在TCP协议之上的，默认端口为4730。通讯发生于客户（Client）
与任务服务器(Job Server)，或者工作者(Worker)和任务服务器之间。两种类型的通讯
中使用的网络包(Packet)包括请求包(Request)和应答包(Response)。所有发向任务服务
器的网络包认为是请求包而所有从任务服务器发出则为应答包。下图为一个简单的格
局(Configuration)：


----------     ----------     ----------     ----------
| Client |     | Client |     | Client |     | Client |
----------     ----------     ----------     ----------
     \             /              \             /
      \           /                \           /
      --------------               --------------
      | Job Server |               | Job Server |
      --------------               --------------
            |                            |
    ----------------------------------------------
    |              |              |              |
----------     ----------     ----------     ----------
| Worker |     | Worker |     | Worker |     | Worker |
----------     ----------     ----------     ----------

Initially, the workers register functions they can perform with each
job server. Clients will then connect to a job server and issue a
request to a job to be run. The job server then notifies each worker
that can perform that job (based on the function it registered) that
a new job is ready. The first worker to wake up and retrieve the job
will then execute it.

首先，工作者将自己所能功能的向每一个任务服务器上进行注册。客户将与任务
服务器建立连接，并发送请求给任务服务器，以告之需要执行的任务（Job）。
任务服务器然后会通知每一个具备完成该任务能力的工作者有一个新的任务就绪。
第一个被唤醒的工作者将获取任务并执行之。

All communication between workers or clients and the job server
are binary. There is also a line-based text protocol used by
administrative clients. This part of the protocol is text based so a
custom administrative utility is not required (instead, 'telnet' or
'nc' can be used). This is documented under "Administrative Protocol".

所有工作者或者客户与任务服务器进行的通讯都是二进制格式的（binary）。对于
管理型的客户使用另外一基于文本行（line-based text）的协议。这部分协议是基
于文本的，所以不需要特定的管理工具，只要'telnet' 或是 'nc'就够用了。这部分
在“管理协议（Administrative Protocol）“中阐述。

Binary Packet 二进制数据包
--------------------------

Requests and responses are encapsulated by a binary packet. A binary
packet consists of a header which is optionally followed by data. The
header is:

请求和应答都被封装成二进制的数据包。一个二进制包由包头（Header)和可选的跟
随的数据部分（Data）构成。包头如下：

4 byte magic code - This is either "\0REQ" for requests or "\0RES"
                    for responses.
4字节幻数         - "\0REQ" 表示请求 "\0RES" 表示应答

4 byte type       - A big-endian (network-order) integer containing
                    an enumerated packet type. Possible values are:
4字节类型码       - 是一个大端字节序（Big-endian，网络字节序）表示的整数
                    包含一个枚举类型的包类型码。可能值包括：

                    #   Name                Magic  Type
                    1   CAN_DO              REQ    Worker
                    2   CANT_DO             REQ    Worker
                    3   RESET_ABILITIES     REQ    Worker
                    4   PRE_SLEEP           REQ    Worker
                    5   (unused)            -      -
                    6   NOOP                RES    Worker
                    7   SUBMIT_JOB          REQ    Client
                    8   JOB_CREATED         RES    Client
                    9   GRAB_JOB            REQ    Worker
                    10  NO_JOB              RES    Worker
                    11  JOB_ASSIGN          RES    Worker
                    12  WORK_STATUS         REQ    Worker
                                            RES    Client
                    13  WORK_COMPLETE       REQ    Worker
                                            RES    Client
                    14  WORK_FAIL           REQ    Worker
                                            RES    Client
                    15  GET_STATUS          REQ    Client
                    16  ECHO_REQ            REQ    Client/Worker
                    17  ECHO_RES            RES    Client/Worker
                    18  SUBMIT_JOB_BG       REQ    Client
                    19  ERROR               RES    Client/Worker
                    20  STATUS_RES          RES    Client
                    21  SUBMIT_JOB_HIGH     REQ    Client
                    22  SET_CLIENT_ID       REQ    Worker
                    23  CAN_DO_TIMEOUT      REQ    Worker
                    24  ALL_YOURS           REQ    Worker
                    25  WORK_EXCEPTION      REQ    Worker
                                            RES    Client
                    26  OPTION_REQ          REQ    Client/Worker
                    27  OPTION_RES          RES    Client/Worker
                    28  WORK_DATA           REQ    Worker
                                            RES    Client
                    29  WORK_WARNING        REQ    Worker
                                            RES    Client
                    30  GRAB_JOB_UNIQ       REQ    Worker
                    31  JOB_ASSIGN_UNIQ     RES    Worker
                    32  SUBMIT_JOB_HIGH_BG  REQ    Client
                    33  SUBMIT_JOB_LOW      REQ    Client
                    34  SUBMIT_JOB_LOW_BG   REQ    Client
                    35  SUBMIT_JOB_SCHED    REQ    Client
                    36  SUBMIT_JOB_EPOCH    REQ    Client

4 byte size       - A big-endian (network-order) integer containing
                    the size of the data being sent after the header.
4 字节 包尺寸     - 一个大端字节序（网络字节序）整数。包含一个数据
                    尺寸，表示包头之后将被发送的数据大小。

Arguments given in the data part are separated by a NULL byte, and
the last argument is determined by the size of data after the last
NULL byte separator. All job handle arguments must not be longer than
64 bytes, including NULL terminator.

数据体中承载的参数(Arguments)以是NULL字节进行分割，最末的参数不需要
NULL字节结束，而是由数据尺寸来确定。所有任务句柄（job handle）参数
不得长于64字节，包括NULL结束字节在内。

Client/Worker Requests 客户和工作者都可以发送的请求包
-----------------------------------------------------

These request types may be sent by either a client or a worker:
以下这些请求包类型可以由客户和工作者发送:

ECHO_REQ 回响请求包

    When a job server receives this request, it simply generates a
    ECHO_RES packet with the data. This is primarily used for testing
    or debugging.

    当一个任务服务器收到这个请求包时，必简单的生成一个 ECHO_RES（回响
    应答包）并承载接收到的数据。这类请求包主要用于测试和调试。

    Arguments:
    - Opaque data that is echoed back in response.
    参数
    - 一段不明数据，该数据将在应答时被原样返回。

Client/Worker Responses  客户和工作者都可以发出的应答包
-------------------------------------------------------

These response types may be sent to either a client or a worker:
这些应答包类型可能由客户或者工作者发出:

ECHO_RES 回响应答包

    This is sent in response to a ECHO_REQ request. The server doesn't
    look at or modify the data argument, it just sends it back.

    这类数据包将在应答回响请求包时发送。服务器不用查看或者修改数据参数，
    将其返回即可。

    Arguments:
    - Opaque data that is echoed back in response.
    参数
    - 一段不明数据，该数据在应答时原样返回。

ERROR 错误包

    This is sent whenever the server encounters an error and needs
    to notify a client or worker.
    这类数据包在服务器中遇到错误，并且应该通知客户或工作时，发出。

    Arguments:
    - NULL byte terminated error code string.
    - Error text.

    参数
    - NULL字节结束的错误代码字符串
    - 错误文本

Client Requests  客户发出的请求包
---------------------------------

These request types may only be sent by a client:
这些类型的请求包仅由客户发出:

提交任务请求包
SUBMIT_JOB, SUBMIT_JOB_BG,
SUBMIT_JOB_HIGH, SUBMIT_JOB_HIGH_BG,
SUBMIT_JOB_LOW, SUBMIT_JOB_LOW_BG

    A client issues one of these when a job needs to be run. The
    server will then assign a job handle and respond with a JOB_CREATED
    packet.
    当客户有任务需要执行时，发送这些类型之中的请求包。服务器将分配一个
    任务句柄并以 JOB_CREATED 包应答。

    If on of the BG versions is used, the client is not updated with
    status or notified when the job has completed (it is detached).
    如果使用的是 BG版本的数据包，那么客户将不更新状态，或者当任务完成
    时被通知。（与任务分离）

    The Gearman job server queue is implemented with three levels:
    normal, high, and low. Jobs submitted with one of the HIGH versions
    always take precedence, and jobs submitted with the normal versions
    take precedence over the LOW versions.
    Gearman 任务服务器需要实施具备三个等级的优先队列，普通（Normal）、
    高（high）和低（low）。高优先级版本的方式提交的任务总被优先执行，而一
    普通优先级的次之，低优先级的最末被选择。

    Arguments:
    - NULL byte terminated function name.
    - NULL byte terminated unique ID.
    - Opaque data that is given to the function as an argument.

   参数
   - NULL字节结束的功能名称
   - NULL字节结束的唯一ID
   - 一段不明数据将被传递，以作为功能调用时使用的一个输入参数

SUBMIT_JOB_SCHED 调度型任务请求包

    Just like SUBMIT_JOB_BG, but run job at given time instead of
    immediately. This is not currently used and may be removed.
   
    与SUBMIT_JOB_BG类似，但不同于前者立即运行，而是在指定的时间
    运行任务。当前并未使用，可能会被删除。

    Arguments:
    - NULL byte terminated function name.
    - NULL byte terminated unique ID.
    - NULL byte terminated minute (0-59).
    - NULL byte terminated hour (0-23).
    - NULL byte terminated day of month (1-31).
    - NULL byte terminated month (1-12).
    - NULL byte terminated day of week (0-6, 0 = Monday).
    - Opaque data that is given to the function as an argument.

SUBMIT_JOB_EPOCH 

    Just like SUBMIT_JOB_BG, but run job at given time instead of
    immediately. This is not currently used and may be removed.

    Arguments:
    - NULL byte terminated function name.
    - NULL byte terminated unique ID.
    - NULL byte terminated epoch time.
    - Opaque data that is given to the function as an argument.

GET_STATUS 获取状态请求包

    A client issues this to get status information for a submitted job.

    客户发出该请求包获取一个提交的任务的状态信息。

    Arguments:
    - Job handle that was given in JOB_CREATED packet.

    参数
    - 一个由JOB_CREATED 应答包返回的任务句柄

OPTION_REQ 选项请求包

    A client issues this to set an option for the connection in the
    job server. Returns a OPTION_RES packet on success, or an ERROR
    packet on failure.

   客户发出这个请求包设置任务服务器上连接的选项。如果设置成功，返回
   选项应答包，否则返回错误应答包。

    Arguments:
    - Name of the option to set. Possibilities are:
      * "exceptions" - Forward WORK_EXCEPTION packets to the client.

    参数
    - 选项的名称。可能为:
　　　＊ "exceptions" - 转发工作异常包到客户

Client Responses 客户接受的应答包
---------------------------------

These response types may only be sent to a client:
这些应答包类型只被发送到客户:

JOB_CREATED 任务已创建应答包

    This is sent in response to one of the SUBMIT_JOB* packets. It
    signifies to the client that a the server successfully received
    the job and queued it to be run by a worker.

    这个应答包用于响应任务提交请求包。它通知客户任务服务器成功接受任务
    并且已经加入到任务队列等待工作者执行。

    Arguments:
    - Job handle assigned by server.
    参数
    - 由工作服务器分配的任务句柄。

WORK_DATA, WORK_WARNING, WORK_STATUS, WORK_COMPLETE,
WORK_FAIL, WORK_EXCEPTION

    For non-background jobs, the server forwards these packets from
    the worker to clients. See "Worker Requests" for more information
    and arguments.

    对于非后台任务，工作者发送给任务服务器的这些类型的请求包将被转发到
    客户。详见"工作者请求包"

STATUS_RES 状态应答包

    This is sent in response to a GET_STATUS request. This is used by
    clients that have submitted a job with SUBMIT_JOB_BG to see if the
    job has been completed, and if not, to get the percentage complete.

    发送这些应答包用于响应GET_STATUS请求包。这个请求包主要用于客户通过
    SUBMIT_JOB_BG提交的后台任务之后，查询任务是否已经完成。如果没有则
    可以获取当前完成进程。

    Arguments:
    - NULL byte terminated job handle.
    - NULL byte terminated known status, this is 0 (false) or 1 (true).
    - NULL byte terminated running status, this is 0 (false) or 1
      (true).
    - NULL byte terminated percent complete numerator.
    - Percent complete denominator.

    参数
    - NULL字节结束的任务句柄
    - NULL字节结束的状态是否知晓，取值‘0’（48）则表示false，或者'1'(49)表示true
    - NULL字节结束的运行状态，取值'0'表示false, '1'则表示true
    - NULL字节结束的完成进度分子
    - NULL字节结束的完成进度的分母

OPTION_RES 选项应答包

    Successful response to the OPTION_REQ request.
    成功应答选项请求包

    Arguments:
    - Name of the option that was set, see OPTION_REQ for possibilities.
    参数
    - 选项名称，取值范围见 OPTION_REQ

Worker Requests 工作者请求包
----------------------------

These request types may only be sent by a worker:
这些请求包类型只能由工作者发出:

CAN_DO 可干请求包

    This is sent to notify the server that the worker is able to
    perform the given function. The worker is then put on a list to be
    woken up whenever the job server receives a job for that function.

    这个请求包用过告知工作服务器工作者能够执行某个特定的功能。工作者将被
    列入该功能的唤醒列表中，当工作服务器收到任务时唤醒该列表中的工作者。

    Arguments:
    - Function name.

    参数
    - 功能名称

CAN_DO_TIMEOUT 可干但会超时请求包

     Same as CAN_DO, but with a timeout value on how long the job
     is allowed to run. After the timeout value, the job server will
     mark the job as failed and notify any listening clients.

     和可干请求包一样，但是带有一个超时值，以允许该功能在限定时间内
     完成。超过该限定时间，工作服务器将该任务标记为失败并通知监听的
     的客户。

     Arguments:
     - NULL byte terminated Function name.
     - Timeout value.

     参数
     - NULL 字节结束的功能名称
     - 超过时间值

CANT_DO 不可干请求包

     This is sent to notify the server that the worker is no longer
     able to perform the given function.

     这个请求包用于通知任务服务器该工作者已不能执行某个功能。

     Arguments:
     - Function name.

     参数
     - 功能名称

RESET_ABILITIES 重置能力请求包

    This is sent to notify the server that the worker is no longer
    able to do any functions it previously registered with CAN_DO or
    CAN_DO_TIMEOUT.

    这个请求包用于告知任务服务器工作者不再执行任何已经通过可干包和
    可干超时包登记的功能。

    Arguments:
    - None.

    参数
    - 无。

PRE_SLEEP 睡前请求包

    This is sent to notify the server that the worker is about to
    sleep, and that it should be woken up with a NOOP packet if a
    job comes in for a function the worker is able to perform.
    这个请求包用于告知任务服务器工作者准备睡（进入休眠，因为工作者不
    再准备轮询是否有任务）了。这样，任务服务器在接受到某个工作者可
    以执行的任务时，应该发送酱油包（NOOP）以唤醒工作者。
   

    Arguments:
    - None.

    参数
    - 无

GRAB_JOB 拉活请求包

    This is sent to the server to request any available jobs on the
    queue. The server will respond with either NO_JOB or JOB_ASSIGN,
    depending on whether a job is available.
    这个请求包发送到任务服务器请求获得任务队列中的任务。任务服务器
    如果有可以分配的任务则以JOB_ASSIGN应答，否则以NO_JOB任务包。

    Arguments:
    - None.
    参数
    - 无

GRAB_JOB_UNIQ 拉取特定任务请求包

    Just like GRAB_JOB, but return JOB_ASSIGN_UNIQ when there is a job.
    和拉活请求包一样，但返回JOB_ASSIGN_UNIQ应答包。

    Arguments:
    - None.
    参数
    - 无

WORK_DATA 工作数据请求包

    This is sent to update the client with data from a running job. A
    worker should use this when it needs to send updates, send partial
    results, or flush data during long running jobs. It can also be
    used to break up a result so the worker does not need to buffer
    the entire result before sending in a WORK_COMPLETE packet.

    发送请求包，并使用当前正在运行的任务的输出数据更新客户。当工作者需要
    发送更新、发送部分结果、或者条时间执行的任务的数据使用该请求包。它可
    以将任务输出的结果分段返回，使得工作者不需要在发出工作完成请求包
    （WORK_COMPLETE）之前缓冲任务的全部输出。

    Arguments:
    - NULL byte terminated job handle.
    - Opaque data that is returned to the client.
    参数
    - NULL字节结束的任务句柄
    - 一段不明数据，返回给客户的
 
WORK_WARNING 工作警告请求包

    This is sent to update the client with a warning. It acts just
    like a WORK_DATA response, but should be treated as a warning
    instead of normal response data.

    发送这个请求包包括一个警告以更新客户。它与WORK_DATA应答包一样，
    但不应以正常应答数据对待，而是以警告来处理。

    Arguments:
    - NULL byte terminated job handle.
    - Opaque data that is returned to the client.

    参数
    - NULL字节结束的任务句柄。
    - 一段不明数据，返回给客户的

WORK_STATUS 工作状态请求包

    This is sent to update the server (and any listening clients)
    of the status of a running job. The worker should send these
    periodically for long running jobs to update the percentage
    complete. The job server should store this information so a client
    who issued a background command may retrieve it later with a
    GET_STATUS request.

    发送这个请求包更新任务服务器（以及任务监听该任务的客户）上正在
    运行的任务的状态。对于运行时间很长的任务，工作者应当定期发送这
    种请求包以更新完成进度。任务服务器应当存储这些信息，以当某个
    发送该后台任务的客户在将来发送状态查询请求包(GET_STATUS)来获取
    该状态。

    Arguments:
    - NULL byte terminated job handle.
    - NULL byte terminated percent complete numerator.
    - Percent complete denominator.
    参数
    - NULL 字节结束的任务句柄
    - NULL 字节结束的完成进度的分子
    - 完成进度的分母

WORK_COMPLETE 任务完成请求包

    This is to notify the server (and any listening clients) that
    the job completed successfully.
    发送这个请求包以通知工作服务器（以及任务监听的客户）任务成功
    完成。

    Arguments:
    - NULL byte terminated job handle.
    - Opaque data that is returned to the client as a response.

    参数
    - NULL结束的任务句柄
    - 一段不明数据，作为应答返回给客户

WORK_FAIL 任务失败请求包

    This is to notify the server (and any listening clients) that
    the job failed.

    发送该请求包告知任务服务器（以及任何监听的客户）任务失败。

    Arguments:
    - Job handle.

    参数
    - 任务句柄

WORK_EXCEPTION 任务异常请求包

    This is to notify the server (and any listening clients) that
    the job failed with the given exception.

    发送该请求包用于告知任务服务（以及任何监听的客户）任务因某异常
    失败。

    Arguments:
    - NULL byte terminated job handle.
    - Opaque data that is returned to the client as an exception.

    参数
    - NULL 字节结束的任务句柄。
    - 一段不明数据 作为异常返还给客户

SET_CLIENT_ID 设置客户ID请求包

    This sets the worker ID in a job server so monitoring and reporting
    commands can uniquely identify the various workers, and different
    connections to job servers from the same worker.

    这类请求包在任务服务器上设置工作者ID。因此可以让监控和报告命令众
    多工作者的身份，以区分连接到任务服务器上工作者。

    Arguments:
    - Unique string to identify the worker instance.

    参数
    - 唯一的字符串以标识工作者实例。

ALL_YOURS 全归你了

    Not yet implemented. This looks like it is used to notify a job
    server that this is the only job server it is connected to, so
    a job can be given directly to this worker with a JOB_ASSIGN and
    no worker wake-up is required.

    Arguments:
    - None.

    暂未实现。

Worker Responses 工作者接受的应答包
-----------------------------------

These response types may only be sent to a worker:
这些应答包类型只可能发送给工作者。

NOOP 酱油应答包

    This is used to wake up a sleeping worker so that it may grab a
    pending job.

    这个用于唤醒休眠中的工作者，以使它拉取一个待处理的任务。

    Arguments:
    - None.

NO_JOB 无任务应答包

    This is given in response to a GRAB_JOB request to notify the
    worker there are no pending jobs that need to run.

    这个应答包用于响应GRAB_JOB请求，以通知工作者没有待处理的任务需要执行。

    Arguments:
    - None.

JOB_ASSIGN 任务分配应答包

    This is given in response to a GRAB_JOB request to give the worker
    information needed to run the job. All communication about the
    job (such as status updates and completion response) should use
    the handle, and the worker should run the given function with
    the argument.

    这个应答包用于应答GRAB_JOB请求包，发送给工作者运行任务所需的资料。所有
    有关任务的通讯（比如状态更新、完成应答）都应当使用句柄，工作者应当 根据
    参数执行特定的功能。

    Arguments:
    - NULL byte terminated job handle.
    - NULL byte terminated function name.
    - Opaque data that is given to the function as an argument.

    参数
    - NULL字节结束的任务句柄
    - NULL字节结束的功能名
    - 一段不明数据 在功能执行时作为输入参数

JOB_ASSIGN_UNIQ 特种任务分配应答包

    This is given in response to a GRAB_JOB_UNIQ request and acts
    just like JOB_ASSIGN but with the client assigned unique ID.

    这个应答包用于响应GRAB_JOB_UNIQ请求，其行为和JOB_ASSIGN一样，但
    附带一个客户指定的特定ID.

    Arguments:
    - NULL byte terminated job handle.
    - NULL byte terminated function name.
    - NULL byte terminated unique ID.
    - Opaque data that is given to the function as an argument.

    参数
    - NULL字节结束的任务句柄
    - NULL字节结束的功能名
    - NULL字节结束的特定ID
    - 一段不明数据 用于功能执行时作为参数。

Administrative Protocol 监管协议
--------------------------------

The Gearman job server also supports a text-based protocol to pull
information and run some administrative tasks. This runs on the same
port as the binary protocol, and the server differentiates between
the two by looking at the first character. If it is a NULL (\0),
then it is binary, if it is non-NULL, that it attempts to parse it
as a text command. The following commands are supported:

Gearman 任务服务器也支持基于文本的协议，用于拉取资料以及执行相关监控
任务。它和二进制协议运行于同一端口，服务器根据第一个字符来区别才者。
如果是NULL字节则为二进制协议，否则如果为非NULL，则试图以文件命令进行解析。
支持下列命令。

workers 工作者（们的状态）

    This sends back a list of all workers, their file descriptors,
    their IPs, their IDs, and a list of registered functions they can
    perform. The list is terminated with a line containing a single
    '.' (period). The format is:
    服务器返回一个包含所有工作者的列表，包括文件描述符、IP地址、ID(通过
    SET_CLIENT_ID设置），以及能够执行的功能列表。这个列表以一仅含'.'的行
    结束。格式如下：

    FD IP-ADDRESS CLIENT-ID : FUNCTION ...

    Arguments:
    - None.

status （任务）状态表

    This sends back a list of all registered functions.  Next to
    each function is the number of jobs in the queue, the number of
    running jobs, and the number of capable workers. The columns are
    tab separated, and the list is terminated with a line containing
    a single '.' (period). The format is:
    服务器返回一个包含所有已注册的功能的列表。紧跟功能名之后的是当前
    列队的任务数，正在进行的任务数，以及能够执行该任务的工作者数量。
    列以tab分开，列表以仅含'.'的行结束。格式如下:

    FUNCTION\tTOTAL\tRUNNING\tAVAILABLE_WORKERS

    Arguments:
    - None.

maxqueue 队列长度（设置命令)

    This sets the maximum queue size for a function. If no size is
    given, the default is used. If the size is negative, then the queue
    is set to be unlimited. This sends back a single line with "OK".

    用于设置一个功能可以列队的最大任务数。如果没有size参数，则使用默认值。
    如果size为负数，则无限制。该命令仅返回单行'OK'。

    Arguments:
    - Function name.
    - Optional maximum queue size.

shutdown 关服命令

    Shutdown the server. If the optional "graceful" argument is used,
    close the listening socket and let all existing connections
    complete.

    关闭服务器。如果给定‘优雅’参数，则表示关于监听socket，并让已建立的
    连接完成，然后再关服。
    

    Arguments:
    - Optional "graceful" mode.

version 版本命令

    Send back the version of the server.
    返回服务器的版本。

    Arguments:
    - None.


The Perl version also has a 'gladiator' command that uses the
'Devel::Gladiator' Perl module and is used for debugging.


Binary Protocol Example  二进制协议实例
---------------------------------------

This example will step through a simple interaction where a worker
connects and registers for a function named "reverse", the client
connects and submits a job for this function, and the worker performs
this job and responds with a result. This shows every byte that needs
to be sent over the wire in order for the job to be run to completion.

示例单一步步展示一次简单交互。工作者连接任务服务器并注册一个功能名为
‘reverse'的功能，客户连接并提交一项任务，然后工作者执行任务并以结果
应答之。下列的所有每一个字节都是必须按序发送，才能使任务执行完成。

Worker registration: 工作者注册

Worker -> Job Server
00 52 45 51                \0REQ        (Magic)
00 00 00 01                1            (Packet type: CAN_DO)
00 00 00 07                7            (Packet length)
72 65 76 65 72 73 65       reverse      (Function)


Worker check for job: 工作者查询任务

Worker -> Job Server
00 52 45 51                \0REQ        (Magic)
00 00 00 09                9            (Packet type: GRAB_JOB)
00 00 00 00                0            (Packet length)

Job Server -> Worker
00 52 45 53                \0RES        (Magic)
00 00 00 0a                10           (Packet type: NO_JOB)
00 00 00 00                0            (Packet length)

Worker -> Job Server
00 52 45 51                \0REQ        (Magic)
00 00 00 04                4            (Packet type: PRE_SLEEP)
00 00 00 00                0            (Packet length)


Client job submission: 客户提交任务

Client -> Job Server
00 52 45 51                \0REQ        (Magic)
00 00 00 07                7            (Packet type: SUBMIT_JOB)
00 00 00 0d                13           (Packet length)
72 65 76 65 72 73 65 00    reverse\0    (Function)
00                         \0           (Unique ID)
74 65 73 74                test         (Workload)

Job Server -> Client
00 52 45 53                \0RES        (Magic)
00 00 00 08                8            (Packet type: JOB_CREATED)
00 00 00 07                7            (Packet length)
48 3a 6c 61 70 3a 31       H:lap:1      (Job handle)


Worker wakeup: 工作者被唤醒

Job Server -> Worker
00 52 45 53                \0RES        (Magic)
00 00 00 06                6            (Packet type: NOOP)
00 00 00 00                0            (Packet length)


Worker check for job: 工作者再查询任务

Worker -> Job Server
00 52 45 51                \0REQ        (Magic)
00 00 00 09                9            (Packet type: GRAB_JOB)
00 00 00 00                0            (Packet length)

Job Server -> Worker
00 52 45 53                \0RES        (Magic)
00 00 00 0b                11           (Packet type: JOB_ASSIGN)
00 00 00 14                20           (Packet length)
48 3a 6c 61 70 3a 31 00    H:lap:1\0    (Job handle)
72 65 76 65 72 73 65 00    reverse\0    (Function)
74 65 73 74                test         (Workload)


Worker response for job: 工作者对任务进行应答

Worker -> Job Server
00 52 45 51                \0REQ        (Magic)
00 00 00 0d                13           (Packet type: WORK_COMPLETE)
00 00 00 0c                12           (Packet length)
48 3a 6c 61 70 3a 31 00    H:lap:1\0    (Job handle)
74 73 65 74                tset         (Response)


Job server response to client: 任务服务器应答客户

Job Server -> Client
00 52 45 53                \0RES        (Magic)
00 00 00 0d                13           (Packet type: WORK_COMPLETE)
00 00 00 0c                12           (Packet length)
48 3a 6c 61 70 3a 31 00    H:lap:1\0    (Job handle)
74 73 65 74                tset         (Response)


At this point, the worker would then ask for more jobs to run (the
"Check for job" state above), and the client could submit more
jobs. Note that the client is full duplex and could have multiple
jobs being run over a single socket at the same time. The result
packets may not be sent in the same order the jobs were submitted
and instead interleaved with other job result packets.

此时，工作者将继续获取更多的任务来执行。（上述的‘查询任务’状态），
客户可以提交更多的任务。注意的是，客户是全双功的，在同一个Socket连接上
可能有许多任务正在被执行。任务执行返还结果的数据包不是按照提交任务的顺
序返回。而是多个任务彼此交替的返回的。