Gearman协议工作于TCP之上，默认使用4730端口。它之前使用端口7003,但与AFS的端口范围冲突，4730端口是由IANA分配的。client和jobserver间，以及worker与jobserver间存在通信交互，这两种情况下的通信协议都是由请求包和响应包组成。所有发送到jobserver的包都认为是请求，所有由jobserver发送的包都认为是响应。一种简单的配置例子是这样的:
---------- ---------- ---------- ----------
|Client | | Client | | Client | | Client |
---------- ---------- ---------- ----------
| | | |
-------------- --------------
|Job Server | | Job Server |
-------------- --------------
----------------------------------------------
---------- ---------- ---------- ----------
|Worker | | Worker | | Worker | | Worker |
---------- ---------- ---------- ----------
初始化时，worker向每个jobserver注册其所能执行的function。client可以连接到一个jobserver并请求运行一个任务,然后Job server通知每个可以执行这个任务的worker（基于worker注册的function）：一个新的任务来了。第一个唤醒的worker取得该任务并执行它。
worker或client跟jobserver间的所有通信都是使用二进制的。也有一个用于管理操作的基于文本行的客户端协议。正因为采用文本协议，没有必要再定制管理工具（可以用”telnet”或”nc”）。详见“管理协议(AdministrativeProtocol)”。
二进制数据包
请求与响应封装于二进制数据包中。一个二进制数据包是由一个消息头和可选的后续数据组成。消息头的构成：
4字节 魔数：请求包是 ”/0REG”，响应包是“/0RES”
4字节 类型：大端存储(网络字节序)的整数，数据包的类型。可取值：
|
序号 |
包类型 |
魔数 |
通信端 |
|
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 |
|
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字节长度：大端存储(网络字节序)的整数，指示消息头后的数据长度。
位于数据部分的参数由一个NULL字节分隔，最后一个参数由最后一个NULL分隔符后的数据长度决定。所有的任务句柄(jobhandle) 参数都不能超过64字节，包括NULL终止符。
Client/Worker请求
这部分请求类型可以由client或worker发送：
ECHO_REG
当jobserver收到这个请求后，它会发送一个ECHO_RES包，包含（发送的）数据。这主要用于测试或调试。
参数：
-
在响应包中回传收到的数据。
Client/Worker响应
这部分响应可以发送到client或worker：
ECHO_RES
这是作为ECHO_RES的请求的响应。服务器不会解析或改变数据参数，只是简单地回传。
参数
-
包中回传收到的数据。
ERROR
当服务器发现错误时发送这种数据包通告client或worker。
参数：
-
NULL终止的错误码串
-
错误描述
Client请求
这部分请求只可以由client发送：
SUBMIT_JOB,SUBMIT_JOB_BG,
SUBMIT_JOB_HIGH,SUBMIT_JOB_HIGH_BG,
SUBMIT_JOB_LOW,SUBMIT_JOB_LOW_BG
client发送其中一个来发起任务请求。服务器会分配一个任务句柄(jobhandle)并发送JOB_CREATED包作为响应。
如果使用了BG系列的包，client不会得到任务状态信息或任务完成通知（它已与服务器脱离）。
Gearman jobserver队列实现了三种级别：normal,high, low。由HIGH系列提交的任务总是有较高优先级，普通系列提交的任务比由LOW系列提交的优先。
参数：
-
以NULL终止的function
-
以NULL终止的唯一ID
-
透传数据，作为function的参数
SUBMIT_JOB_SCHED
与SUBMIT_JOB_BG相似，但在指定的时间执行任务，而不是立即执行。这在当前并没有使用，并且有可能被去除。
参数：
-
以NULL终止的function
-
以NULL终止的唯一ID
-
以NULL终止的分钟(0-59)
-
以NULL终止的小时(0-23)
-
以NULL终止的日(1-31)
-
以NULL终止的月(1-12)
-
以NULL终止的周(0-6,0是周一)
-
透传数据，作为function的参数
SUBMIT_JOB_EPOCH
与SUBMIT_JOB_BG相似，但在指定的时间执行任务，而不是立即执行。这在当前并没有使用，并且有可能被去除。
参数：
-
以NULL终止的function
-
以NULL终止的唯一ID
-
以NULL终止的时间点(epochtime)
-
透传数据，作为function的参数
GET_STATUS
Client发送此来获取提交任务的状态信息。
参数：
-
在JOB_CREATE包中所返回的任务句柄
OPTION_REQ
Client通过此来设置与jobserver的连接选项。成功时返回OPTION_RES包，失败时返回ERROR包。
参数：
-
要设置的选项名，可取值：
-
“exception”: 发送 WORK_EXCEPTION到client
Client响应
这部分响应只发送到client。
JOB_CREATED
这作为SUBMIT_JOB*包的响应。它告示client任务已由服务器成功接收并排队由worker运行。
参数：
-
由服务器分配的任务句柄
WORK_DATA,WORK_WARNING, WORK_STATUS, WORK_COMPLETE,
WORK_FAIL,WORK_EXCEPTION
对于非后台任务，服务器转发这些来自worker包到client。更多信息及参数格式请参见“Worker请求”。
STATUS_RES
这作为对GET_STATUS请求的响应。这用于一个以SUBMIT_JOB_BG提交任务的client来得知任务是否完成，如果没有的话，得到完成的百分比。
参数：
-
NULL终止的任务句柄
-
NULL终止的状态，0(false), 1(true)
-
NULL终止的运行状态，0 (false), 1(true)
-
NULL终止的百分比分子
-
百分比分母
OPTION_RES
是OPTION_RES请求的成功响应。
参数：
-
选项的名称，参见OPTION_REQ的可取值。
Worker请求
这部分请求只能由worker发送：
CAN_DO
发送到server告知worker可以执行给定的function。然后此worker被放入一个列表中，当jobserver收到一个该function类型的job时唤醒该列表的worker。
参数：
-
Function
CAN_DO_TIMEOUT
与CAN_DO相似，但带有超时值，表示该任务可以运行多长时间。在超时后，jobserver会标记该任务为失败，并且告知所有监听的client。
参数：
-
NULL终止的function
-
超时值
CANT_DO
这告知服务器该worker已经不能再执行该function。
参数：
-
Function
RESET_ABILITIES
这告知服务器该worker已不再能执行此前任一由CAN_DO和CAN_DO_TIMEOUT注册的function。
参数：
无
PRE_SLEEP
这告知服务器该worker将进入睡眠状态，如果一个可由该worker执行的任务到来，应该发送一个NOOP包来唤醒它。
参数：
无
GRAB_JOB
向服务器请求一个的有效的队列任务。服务器会根据是否有一个有效任务返回NO_JOB或JOB_ASSIGN。
参数：
无
GRAB_JOB_UNIQ
与GRAB_JOB相似，不同之处在于当有一个任务时返回JOB_ASSIGN_UNIQ。
参数
无
WORK_DATA
用于向client返回运行任务的最新数据。当运行长任务时，worker应该用此来发送更新，发送部分结果，或刷新数据。它也可用于分割结果数据，这样worker不必在发送WORK_COMPLETE包前缓存整个结果集。
参数：
-
NULL终止的任务句柄
-
透传的返回到client的数据
WORK_WARNING
这发送一个告警状态更新给client。这与WORK_DATA相似，但这应被视为是一种警告数据，而不是普通的返回数据。
-
NULL终止的任务句柄
-
透传的返回到client的数据
WORK_STATUS
这发送一个运行任务状态更新到服务器（和任何监听的客户端）。对于长任务，worker应该周期性地发送它来更新完成的百分比。Jobserver 应该保存这种信息，这样一个提交了后台任务的客户端可以通过GET_STATUS请求获取它。
参数：
-
NULL终止的任务句柄
-
NULL终止的百分比分子
-
百分比分母
WORK_COMPLETE
告知服务器（和任何监听的客户端）任务已成功完成。
参数：
-
NULL终止的任务句柄
-
透传的返回给client的响应数据
WORK_FAIL
告知服务器（和任何监听的客户端）任务失败。
-
NULL终止的任务句柄
WORK_EXCEPTION
告知服务器（和任何监听的客户端）任务异常。
参数：
-
NULL终止的任务句柄
-
透传的返回给client的异常响应数据
SET_CLIENT_ID
向jobserver设置 workerID，这样监控和报告命令可以唯一标识不同的worker，以及来自同一个worker的到jobserver的不同连接。
参数：
-
标识worker实例的唯一的字符串
ALL_YOURS
还没有实现。这似乎是用来告知jobserver这是该worker连接的唯一jobserver，所以一个任务可以直接通过JOB_ASSIGN给worker，不需要唤醒机制。
参数：
无
Woker响应
这部分响应只发送给worker：
NOOP
用于唤醒一个正在睡眠的worker，这样它可以去获取一个正挂起的任务。
参数：
无
NO_JOB
这用作GRAB_JOB请求的响应，告知worker没有需要运行任务。
参数：
无
JOB_ASSIGN
这用作GRAB_JOB请求的响应，给worker运行该任务的必需的信息。所有关于此任务的通信过程（例如状态更新和完成响应）应该使用此句柄，并且worker必须用指定的参数运行所给的function。
参数：
-
NULL终止的任务句柄
-
NULL终止的function
-
透传的返回给client的响应数据
JOB_ASSIGN_UNIQ
此用作GRAB_JOB_UNIQ请求的响应，并和JOB_ASSIGN的行为类似，但带有client设置的唯一标识。
参数：
-
NULL终止的任务句柄
-
NULL终止的function
-
NULL终止的唯一标识
-
透传的数据用作function的参数
管理协议
Gearmanjobserver也支持文本行协议来提取信息和运行一些管理任务。它运行于与二进制协议相同的端口，server用第一个字符来区分这两种协议：如果它是NULL(/0)则是二进制的，如果是非NULL则尝试解析成文本命令。以下是支持的命令：
workers
回送一个worker列表，它们的文件描述符、IP、ID和可执行的注册函数列表。这个列表终止于由一个点”.”组成的行。格式是：
FDIP-ADDRESS CLIENT-ID : FUNCTION ...
参数：
无
status
回送一个所有注册函数的列表。在function后的是队列中的任务数，正在运行的任务数，以及有该功能的worker数。列间以tab分隔。这个列表终止于由一个点”.”组成的行。格式是：
FUNCTION/tTOTAL/tRUNNING/tAVAILABLE_WORKERS
参数：
无
maxqueue
设置该function的最大队列长度。如果没有指定大小，使用默认大小。如果大小是负值，则队列是无限大的。一个由“OK”组成的单行作为响应。
参数：
-
Function
-
可选的最大队列长度
shutdown
关闭服务器。如果使用了可选参数“graceful”，关闭监听连接，等待正关闭的连接完成。
参数：
-
可选参数”graceful”模式
version
返回服务器的版本号。
参数：
无
Perl版本还有一个”gladiator”命令，它使用”Devel::Gladiator”Perl模块，用于调试。
二进制协议例子
该例子会逐步察看一个交互过程：worker连接并注册一个叫”reverse”的function，client连接并提交一个该function的任务，worker执行该任务并返回一个结果。这显示了要完成一个任务所需发送的每个字节。
worker注册：
Worker-> Job Server
0052 45 51 /0REQ (Magic)
0000 00 01 1 (Packet type: CAN_DO)
0000 00 07 7 (Packet length)
7265 76 65 72 73 65 reverse (Function)
Workercheck for job:
worker检测任务：
Worker-> Job Server
0052 45 51 /0REQ (Magic)
0000 00 09 9 (Packet type: GRAB_JOB)
0000 00 00 0 (Packet length)
JobServer -> Worker
0052 45 53 /0RES (Magic)
0000 00 0a 10 (Packet type: NO_JOB)
0000 00 00 0 (Packet length)
Worker-> Job Server
0052 45 51 /0REQ (Magic)
0000 00 04 4 (Packet type: PRE_SLEEP)
0000 00 00 0 (Packet length)
Clientjob submission:
Client-> Job Server
0052 45 51 /0REQ (Magic)
0000 00 07 7 (Packet type: SUBMIT_JOB)
0000 00 0d 13 (Packet length)
7265 76 65 72 73 65 00 reverse/0 (Function)
00 /0 (Unique ID)
7465 73 74 test (Workload)
JobServer -> Client
0052 45 53 /0RES (Magic)
0000 00 08 8 (Packet type: JOB_CREATED)
0000 00 07 7 (Packet length)
483a 6c 61 70 3a 31 H:lap:1 (Job handle)
唤醒Worker:
JobServer -> Worker
0052 45 53 /0RES (Magic)
0000 00 06 6 (Packet type: NOOP)
0000 00 00 0 (Packet length)
Worker检测任务:
Worker-> Job Server
0052 45 51 /0REQ (Magic)
0000 00 09 9 (Packet type: GRAB_JOB)
0000 00 00 0 (Packet length)
JobServer -> Worker
0052 45 53 /0RES (Magic)
0000 00 0b 11 (Packet type: JOB_ASSIGN)
0000 00 14 20 (Packet length)
483a 6c 61 70 3a 31 00 H:lap:1/0 (Job handle)
7265 76 65 72 73 65 00 reverse/0 (Function)
7465 73 74 test (Workload)
Worker对任务的响应:
Worker-> Job Server
0052 45 51 /0REQ (Magic)
0000 00 0d 13 (Packet type: WORK_COMPLETE)
0000 00 0c 12 (Packet length)
483a 6c 61 70 3a 31 00 H:lap:1/0 (Job handle)
7473 65 74 tset (Response)
Jobserver 对client的响应:
JobServer -> Client
0052 45 53 /0RES (Magic)
0000 00 0d 13 (Packet type: WORK_COMPLETE)
0000 00 0c 12 (Packet length)
483a 6c 61 70 3a 31 00 H:lap:1/0 (Job handle)
7473 65 74 tset (Response)
至此，worker可以请求更多的任务来运行，client也可以提交更多的任务。注意，client是完全多路复用的，可能在一个socket上同时运行多个任务。结果包可能不是以任务所提交的顺序来发送，而与其它任务的结果包交错在一起。