在.Net Remoting 中，“.NET Remoting Framework”具体是什么或在哪里？
In .Net Remoting, what or where specifically is the ".NET Remoting Framework"?
tl;博士:
我正在尝试查找 .Net Remoting Framework 运行 的位置（例如，服务名称或进程名称）。此外，来源将是惊人的。
上下文：
我正在维护使用 .Net 远程处理的遗留代码，以允许使用在两个进程之间存储连接信息的对象，并且长期以来一直存在随机断开连接和崩溃的问题，显然是由于那些远程处理对象超时。 this post 的回答中提到了我们看到的问题，特别是位：
My issue was using the Marshal to register the remoting object. Over time the remoting object will disappear for clients to consume, i.e. no longer on the remoting object.
我们过去使用的 'fixing' 方法是 post 中提到的方法：return 使用空租用管理器，它使对象永远保持活动状态，以便以避免随机不需要的超时。
几年前，该代码已被删除，因为它在 Linux 上引起了问题 - 基本上，每个连接在有用后保持活动状态都会消耗一个套接字，并且由于套接字是 [= 上的文件57=]，我们 运行 没有文件描述符。由于我们认为受超时问题影响最大的功能已被弃用，因此我们恢复了常规超时，并且在两年内一切正常。
然而，最近 Windows 的最新补丁或一些其他环境变化似乎导致不必要的超时问题在我们的某些机器上全面恢复（仅在 Windows 上; Mono 似乎可以很好地处理这个工作流程，让我强烈预感这是一个 .Net 错误）。具体来说，任何时候我们在另一个客户端保持连接约 5 小时或更长时间后尝试连接新客户端时，进程都会挂起尝试连接到 TCP 端口，如果我理解正确的话，这就是远程处理框架告诉我们的是我们的服务器监听的地方。
因为这削弱了我们的 Windows 使用，导致这个缺陷最终得到了正确解决的推动，我现在想弄清楚的是为什么，经过一段时间后 ~5来自一个客户端的持续连接数小时，我们不再能够从新的客户端进程到服务器建立远程连接。但首先，为了做到这一点，我想了解整个工作流程，其中包括了解 .Net Remoting Framework 中发生了什么，该框架存储了首先要创建的远程连接所需的信息。然而，我读过的所有内容都只是顺便提到了框架，并没有解释它到底是什么。
问题：
Many different(PDF warning) articles 在 .Net 远程处理上将“.Net Remoting Framework”称为关键部分，它存储有关使用 RemotingServices.Marshal 或 RemotingServices.RegisterWellKnownSericeType 注册的对象的信息。如果我理解正确，它会允许其他客户端 .Net 进程使用两个进程都知道为键的 URI 查询这些对象。
被查询的进程或服务在哪里？老实说，即使答案是我在文档中明确提到的不知何故错过的东西，我也会因为拥有它而欣喜若狂。谢谢！
（此外，当然，任何对我的更大问题的额外见解将不胜感激。）
编辑：'greater problem' 似乎是我们 运行ning 的安全软件程序干扰了我们工作机器中的网络适配器，有时会导致 System.Net.Sockets.SocketExceptions 在我们的远程处理程序尝试通过这些套接字进行连接时发生。这意味着当 LeaseManager 去检查租约是否仍在为 RemotingObject 工作时，它会看到套接字错误并反射性地认为租约已断开连接，因此删除我们希望保持活动状态的对象引用。我们的方法是 return InitializeLifetimeService 函数为 returning null，并使用 Dispose 模式自行处理所有对象垃圾回收。完整描述是 here.
它运行在 配置部分中定义主机的任何应用程序，可以是 IIS、Windows 服务或控制台应用程序。客户端应用程序也需要进行一些配置，以告诉它 class 实际上是远程主机的代理。
远程处理中使用的类型在 Sytem.Runtime.Remoting 命名空间中。
我从未使用过让对象代理保持活动状态数小时的远程处理；我想你通常会想要一个新的，使用它，然后丢弃它。如果那不可能，请检查模式。 SingleCall 可能是最好的选择，因为在主机端会为每个远程请求创建一个新对象，并在完成后销毁。如果编码不正确，寿命较长的对象可能会有一些陈旧的状态，或者可能存在内存泄漏或其他问题。
我们仍然为 ClickOnce 智能客户端使用远程处理，我们没有您遇到的超时问题，但我们的远程处理仅针对 SingleCall 配置。
来自 link，这将是托管应用程序中的配置：
<configuration>
<system.runtime.remoting>
<application>
<service>
<wellknown mode="SingleCall" type="Hello.HelloService, Hello"
objectUri="HelloService.soap" />
</service>
</application>
</system.runtime.remoting>
</configuration>
在客户端上：
<configuration>
<system.runtime.remoting>
<application>
<client>
<wellknown type="Hello.HelloService, Hello"
url="http://localhost:8000/HelloService.soap" />
</client>
</application>
</system.runtime.remoting>
</configuration>
tl;博士:
我正在尝试查找 .Net Remoting Framework 运行 的位置（例如，服务名称或进程名称）。此外，来源将是惊人的。
上下文：
我正在维护使用 .Net 远程处理的遗留代码，以允许使用在两个进程之间存储连接信息的对象，并且长期以来一直存在随机断开连接和崩溃的问题，显然是由于那些远程处理对象超时。 this post 的回答中提到了我们看到的问题，特别是位：
My issue was using the Marshal to register the remoting object. Over time the remoting object will disappear for clients to consume, i.e. no longer on the remoting object.
我们过去使用的 'fixing' 方法是 post 中提到的方法：return 使用空租用管理器，它使对象永远保持活动状态，以便以避免随机不需要的超时。
几年前，该代码已被删除，因为它在 Linux 上引起了问题 - 基本上，每个连接在有用后保持活动状态都会消耗一个套接字，并且由于套接字是 [= 上的文件57=]，我们 运行 没有文件描述符。由于我们认为受超时问题影响最大的功能已被弃用，因此我们恢复了常规超时，并且在两年内一切正常。
然而，最近 Windows 的最新补丁或一些其他环境变化似乎导致不必要的超时问题在我们的某些机器上全面恢复（仅在 Windows 上; Mono 似乎可以很好地处理这个工作流程，让我强烈预感这是一个 .Net 错误）。具体来说，任何时候我们在另一个客户端保持连接约 5 小时或更长时间后尝试连接新客户端时，进程都会挂起尝试连接到 TCP 端口，如果我理解正确的话，这就是远程处理框架告诉我们的是我们的服务器监听的地方。
因为这削弱了我们的 Windows 使用，导致这个缺陷最终得到了正确解决的推动，我现在想弄清楚的是为什么，经过一段时间后 ~5来自一个客户端的持续连接数小时，我们不再能够从新的客户端进程到服务器建立远程连接。但首先，为了做到这一点，我想了解整个工作流程，其中包括了解 .Net Remoting Framework 中发生了什么，该框架存储了首先要创建的远程连接所需的信息。然而，我读过的所有内容都只是顺便提到了框架，并没有解释它到底是什么。
问题：
Many different(PDF warning) articles 在 .Net 远程处理上将“.Net Remoting Framework”称为关键部分，它存储有关使用 RemotingServices.Marshal 或 RemotingServices.RegisterWellKnownSericeType 注册的对象的信息。如果我理解正确，它会允许其他客户端 .Net 进程使用两个进程都知道为键的 URI 查询这些对象。
被查询的进程或服务在哪里？老实说，即使答案是我在文档中明确提到的不知何故错过的东西，我也会因为拥有它而欣喜若狂。谢谢！
（此外，当然，任何对我的更大问题的额外见解将不胜感激。）
编辑：'greater problem' 似乎是我们 运行ning 的安全软件程序干扰了我们工作机器中的网络适配器，有时会导致 System.Net.Sockets.SocketExceptions 在我们的远程处理程序尝试通过这些套接字进行连接时发生。这意味着当 LeaseManager 去检查租约是否仍在为 RemotingObject 工作时，它会看到套接字错误并反射性地认为租约已断开连接，因此删除我们希望保持活动状态的对象引用。我们的方法是 return InitializeLifetimeService 函数为 returning null，并使用 Dispose 模式自行处理所有对象垃圾回收。完整描述是 here.
它运行在 配置部分中定义主机的任何应用程序，可以是 IIS、Windows 服务或控制台应用程序。客户端应用程序也需要进行一些配置，以告诉它 class 实际上是远程主机的代理。
远程处理中使用的类型在 Sytem.Runtime.Remoting 命名空间中。
我从未使用过让对象代理保持活动状态数小时的远程处理；我想你通常会想要一个新的，使用它，然后丢弃它。如果那不可能，请检查模式。 SingleCall 可能是最好的选择，因为在主机端会为每个远程请求创建一个新对象，并在完成后销毁。如果编码不正确，寿命较长的对象可能会有一些陈旧的状态，或者可能存在内存泄漏或其他问题。
我们仍然为 ClickOnce 智能客户端使用远程处理，我们没有您遇到的超时问题，但我们的远程处理仅针对 SingleCall 配置。
来自 link，这将是托管应用程序中的配置：
<configuration>
<system.runtime.remoting>
<application>
<service>
<wellknown mode="SingleCall" type="Hello.HelloService, Hello"
objectUri="HelloService.soap" />
</service>
</application>
</system.runtime.remoting>
</configuration>
在客户端上：
<configuration>
<system.runtime.remoting>
<application>
<client>
<wellknown type="Hello.HelloService, Hello"
url="http://localhost:8000/HelloService.soap" />
</client>
</application>
</system.runtime.remoting>
</configuration>