一个关于proto 文件的经验分享 ：gRPC 跨语言双端通信显示错误码：12 UNIMPLEMENTED （附赠gRPC错误码表）

错误现象描述：

在使用c++的客户端向golang的服务端发送远程调用时，显示：

/home/zry/gRPC/grpc-v1.45.2/examples/cpp/DeviceData/greeter_client.cc83
12: unknown service DeviceData.DeviceDataService
Greeter 接收到: RPC 失败

这里的unknown service DeviceData.DeviceDataService是根据我自己的proto文件生成的。
proto 文件如下：

service DeviceDataService{
  rpc SendRTRecordData(RTRecordDatas) returns (RTRecordDataQcs){}
}

而12 是我们客户端调这个服务接口后返回的错误码

部分代码如下：

// 实际的 RPC。
Status status = stub_->SendRTRecordData(&context, request, &reply);
// 对它的状态进行操作。
if (status.ok()) {
  return std::to_string(reply.sensordata_size());
} else {
  std::cout << __FILE__ << __LINE__ << std::endl;
  std::cout << status.error_code() << ": " << status.error_message()
            << std::endl;
  return "RPC 失败";
}

12是status.error_code() 的输出，根据gRPC 错误码表 这里的错误是指远端调用的函数 找不到，在确认，两边的函数使用一致的情况下，我们使用同一份proto 文件。

那么，到底为什么呢？

问题原因

在得到 .proto文件的时候，这是一个golang的文件，即在文件中存在如下设置：

syntax = "proto3";

option go_package = "grpc/DeviceData";
package pb;

而在c++ 中，没有option 指定的 包关键字。 所以我们使用的是 package DeviceData去设定命名空间。

也就是因为这个，导致虽然是同样的接口调用但由于不是同一个命名空间，所以在服务端来说，表现就是 找不到调用方式。

解决方案

修改 proto文件的 package 关键字指定的命名空间让两边一致。问题解决。

附赠gRPC 错误码表

code	数	描述
OK	0	不是错误;成功返回。
CANCELLED	1	操作通常由调用方取消。
UNKNOWN	2	未知错误。例如，当从另一个地址空间接收的值属于此地址空间中未知的错误空间时，可能会返回此错误。此外，未返回足够错误信息的 API 引发的错误可能会转换为此错误。Status
INVALID_ARGUMENT	3	客户端指定了无效的参数。请注意，这与 不同。 表示无论系统状态如何（例如，文件格式不正确）都存在问题的参数。FAILED_PRECONDITION``INVALID_ARGUMENT
DEADLINE_EXCEEDED	4	截止时间在操作完成之前已过期。对于更改系统状态的操作，即使操作已成功完成，也可能会返回此错误。例如，来自服务器的成功响应可能会延迟很长时间
NOT_FOUND	5	未找到某些请求的实体（例如，文件或目录）。服务器开发人员注意：如果整个类别的用户的请求被拒绝，则可以使用逐步推出功能或未记录的允许列表。如果拒绝一类用户中某些用户的请求，则必须使用基于用户的访问控制。NOT_FOUND``PERMISSION_DENIED
ALREADY_EXISTS	6	客户端尝试创建的实体（例如，文件或目录）已存在。
PERMISSION_DENIED	7	调用方没有执行指定操作的权限。 不得用于因耗尽某些资源而导致的拒绝（改用这些错误）。 如果无法识别调用方，则不得使用（对于这些错误，则改用）。此错误代码并不意味着请求有效，也不表示请求的实体存在或满足其他前提条件。PERMISSION_DENIED``RESOURCE_EXHAUSTED``PERMISSION_DENIED``UNAUTHENTICATED
RESOURCE_EXHAUSTED	8	某些资源已用尽，可能是每个用户的配额，或者可能是整个文件系统空间不足。
FAILED_PRECONDITION	9	该操作被拒绝，因为系统未处于执行该操作所需的状态。例如，要删除的目录为非空目录，将 rmdir 操作应用于非目录等。服务实现者可以使用以下准则来决定 、 和 ： （a） 如果客户端可以只重试失败的调用，则使用。（b） 如果客户端应该在更高级别重试（例如，当客户端指定的测试和设置失败时，指示客户端应重新启动读-修改-写入序列），则使用该命令。（c） 如果客户端在系统状态被显式修复之前不应重试，则使用。例如，如果“rmdir”因为目录不为空而失败，则应返回，因为除非从目录中删除文件，否则客户端不应重试。FAILED_PRECONDITION``ABORTED``UNAVAILABLE``UNAVAILABLE``ABORTED``FAILED_PRECONDITION``FAILED_PRECONDITION
ABORTED	10	操作已中止，通常是由于并发问题（如排序器检查失败或事务中止）造成的。请参阅上面的准则，在 、 和 之间做出决定。FAILED_PRECONDITION``ABORTED``UNAVAILABLE
OUT_OF_RANGE	11	尝试的操作超出了有效范围。例如，查找或读取过去的文件末尾。与 不同，此错误表示如果系统状态发生更改，该问题可能会得到解决。例如，如果要求以不在 [32,0^2-32] 范围内的偏移量读取，则将生成 1 位文件系统，但如果要求从超过当前文件大小的偏移量读取，则将生成 <> 位文件系统。和 之间存在相当多的重叠。我们建议在应用时使用（更具体的错误），以便循环访问空间的调用方可以轻松查找错误以检测错误何时完成。INVALID_ARGUMENT``INVALID_ARGUMENT``OUT_OF_RANGE``FAILED_PRECONDITION``OUT_OF_RANGE``OUT_OF_RANGE``OUT_OF_RANGE
UNIMPLEMENTED	12	此服务中未实现或不支持/启用该操作。
INTERNAL	13	内部错误。这意味着底层系统预期的一些不变量已被打破。此错误代码保留用于严重错误。
UNAVAILABLE	14	该服务目前不可用。这很可能是暂时性情况，可以通过回退重试来纠正。请注意，重试非幂等操作并不总是安全的。
DATA_LOSS	15	不可恢复的数据丢失或损坏。
UNAUTHENTICATED	16	该请求没有用于该操作的有效身份验证凭据。

