.NET Datagram（数据报）Socket 潜在停止收取数据的疑难故障问题。

UDP socket 属于数据报类型的 “套接字” 该问题，自然也存在上述提到的疑难故障问题，通常一个 UDP socket 持续一天及以上频繁不停的收取 “数据报” 数据，就会出现奇葩的 “ReceiveFrom” 失效，再也收不到任何数据的问题，在.NET的基础上要解决这个问题的办法只有一种，关掉该 Socket 重新实例化一个新的 Socket 以后，即可正确恢复工作。

该问题覆盖到 “.NET Core”、“.NET Framework”、“.NET Standard” 等，至今未被 Microsoft 进行修复，大家都懂的，Microsoft 的东西最终还是要靠，技术人员自己动手来解决，就像人们要深入研究 Microsoft 那套东西，“逆向工程” 是必须要介入的，否则在 Microsoft 提供的东西上面，你很难办成事情。

该问题表现为 “Socket” 一直阻塞在 ReceiveFrom，但 Socket 是未被释放且正常就绪工作的，Microsoft 底层实现是基于 recvmsg 函数的，注意：检索CLR的 C/C++ 函数实现，它被封装为 InternalCall 内部调用，由 .NET 框架进行调用，而不是人们，所设想的基于 P/Invoke Call。

.NET Framework and .NET CLR 2.0 可以参考：sscli2.0

.NET Framework and .NET CLR 4.0 可以参考：sscli4.0

.NET Core and .NET Core CLR 可以参考：.NET Core CLR（GitHub）

上述提出：均未解决本文提出的问题。

总的来说：

Windows 兼容性来说 .NET Core CLR 非常不行，除非程序经过 "ilc" native build（linux为clang++、win64为VC++）编译以后，否则 P/Invoke 调用某些DLL库文件，.NET Core CLR 会无征兆直接崩溃（即程序闪退），当然，本文不是在批评 .NET Core CLR 好不好的问题。

类似频繁调用的 Network IO 接口函数，InternalCall 效率会比 P/Invoke Call，好很多，因为大家都知道 P/Invoke Call 要想调用速度起飞，那需要注意很多东西，否则一次 P/Invoke Call 调用CPU负载功耗就会非常昂贵，P/Invoke Call 虽然性能要好过COM调用很多，并不意味着就能赶上 C/C++ DLL函数调用性能，它需要人们进行更多的优化。

本文提出的问题只有以下一个解决方案：

由C/C++ 语言编写一套新的 UDP socket 动态链接库，来替代 .NET 微软提供的官方 Socket 实现的 UDP socket，没有其它办法。

但人们需要极度注意一个东西，如果我们要在 .NET 程序上面附着 C/C++ 程序来处理 UDP socket，不要通过 recvfrom、recv 等函数来实现，建议只通过 recvmsg/sendmsg C函数，正确封装来实现类似的功能，.NET Socket 仍可重叠使用，只要确保让发送/收取两个函数由C函数来实现就可以，自然 P/Invoke Call 调用性能优化是需要非常注意的，否则网络I/O带宽吞吐性能上不去就不要怪别人了。

如果人们套用 “recvfrom” 来收发报文，在不同的 Windows 发行版操作系统上面，或者 “Linux” 发行操作系统上面会存在很大的差异，有些系统可以正确收发 “数据报”，但有些系统 “recvfrom” 讲一直阻塞，根据网卡捕包，人们可以清晰可见，UDP侦听端口上面在流通流量，但 .NET 程序没有办法收到任何 “数据报消息”。

我曾经花费过不少时间研究过该问题如何解决，最终是暂时放弃，因为没有找到其它更好的办法来解决这个问题。