端点、套接字、接受器之间的区别

Posted 2023-02-21

【中文标题】端点、套接字、接受器之间的区别

【英文标题】：Difference between endpoint, socket, acceptor

【发布时间】：2017-11-23 15:05:48

【问题描述】：

我正在尝试理解使用套接字进行网络编程的概念。

据我了解，电话交谈是平行的，

端点是电话号码， 连接手机和手机 接听者是接电话的人。

那么，

Socket 绑定到端点（手机连接到插头）和

Acceptor 可以访问套接字和处理程序 （一个人被放在电话旁边，得到一个任务，如果有人来电怎么办）

如果这是一个有效的可视化，那么为什么你可以将接受器直接绑定到一个端点，然后再给接受器套接字呢？还是上面说的明显错了？

tcp::endpoint ep(boost::asio::ip::address::from_string("192.168.XXX.XXX"), portNumber);
tcp::acceptor a(io_service);
tcp::socket s(io_service);

a.open(ep.protocoll());
a.bind(endpoint);
a.listen(boost::asio::socket_base::max_connections);
a.async_accept(s, myHandler);

【问题讨论】：

好吧，在它接通你之前你先拨打这个号码，对吧？所以，对我来说，在尝试连接套接字之前给接受者一个端点似乎是合适的。为什么它们是否具有可比性很重要？您在使用 asio 时遇到任何实际问题吗？

我使用s.bind() 然后a.async_accept(s, myHandler) 并抛出一些boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> > 所以，我想，也许我对此事的理解是错误的。而且我不明白套接字和接受器之间的区别

接受器绑定到本地地址。这就像，考虑你有多个手机。你告诉接受者：听这个电话，但忽略其余的。因此，当连接到来时，接受者决定“是的，呼叫是给我的开发人员的”，然后它创建一个套接字，以便您（开发人员）可以使用它。有帮助吗？

我认为您最好解释一下您是如何使用 asio 以及您遇到的错误（在问题本身中），而不是试图强制与其他物理对象进行比较。

感谢您的建议，但这基本上是我一直在做的事情。我现在希望得到一个直观的理解，这样我就可以通过思考而不是在谷歌上搜索我想要采取的每一步来解决问题。 （实际上是在学习……）

【参考方案1】：

您的等价性不够准确。将接受器视为一种 被动 套接字：它只是等待另一个端点的套接字请求连接，它是只读的。当接受器“读取”一个请求时（即触发相应的 I/O 事件时），它将分支连接到远程端点的新套接字并将所有进一步的 I/O 工作委托给它。然而，接受器本身仍处于被动模式。

【讨论】：

所以接受者更像是手机，它在收到请求（被调用）时激活套接字（可以做事的主动者），套接字是活动部分，然后使用处理程序知道它必须做什么。这样更好吗？

你可以把acceptor想象成秘书的电话在等待呼入。如果有人拨打秘书的电话，他/她会将电话转接到 CEO 的电话。然后老板可以进行对话、挂断或回电。然而，秘书从不主动打电话。

【参考方案2】：

我感觉到你的痛苦。 我不喜欢 boost::asio 框架中使用的抽象或 api。 这就是我目前所处的位置。

端点是一个IP地址和一个端口。

套接字是工程意义上的通道概念的抽象。它就像两个电话之间的电线，或者两个天线之间的空气。它由发送者和接收者两个端点定义。

接受器是设置套接字（通道）的东西。一个更好的名字可能是 listener，虽然我更喜欢不以 -er 结尾的名字。请告知您是否可以想到一个好的候选人。我在寻找一个更好的名称来描述接受者时发现了这篇文章。也许“接收器”是一个好名字，因为它是一类物理事物的抽象。例如，碟形卫星天线可以充当接收器。

既然您处于 boost::asio 的领域，您可能会发现将 io_service 视为 eventLoop 会更好。那个也困扰着我。

您可能会发现从客观主义（哲学流派）研究无效概念的想法很有价值，在命名事物的挑战和认识论（知识的原则）之间似乎存在对应关系。