下表列出了 gRPC 库（在客户端或服务器端）可能返回的代码，并总结了生成这些代码的情况。

box	code	在客户端或服务器上生成
客户端应用程序取消了请求	CANCELLED	双
截止时间在服务器返回状态之前过期	DEADLINE_EXCEEDED	双
在服务器上找不到方法	UNIMPLEMENTED	服务器
服务器关闭	UNAVAILABLE	服务器
服务器端应用程序引发异常（或执行除返回状态代码以终止 RPC 之外的操作）	UNKNOWN	服务器
在截止日期到期之前未收到任何回复。当客户端无法向服务器发送请求或服务器无法及时响应时，可能会发生这种情况。	DEADLINE_EXCEEDED	双
在连接中断之前传输的一些数据（例如，写入TCP连接的请求元数据）	UNAVAILABLE	客户
无法解压缩，但支持压缩算法（客户端 -> 服务器）	INTERNAL	服务器
无法解压缩，但支持压缩算法（服务器 -> 客户端）	INTERNAL	客户
服务器不支持客户端使用的压缩机制	UNIMPLEMENTED	服务器
服务器暂时资源不足（例如，已达到流量控制资源限制）	RESOURCE_EXHAUSTED	服务器
客户端没有足够的内存来保存服务器响应	RESOURCE_EXHAUSTED	客户
流量控制协议冲突	INTERNAL	双
解析返回状态时出错	UNKNOWN	客户
身份验证元数据不正确（凭据无法获取元数据、在通道和呼叫上设置的凭据不兼容、元数据中设置的主机无效等）:authority	UNAUTHENTICATED未经身份验证	双
请求基数冲突（方法只需要一个请求，但客户端发送了一些其他数量的请求）	UNIMPLEMENTED未执行	服务器
响应基数冲突（方法只需要一个响应，但服务器发送了其他数量的响应）	UNIMPLEMENTED未执行	客户
解析响应 proto 时出错	INTERNAL内部	客户
解析请求 proto 时出错	INTERNAL内部	服务器
发送或接收的消息大于配置的限制	RESOURCE_EXHAUSTED	双
Keepalive 看门狗超时	UNAVAILABLE不能利用的	双

库从不生成以下状态代码：

• INVALID_ARGUMENT
• NOT_FOUND
• ALREADY_EXISTS
• FAILED_PRECONDITION
• 中止
• OUT_OF_RANGE
• DATA_LOSS

可能希望重试失败的 RPC 的应用程序必须决定重试哪些状态代码。如上表所示，gRPC 库可以针对不同的情况生成相同的状态码。服务器应用程序也可以返回这些相同的状态代码。因此，没有适合在所有应用程序中重试的状态代码的固定列表。因此，各个应用程序必须自行确定哪些状态代码应导致重试 RPC。

---

分享一个有趣的 学习链接：https://xxetb.xet.tech/s/HY8za