这是RPC协议吗？
Is this RPC protocol?
以下两种用例中，哪些被定义为 RPC：
1
客户端将代码序列化为二进制格式，例如 python 函数被 pickle 并放入消息正文中。
消息被发送到服务器，然后服务器反序列化它并运行函数代码。获取结果并通过网络将结果发送回客户端。
（代码在客户端定义并在服务器端执行）
2
客户端发送的消息仅包含服务器应执行的方法的名称文本格式。服务器端定义了方法并运行该方法。之后，结果通过网络发送回客户端。
（代码在服务器端定义并在服务器端执行）
似乎大多数人认为 RPC 仅在 2 用例中定义和使用。另一个问题：Grpc 只是针对第二个用例构建的，不是吗？
RPC 代表“远程过程调用”。您的两个定义都在执行此操作，通过传递（序列化）参数和返回结果（序列化）来远程调用某些代码。
两个定义之间的唯一区别是第一个定义将序列化代码发送到远程服务器，而第二个定义使用服务器上已有的代码。但是 1st 和 2nd 仍然是两种 RPC，只是实现方式不同。
第二个定义与 API（“应用程序编程接口”）相关，因为只有第二个定义具有 well-defined 具有固定签名的 pre-defined 函数的接口。您“知道”API 中有哪些功能以及它们需要哪些参数。因此，在第二种情况下，您只需通过名称（或其他方式）引用这些远程函数，而不是发送代码本身。
如果要在两个定义之间进行选择，那么第 2 个是 RPC 的更经典的定义，它更接近人们在谈论 RPC 时通常的意思。
第二种情况也更安全 - 因为第一种情况允许客户端在服务器上执行任意 unchecked/unreliable 代码，这可能会对其造成伤害。而第二种情况允许服务器严格决定什么应该是 运行 什么类型的参数。
第二种情况也更能提供信息，因为 API 通常有很多关于每个可用函数及其属性的详细文档。在第一种情况下，客户必须对编程有深刻的理解，因为任意代码不再像第二种情况那样得到很好的记录API。
但是，如果您有第 2 个案例，并不意味着您不能同时有第 1 个案例。例如在第二种情况 API 中，您可以只实现函数 ResultTuple CallAnyCode(FunctionCode, ArgumentsTuple) - 这种函数可能允许您远程执行任意代码。所以你已经很好地定义了具有许多功能的 rich API 并且在这个 API 中有一个功能可以 运行 任意代码（可能具有一些更高的管理员身份验证权限）。这也是一些服务器上的常见做法。在这种情况下，第二个定义将在其中包含第一个定义。
关于 GRPC（“Google 远程过程调用”）——这只是 Google 提供的 RPC 概念的一种可能实现，并在所有 Google 中广泛使用服务也是如此。
GRPC 为所有函数定义了严格的接口 (API)。每个函数都有输入协议缓冲区的名称和格式，基本上所有参数都以结构化二进制形式描述（类似于 JSON 但以紧凑二进制形式序列化）。生成的 Protocol Buffer 也有严格的描述。
所以 GRPC 实际上对应于您的第二个定义。因为代码位于服务器上并且具有严格定义的接口。函数仅通过名称引用，无需向服务器上传任何代码。
但这并不意味着 GRPC 不能用于执行任意代码。如果您有足够的权限，您仍然可以创建 GRPC 函数 Result_ProtoBuf CallAnyCode(Code_plus_Arguments_ProtoBuf)，通过它您可以将任意序列化代码传递到服务器并在那里执行它。在这种情况下，GRPC 创建了一个 function-wrapper，它实际上也实现了第一个定义。
以下两种用例中，哪些被定义为 RPC：
1
客户端将代码序列化为二进制格式，例如 python 函数被 pickle 并放入消息正文中。 消息被发送到服务器，然后服务器反序列化它并运行函数代码。获取结果并通过网络将结果发送回客户端。 （代码在客户端定义并在服务器端执行）
2
客户端发送的消息仅包含服务器应执行的方法的名称文本格式。服务器端定义了方法并运行该方法。之后，结果通过网络发送回客户端。 （代码在服务器端定义并在服务器端执行）
似乎大多数人认为 RPC 仅在 2 用例中定义和使用。另一个问题：Grpc 只是针对第二个用例构建的，不是吗？
RPC 代表“远程过程调用”。您的两个定义都在执行此操作，通过传递（序列化）参数和返回结果（序列化）来远程调用某些代码。
两个定义之间的唯一区别是第一个定义将序列化代码发送到远程服务器，而第二个定义使用服务器上已有的代码。但是 1st 和 2nd 仍然是两种 RPC，只是实现方式不同。
第二个定义与 API（“应用程序编程接口”）相关，因为只有第二个定义具有 well-defined 具有固定签名的 pre-defined 函数的接口。您“知道”API 中有哪些功能以及它们需要哪些参数。因此，在第二种情况下，您只需通过名称（或其他方式）引用这些远程函数，而不是发送代码本身。
如果要在两个定义之间进行选择，那么第 2 个是 RPC 的更经典的定义，它更接近人们在谈论 RPC 时通常的意思。
第二种情况也更安全 - 因为第一种情况允许客户端在服务器上执行任意 unchecked/unreliable 代码，这可能会对其造成伤害。而第二种情况允许服务器严格决定什么应该是 运行 什么类型的参数。
第二种情况也更能提供信息，因为 API 通常有很多关于每个可用函数及其属性的详细文档。在第一种情况下，客户必须对编程有深刻的理解，因为任意代码不再像第二种情况那样得到很好的记录API。
但是，如果您有第 2 个案例，并不意味着您不能同时有第 1 个案例。例如在第二种情况 API 中，您可以只实现函数 ResultTuple CallAnyCode(FunctionCode, ArgumentsTuple) - 这种函数可能允许您远程执行任意代码。所以你已经很好地定义了具有许多功能的 rich API 并且在这个 API 中有一个功能可以 运行 任意代码（可能具有一些更高的管理员身份验证权限）。这也是一些服务器上的常见做法。在这种情况下，第二个定义将在其中包含第一个定义。
关于 GRPC（“Google 远程过程调用”）——这只是 Google 提供的 RPC 概念的一种可能实现，并在所有 Google 中广泛使用服务也是如此。
GRPC 为所有函数定义了严格的接口 (API)。每个函数都有输入协议缓冲区的名称和格式，基本上所有参数都以结构化二进制形式描述（类似于 JSON 但以紧凑二进制形式序列化）。生成的 Protocol Buffer 也有严格的描述。
所以 GRPC 实际上对应于您的第二个定义。因为代码位于服务器上并且具有严格定义的接口。函数仅通过名称引用，无需向服务器上传任何代码。
但这并不意味着 GRPC 不能用于执行任意代码。如果您有足够的权限，您仍然可以创建 GRPC 函数 Result_ProtoBuf CallAnyCode(Code_plus_Arguments_ProtoBuf)，通过它您可以将任意序列化代码传递到服务器并在那里执行它。在这种情况下，GRPC 创建了一个 function-wrapper，它实际上也实现了第一个定义。