TCP/IP .NET 套接字效率

Question

我创建了一个处理 TCP 连接的库。它存在于服务器和客户端之外。根据 MSDN 的所有示例和可信来源的建议，我应该在 TcpClient 和 TcpListener 之间建立连接，然后从 TcpClient 向 TcpListener 发送数据并接收响应，最后关闭连接。

但我采取了不同的方法：首先我没有使用异步连接。其次，我没有让客户端在向服务器发送数据后等待响应。第三，我没有关闭连接。

我没有选择异步路径，因为我不知道使用它的好处。我没有让客户端等待响应，因为服务器不会响应某些消息。我没有关闭连接，因为我觉得客户端需要很长时间才能重新连接到服务器，只是为了通过流快速发送一些数据。由于连接没有关闭，而且我仍然希望新客户端能够连接，我让流监听器 - 现有客户端的 - 监听不同的线程。由于我不知道如何使用 FTP，所以我使用 FileStream 读取文件并将它们转换为要通过我的 TCP 连接发送的字节。

我的问题是： 1. 为什么要使用异步连接？ 2. 客户端是否应该总是收到来自服务器的响应？ 3. 如果您知道数据将在前一个数据发送后不久发送，是否应该关闭连接。 4. 让不同的线程处理每个客户端的通信是不是一个好主意。我使用了 ThreadPool，尽管我不确定线程​​的执行是如何工作的。是否在一个线程中异步执行不同的操作？ 5.使用我的通过TCP连接从文件发送读取字节的方法来实现文件共享而不是使用FTP方法有什么缺点吗？

Answer 1

1. 为什么要使用异步连接？

异步避免阻塞操作。阻塞操作意味着被阻塞的线程不能用于其他任何事情，如果是 UI 线程，那么 UI 也会被阻塞。

线程是一种宝贵的资源，在 Windows^* 上，不要将它们浪费在等待可能永远不会响应的其他进程上。

1. 客户端是否应该总是收到来自服务器的响应？ 3. 如果您知道数据将在上一个数据发送后不久发送，是否应该关闭连接。

这些都取决于您正在实施的协议。在某些情况下，简单的请求、响应和关闭就是方法。在其他情况下，大多数数据的连接可能以一种方式长期存在。在某些情况下，单个客户端可能会使用多个并发套接字。

4. 让不同的线程处理每个客户端的通信是个好主意吗

没有。请参阅上面关于线程昂贵的信息。最好让一个小线程池为大量客户端提供服务。对于简单的情况——例如。学习时 – 从每​​个客户端模型的线程开始可能会更容易，但它只是无法扩展到少量^** 客户端。

最后你不太可能做得比框架中的更好：有很多经验（和失败的方法^*** ) 在使用 TCP/IP 实现服务器的历史中。

5. 使用我通过 TCP 连接从文件发送读取字节的方法而不是使用 FTP 方法来实现文件共享有什么缺点吗？

你想要一份多长的清单？开始：

• FTP 是一种标准并得到广泛支持。
• FTP 允许单个客户端会话执行许多操作。
• 在用完其他资源之前，您会因线程调度而使 CPU 陷入困境（假设您没有先用完线程堆栈的虚拟地址空间）。

---

^* 不同的操作系统具有不同的线程/进程模型，具有不同的工程权衡。

^** 你对系统的大小（客户端数量、连接速率、数据量……）只字不提，所以我只能笼统地说。

^*** 例如Socket 类支持三种不同的异步模型。

Answer 2

1. 为什么要异步？这很容易！您有 2 个选择：打开新线程并在套接字读取操作时阻止它或使用异步套接字。线程的唯一问题是线程是重物。每个打开的 .net 线程占用 1MB 内存，还需要开始思考多线程范式。

2. 否

3. 否

4. 没有异步，你别无选择