C# Windws Server 2008中奇怪的套接字行为

很久以前，我使用这段代码的原理制作了一个基于套接字的服务器应用程序（IP地址和端口常量仅用于测试）：

多年来，它一直运行良好，直到最近，一位客户在Windows Server 2008计算机上安装了该服务，并试图从另一个网络（即通过一个或多个路由器）连接到该服务

令人惊讶的是，这是不可能的

进一步的分析表明，根本原因是在我的服务的所有回复数据包中，TTL（IP数据包头中的生存时间参数）被设置为1，从而导致它们在遇到的第一个路由器上被丢弃

有趣的是，如果我删除SetSocketOption（…）调用，TTL就会回到通常的128

这种奇怪的行为似乎只适用于Windows Server 2008。Windows XP和Windows 7都保持TTL=128，正如我所期望的那样。我看不出有任何理由要用“ReuseAddress”选项来更改TTL。有人能解释一下吗

我还可以通过在第一个调用之后添加第二个SetSocketOption（…）调用将TTL恢复到128：

_MainSocket.SetSocketOption( SocketOptionLevel.IP,
                             SocketOptionName.DontRoute, 0).

这有效地抵消了第一次SetLockeToption（..）调用的不必要的副作用

请告诉我在这件事上我似乎不明白什么

---

Martin.

发布在MSDN页面上的关于

SocketOptionName

的这则广告似乎有些启发性，尽管我还没有证实：

用.NET阅读.NET Framework源代码时的误解 反射器使用红门的.NET反射器来解码.NET中的类套接字 框架v2.0

为什么那是ReuseAddress而不是IPTimeOlive

事实上：

SocketOptionName.IpTimeToLive==SocketOptionName.ReuseAddress==4

---

如果是这样的话，那就可以解释为什么

TTL

被设置为

1

——这就是你传递给

ReuseAddress

的值，你看起来很合适！事实上，IpTimeToLive和ReuseAddress的值都是4。但是，为了使系统将4解释为ReuseAddress，必须使用SocketOptionLevel.Socket-如果他使用SocketOptionLevel.IP，那么它被称为IpTimeToLive！结论：我犯了一个编程错误，MS做得很好（幸运！）。

_MainSocket.SetSocketOption( SocketOptionLevel.IP,
                             SocketOptionName.DontRoute, 0).