我必须在 .NET 中编写 TCP/IP 客户端应用程序。 (服务器实际上是一个嵌入式设备，所以不关心它的服务器端。)
我想知道，与其使用异步套接字客户端读/写调用来保持我的主应用程序响应，为什么不使用后台工作程序并在该后台循环中使用同步调用？
它们将用于相同的目的，不，并且更易于编程和调试？
顺便说一句，我仅限于 .NET 3.5，因此不能使用 async/await 调用，这里的另一个线程( Async/await vs BackgroundWorker )似乎是每个人都建议使用的。
基于下面的许多有用的评论，我意识到在我上面的 OP 中应该更详细一点。
嵌入式设备是 Digi WiFi 模块 (http://www.digi.com/products/wireless-wired-embedded-solutions/zigbee-rf-modules/point-multipoint-rfmodules/xbee-wi-fi#overview)
我不是同时发送和接收。嵌入式设备连接我们的数据采集系统之一。 DAQ 接收命令并发出响应 - 一次只有一个命令/响应。
我向嵌入式设备发送命令。然后我等待回复。如果我得到响应，我会处理它，然后发送下一个命令。如果我在 x 秒内没有得到响应，那么我再次发送相同的命令。如果即使在 n 次尝试后我也没有得到响应，那么我认为连接已断开(可以这样做吗？然后显示错误消息并停止？关闭套接字连接并重新打开并重试几次？)
所以如果我的后台工作线程在接收/发送时阻塞是可以的。它要么发送要么接收，而不是两者。
最佳答案
我没用过BackgroundWorker我讨厌它。让我们忘记它并假设它是一个工作线程。
They would serve the same purpose, no, and easier to program and debug?
对于真正的异步方法，您忽略了异步 API there is no thread在它后面。 socket 的
BeginXXX和 EndXXX基于 IOCP .因此，使用异步方法不会浪费任何资源。在工作线程的情况下，您正在浪费一个线程(1mb 的堆栈，cpu 资源)，这不是一个好主意。如果一个操作本质上是异步的，那么同步等待它就是在浪费资源。
比同步更喜欢异步方法。
另外我不明白异步方法如何使调试变得困难。
关于.NET 异步套接字与后台 worker ，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/25206143/