如何使用gRpc实现双向通信？

Question

如何使用gRpc实现双向通信？

3

多年来，由于各种原因，我们所在的公司已经大量投资使用Windows Communication Foundation（WCF）。目前，我们正在将主要开发平台从Visual Studio 2015升级到Visual Studio 2022。遗憾的是，我们发现我们的WCF客户端和服务器应用程序需要比我们预期的更多的工作才能将它们升级到Visual Studio 2022和更新的.NET框架；它们当然不像以前那样流畅。我们计划保留使用WCF的现有应用程序，但正在考虑其他新应用程序的选项。似乎被推广的主要选项是gRPC，然而，根据我目前了解到的情况，对于我们想要做的某些事情，它似乎是一个非常糟糕的替代品。对于我们，WCF中一些关键的价值在于：

单向函数调用（即只要我们知道调用已传递，我们就不需要等待直到其完成）。我了解到这可以通过gRPC实现。
完全双向通信（即客户端可以对服务器进行调用，反之亦然；服务器可以对客户端进行调用）。我了解到使用“流”可以近似实现此功能，但不容易。

为了说明，考虑涉及三种应用程序类型的简化情况：

声音请求者。一个应用程序，请求在不同位置播放不同的声音，并更改声音参数。
声音播放器。可以播放请求的声音并更改其参数的应用程序。它可以通知声音已完成。
声音处理代理。位于声音请求者和声音播放器之间的应用程序。

我们的WCF实现将声音处理代理作为WCF服务器，声音请求者和声音播放器应用程序作为连接到服务器的客户端。这非常适合我们；代理不需要知道要连接哪些播放器和请求者，它们连接到它（并且可以随时这样做）。代理只提供“编排”服务。下面是一个简化的序列图，以说明可能进行的调用类型：

我的问题是：“如果使用gRpc实现，我们如何在SoundPlayer上实现调用（例如CreateSound，PlaySound等）？”如果我理解正确，由于SoundPlayer是客户端（而不是服务器），我们需要将这些实现为从播放器到服务器的调用的“返回”流。有更简单的方法吗？（我知道我们可以将SoundPlayer作为服务器，让SoundHandlerProxy作为客户端连接-但这意味着代理需要知道它要连接的所有播放器，我们宁愿避免这种情况。）或者，除了gRpc之外，我们还可以迁移到其他东西（最好是未来至少十年稳定的东西）吗？

- AndrewCh

不确定这是否符合您的要求，但请查看grpc-dotnet GitHub上的“Racer”示例。它是用于Web应用程序的，但发送双向消息的原则仍然适用。 - Matthew Watson

谢谢@MatthewWatson。我已经看了你指给我的例子。我认为这大致是我自己迄今为止所达到的方法——即使用流。我的问题在于，我需要我的服务器（SoundHandlerProxy）能够调用客户端（SoundPlayer）上的许多不同函数。在这种情况下，我需要设置许多不同的流或使用单个流，但构建一些方式来说明我想要客户端执行哪个“函数”。两者都可能，但远非使用WCF时那么容易。感谢您的意见。 - AndrewCh

你想要实现的函数类似于服务器可以在客户端调用该函数，客户端可以选择执行该方法，并且指定使用c#语言。我的理解是否符合您的想法？ - Jiayao

在您当前的WCF应用程序中，您特别使用了https://learn.microsoft.com/en-us/dotnet/framework/wcf/feature-details/one-way-services和https://learn.microsoft.com/en-us/dotnet/framework/wcf/feature-details/duplex-services方法吗？ - Eric Anderson

你好@EricAnderson，很抱歉回复慢了--我一直不在。回答你的问题：(1)是的，我们对于单向函数调用使用“IsOneWay=true”。我们可以确定函数调用已经被传递，但除此之外我们没有得到任何函数调用的响应（这对我们来说没问题）。(2)是的，我们正在使用“CallbackContract”。其他信息：通常我们使用NetTcpBinding（启用可靠会话和有序设置），偶尔使用NetNamedPipeBinding。 - AndrewCh

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Eric Anderson · Answer 1

我不是 .Net 专家，所以可能会有些细节错误。但是我认为要点是正确的。

单向服务 在网络传输时并不太有趣，因为它们仍然使用 HTTP 请求/响应。参考单向样例

当调用操作时，服务在执行服务操作之前返回 HTTP 状态码为 202……调用操作的客户端会一直阻塞，直到收到来自服务的 202 响应。

因此，它们更像是存根功能，并且可以在 gRPC 中轻松模拟。在 gRPC 中，您将定义该方法返回 google.protobuf.Empty，并在服务器端在另一个线程中启动长时间运行的工作，然后立即返回。

service Foo {
  rpc Bar(BarRequest) returns (google.protobuf.Empty);
}

public class FooService : Foo.FooBase
{
    public override Task<Empty> Bar(BarRequest request,
        ServerCallContext context)
    {
        startProcessingInAnotherThread(request);
        return Task.FromResult(new Empty {});
    }
}

全双工通信似乎与双工服务相同。这些通过配置客户端以知道服务器如何到达它（其主机：端口）来工作。然后，客户端将该信息发送到服务器，以便服务器在未来向其发送RPC。这种设计肯定会对安全性产生影响，您应该研究一下您正在使用的安全模型。

在gRPC中，客户端只需向服务器发送一个通道地址字符串，然后服务器创建一个到该地址的通道即可模拟此过程。

service SoundHandler {
  rpc Connect(ConnectRequest) returns (google.protobuf.Empty);
}

message ConnectRequest {
  enum Type {
    TYPE_UNKNOWN = 0;
    TYPE_SOUND_REQUESTER = 1;
    TYPE_SOUND_PLAYER = 2;
  };

  string channelAddress = 1;
  Type type = 2;
}

service SoundPlayer {
  rpc CreateSound(CreateSoundRequest) returns (CreateSoundResponse);
  // ...
}

service SoundEventReceiver {
  rpc SoundFinished(SoundFinishedRequest) returns (SoundFinishedResponse);
}

然后，在服务中，您将为回调创建一个通道到提供的地址。

public class SoundHandlerService : SoundHandler.SoundHandlerBase
{
    public override Task<Empty> Bar(ConnectRequest request,
        ServerCallContext context)
    {
        var channel = GrpcChannel.ForAddress(request.channelAddress);
        if (request.type == TYPE_SOUND_PLAYER) {
          var channel = GrpcChannel.ForAddress(request.channelAddress);
          var client = new SoundPlayer.SoundPlayerClient(channel);
          registerSoundPlayer(channel, client);
        } // ...
        return Task.FromResult(new Empty {});
    }
}