创建包装请求/响应协议的异步/等待API

我有一个请求/响应协议运行在TCP上，我想提供一个异步/等待API。该协议是STOMP，它是一种基于TCP或SSL运行的相当简单的基于文本的协议。在STOMP中，客户端发送六个左右命令帧中的一个，并在该命令的头部指定一个receipt ID。服务器将以RECEIPT或ERROR框架与receipt-id字段进行响应，因此客户端可以将响应与原始请求进行匹配。服务器也可以随时发送一个MESSAGE帧（STOMP基本上是一个消息协议），它不包含receipt-id。创建包装请求/响应协议的异步/等待API

要允许多个未完成的请求并处理任何MESSAGE帧，计划始终有一个Socket.BeginReceive()未完成。所以我在想的是最简单的实现是创建一个可等待的事件（如互斥体），将该事件存储在一个表中，将设置为receipt的命令请求发送到表中并阻止该事件。当socket.BeginReceive()触发功能可以从消息中获得receipt-id，在表中查找事件并发信号（并存储某种状态，如成功或错误）。这将唤醒调用函数，该函数可以查看结果并将调用应用程序的成功或失败返回。

这听起来基本正确吗？我以前使用过异步/等待API，但从未写过自己的API。如果没关系，我应该使用什么样的等待事件？一个简单的Monitor.Wait()会阻止，但不是我想要的方式，对吗？如果我将整个东西包装在Task.Run()中，那么Monitor.Wait()的行为会正常吗？或者是否有我应该使用的新同步构造？我基本上实施HttpClient.GetAsync()，有没有人知道如何在封面下工作？

来源

2013-02-13 Zik

试着看一下WCF http://msdn.microsoft.com/en-us/library/ms731082.aspx非常有效！ – legrandviking 2013-02-13 23:37:26

HttpClient要简单得多，因为HTTP对每个请求只有一个响应。 HTTP中不存在主动提供的服务器消息。

要正确设置这样的事件“流”，最好使用TPL Dataflow或Rx。否则，您必须创建一个无界的接收缓冲区并重复异步的ReceiveMessage调用。所以我建议使用TPL Dataflow管道创建一个“消息”源块，然后匹配一些请求（使用TaskCompletionSource通知发件人它已完成）并将其余（MESSAGE帧）公开为源块。

内部，你的处理管道应该是这样的：

重复BeginReceive - >
TransformBlock的消息框架 - >
- ActionBlock到响应消息匹配请求。
- BufferBlock对于MESSAGE帧。

来源

2013-02-13 23:40:26

TPL DataFlow大有作为。非常适合这种问题。 – spender 2013-02-14 01:09:06

创建包装请求/响应协议的异步/等待API

回答

相关问题