为什么我们必须在TCP服务器套接字编程中获得两个文件描述符？
我使用本教程进行服务器套接字编程链接。对于功能，我没有问题，我想问的是更多关于架构设计的问题。请在教程中看一看。我们实际上会看到两个文件描述符，一个是在调用socket()时，另一个是在调用accept()时。我们在创建套接字时获得文件描述符是有道理的,因为我们将套接字视为文件；在接受不同的连接时，我们必须有多个文件描述符，这也是有意义的。但为什么我们需要两者兼备才能使其发挥作用呢？
共有1个答案
第一个套接字称为监听套接字。TCP是一种面向连接的流。每个客户端连接在自己的套接字上操作，就像一个文件一样。如果您只有一个套接字，您将无法区分在其上接收的数据属于哪个连接。所以TCP套接字的设计方式是让监听套接字以listen模式运行，每次客户端想要建立与服务器的连接时，accept调用都会返回一个新的套接字，也就是客户端套接字，来表示新的连接，这样它就专门用来与这个客户端通信了。
另一方面，UDP是一种基于数据报的无连接协议，其中仅使用一个套接字来处理来自所有客户端的所有数据。
-
问题内容： 我有服务器和客户端。我的服务器接受所有连接并返回到客户端字符串。但是当我尝试发送更多行时，它崩溃了 这是我的服务器代码： 这是我的客户代码： 问题答案： 来自in中的javadoc： 关闭返回将关闭关联的套接字。 另外，关闭（和所有其他打印机/写入器）也将关闭其基础流。因此，您可以通过关闭（in ），然后尝试写入已关闭的套接字来关闭您的套接字。 要解决此问题，请不要关闭。垃圾收集将为您
-
问题内容： 有时，当我重写方法时，在第一次调用时会出现异常，如下所示： 为什么我们被迫打电话？父类有义务是有意义的，但是更重要的是，我们如何知道需要调用一个方法，而不是等待它崩溃？ 问题答案： 为什么我们被迫调用super.method（）？ 组成Android SDK的类非常复杂。例如，活动和片段都必须执行许多操作才能正常运行（即管理生命周期，优化内存使用，在屏幕上绘制布局等）。要求客户端调用基
-
我正在尝试为我的Android应用程序创建一个推送服务，我遵循Google GCM的文档和示例： 我可以注册/注销我的Android应用程序。从我的服务器端，我可以看到我注册了一个订阅，但当我尝试从服务器向我的Android应用程序发送消息时，我总是收到以下错误： 发送消息到设备#0时出错：MismatchSenderId 对于我的Android应用程序，我使用SENDER_ID=20000000
-
C++20概念的一个特点是，在某些情况下，您必须编写。例如，[expr.prim.req]/3中的这个示例：
-
问题内容： 我的代码是这样的： 它在第一次运行时效果很好，但之后每次都给我Errno 9。我究竟做错了什么？ 顺便说一句， 问题答案： 您在关闭的同一套接字上调用。你不能那样做。 至于该文档的说： 套接字对象上所有以后的操作都将失败。 只需将（或您拥有的任何东西）移动到循环中即可。（或者，如果愿意的话，可以分两步使用而不是这样做，这更容易出错，也意味着您不必猜测IPv4与IPv6等）。
-
真的需要你帮忙。 我的项目是通过电缆连接两台PC机，并使用tcp套接字将客户端文本框形式的字符串发送到服务器。问题是ATI只能发送一个字符串，然后连接就会关闭。 注意：某个端口上的连接将在表单加载中建立并成功。