RPC实现需要很长的轮询/“反向RPC”

Question

我正在计划一个项目的早期阶段。我想知道不涉及实施我自己的协议的常规/简单的方法。

我知道RPC的概念--拥有一个服务器来公开客户端可以调用的某些过程。嗯，我有很多客户，但不幸的是，我不能直接连接到他们(NAT/防火墙问题，他们大多是家庭PC)。因此，我正在考虑让客户机直接连接到服务器，并调用“”方法。我猜这是“反向RPC”也就是说，这个方法所要做的就是阻塞，直到服务器决定需要做一些事情(这可能需要几秒钟或几天)，然后返回一个数据片段，该片段指示需要做什么，并在客户机上实际调用适当的代码并将其返回给服务器。注意以下三个步骤：

1. 客户端轮询服务器。等很长时间。
2. 服务器以序列化形式返回某些操作。例如，“给我一个文件”
3. 客户端执行该操作，并将以下内容发送给服务器

所以我不明白我怎么能用HTTP上的东西来完成这个任务，因为HTTP只有一个请求和响应。我想我可以使用GET (步骤1和步骤2)和POST (步骤3)来完成这个任务，但是我希望能有一些更优雅的东西，因为这包括服务器端的大量簿记(每个请求都有一个cookie，等等)。

我在寻找一种跨平台的方法。客户端将在C#中，但我还没有对服务器做出决定。我不在乎这是否是通过HTTP完成的，所以“web服务”可能适用，也可能不适用。

对于一个符合我描述的协议/公约，有什么想法吗？你能给我指出正确的方向吗？

Answer 1

如果您想建立双向通信，并且希望能够导航NAT/防火墙/等等，听起来您可能对WebSocket感兴趣。