tcp - winsock2:如果套接字已死，则 send() 失败 [不是真的]

Question

在已经被客户端丢弃的 TCP 套接字上调用 send() 会导致内存访问冲突，因为当我运行我创建的服务器应用程序然后用来自浏览器的请求轰炸它时，它崩溃了在处理大约 7 到 11 个请求之后。具体来说，它接受连接，然后最多等待 10 秒左右，然后 Windows 抛出“此程序已停止工作...”消息。如果我删除 send() 调用，则不会发生此类崩溃，这使我相信 Microsoft 的 send() 不能安全地处理从另一端关闭的套接字。

我知道有多种方法可以检查套接字是否实际上已关闭，但我不想先检查再发送，因为客户端仍有可能在检查和发送之间中断。

---

编辑:我注意到close() socket directly after send(): unsafe?在“类似问题”框中，虽然它不太适合我的情况，但我现在想知道是否在 send() 之后快速调用 close() 可能是导致问题的原因。

如果是这种情况，涉及检查然后关闭的解决方案将起作用，因为它没有上述含义。但是，我不知道如何检查 closesocket() 是否安全。

---

编辑:我也希望有一种方法可以检测 send() 实际上已损坏并防止整个应用程序崩溃。

---

编辑:我想我终于更新了这个问题，考虑到我不久前就发现了这个问题，而且可能会有好奇的人偶然发现这个问题。事实证明，该问题与 send 函数或与套接字相关的任何其他内容无关。事实上，这个问题是我正在做的一件非常愚蠢的事情:在无效指针(NULL 和类似的垃圾数据地址)上调用 free。几年前，我终于从我最初使用的一个非常过时的版本更新了我的编译器，我想非常过时的标准库实现让我能够摆脱这种令人畏惧的做法，而且看起来什么我认为 send 的问题是它的副作用。

Answer 1

我已经在 WinSock 中编程十多年了，从未见过或听说过 send() 会在失败时抛出异常(事实上，没有任何 Win32 API 函数会在失败时抛出异常) .如果套接字已关闭，则会报告相应的错误代码。所以您的代码中发生了其他事情。也许您传递给 buf 参数的指针未指向有效的内存块，或者您传递给 len 参数的值超出了 的范围>buf.