为多个请求重用同一个套接字连接

Cur*_*ous 2 c++ sockets tcp libevent multiplexing

这个问题可能有点偏离主题,但我不知道还能问哪里。我正在阅读此https://github.com/msgpack-rpc/msgpack-rpc/blob/master/spec.md并看到该规范包括能够使用相同的连接发送无序消息。

我之前进行TCP套接字编程的唯一方法是在套接字上同步发送请求,例如,我将打开一个套接字127.0.0.1,通过该套接字向该服务器发送请求并等待响应。当我收到所发送请求的响应时,我会在响应请求后通过调用close()客户端和close()服务器来关闭该连接。


作为背景,我正在开发一个 C++ 项目,libevent该项目要做的事情与 RPC 系统非常相似,所以我想知道我应该在底层传输系统中使用什么请求响应套接字周期。

在 C++ thrift 中,有一个名为open()(大概)的客户端方法,它打开一个连接并保持它打开状态,直到您调用close(). 这在被抽象出来的系统中如何工作?例如,在我上面包含的 messagepack-RPC 链接中。最好的做法是什么?如果没有连接,则打开一个连接,发送请求,并在所有先前的请求得到处理后关闭该连接(在服务器上,close()当所有挂起的请求都得到响应时调用)?或者我们是否必须以某种方式尝试使该连接在超出请求生命周期的一段时间内保持活动状态?服务器和客户端如何知道该时间段是多少?recv()例如,我们是否应该在套接字上注册一个读取事件处理程序并在返回时关闭连接0

如果这是一个不同系统以不同方式解决的问题,那么有人可以指导我找到一个资源,我可以使用该资源来读取保持连接活动的可能模式(最好是在事件驱动系统中)?例如,我读到 HTTP 服务器始终保持连接打开,这是为什么?保持每个连接打开是否意味着服务器本质上会泄漏内存?

抱歉,这个看似基本的问题,我以前只做过非常简单的 TCP 套接字编程,所以我可能不知道事情是如何完成的。

use*_*421 5

  1. 在客户端使用连接池。
  2. 客户端中有一个后台线程,该线程会在超时后使空闲连接过期。
  3. 编写服务器,使其可以在每个接受的套接字上处理多个请求,即循环读取请求并发送响应,直到对等方关闭连接,或者读取请求时发生读取超时,或者发生套接字错误。
  4. 任何一方都不要发送关闭消息。关闭套接字就足够了。
  5. 不要使用应用程序 ping 消息来保持连接处于活动状态。如果对等方或中间路由器认为连接成本太高,以至于在一段时间后终止它们,那么您就没有任何业务试图欺骗它。

所有这些都是大多数 HTTP 实现的工作方式。请注意两端的超时时间,以控制两端的空闲资源使用情况。