使用 WCF 替换 TCP/IP 管道
目前我的公司正在使用 TCP/IP 连接在服务器和客户端程序之间进行通信，现在我们正在使用 System.RunTime.Remoting 构建此连接，这很笨重且不那么可靠。它是大约 5 年前构建的，该模型不断被重用，并且开始传播一些问题、使用的端口、拒绝连接等。
我正在尝试找到一些有关如何将其更改为 WCF 的资源，但我没有非常确定我在寻找什么或我应该寻找什么。
如果您想了解更多关于实际使用它做什么的信息，我可以详细介绍，但我需要提取代码并确保我对其进行了完整解释。
谢谢！
So currently my company is using a TCP/IP connection to talk between server and client programs, right now we are building this connection using System.RunTime.Remoting, which is clunky and not that reliable. It was built about 5 years ago and the model keeps getting reused and it's starting to propagate some issues, ports used, refused connections, etc.
I'm trying to find some resources on how to change this over to WCF but I'm not really sure what I am looking for or what I should be searching.
If you want some more information on what were actually doing with it I can go into some detail, but I'll need to pull up the code and make sure I explain it completely.
thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Mikael 已经在他的帖子中触及了大部分相关要点 - 选择
netTcpBinding，它速度相当快，在 LAN 环境中工作得非常好，并且具有您应该需要的所有功能。主要区别在于思维方式的改变：在远程处理中，您基本上是在使用“远程对象”——您或多或少地远程控制另一台计算机上现有的 .NET 对象。
从根本上讲，WCF 非常不同：您有一个服务器和一个客户端，它们除了服务契约（方法的描述）和数据契约（所传递的数据的描述）之外不共享更多内容。在运行时，您对客户端上的代理进行调用，WCF 运行时拦截该调用，将其序列化（包括所有参数），然后发送序列化消息（在
netTcpBinding的情况下为二进制序列化）通过电线。另一端的服务器有一个运行时组件，它监听这些消息并从网络中获取它们，解开它们，然后调用服务实例来运行您想要的方法。
重要的部分是：它是一个基于消息的系统 - 除了契约（服务接口和以 XML 模式表示的数据结构）之外，在运行时两者之间没有连接派对。
这也意味着：服务器无法“返回”客户端并查找某些内容或询问更多信息。该服务必须处理的只是消息以及您（或 WCF 运行时）可能发送的任何潜在消息标头。就是这样。
另外：由于数据交换通过序列化消息并且需要符合 XML 模式标准，因此您不能使用接口或泛型之类的东西 - 您只能传递类的具体实例。
总而言之，WCF 确实在某种程度上取代了 .NET 远程处理，但在某些方面，它是一个完全不同的野兽。这有优点和缺点，但你只需要意识到这些差异，不要试图对抗它们 - 要么你可以安排自己接受这些差异并从中受益，要么不要在你的工作中使用 WCF手。
Mikael already touched on most of the relevant points in his post - pick the
netTcpBindingwhich is quite fast, works extremely well in a LAN environment, and has all the features you should need.The main difference is going to be a change in mindset: in remoting, you're basically working with "remote objects" - you more or less remote-control existing .NET objects on another machine.
WCF is very different, fundamentally: you have a server and a client, and they don't share more than the service contract (description of methods) and the data contracts (description of the data being passed around). At runtime, you make a call to a proxy on the client, the WCF runtime intercepts that call, serializes it (including all parameters) and then send a serialized message (binary serialized in the case of
netTcpBinding) over the wire.The server on the other end has a runtime component which listens for these messages and grabs them off the wire, unwraps them, and then makes a call to the service instance to run that method you wanted.
The important part is: it's a message-based system - besides the contracts (service interface and data structures expressed in XML schema), you have no connection at runtime between the two parties.
Which also means: there is no way for the server to "reach back" to the client and find something out or ask for more information. All the service has to work with is the message and any potential message headers you (or the WCF runtime) might have sent along. That's it.
Also: since the data exchange goes through serialized messages and needs to conform to XML schema standards, you cannot use things like interfaces or generics - you can only pass around concrete instances of classes.
So all in all - WCF does in some way replace .NET remoting - but in some ways, it's quite a different beast. This has pros and cons, but you just need to be aware of those differences and don't try to fight against them - either you can arrange yourself with those and benefit from them even, or then don't use WCF for your jobs at hand.
有一篇古老但很好的文章，名为“将 .NET Remoting 迁移到 WCF（甚至 ASMX！）"，您应该看一下。
我自己已经做了很多远程处理，并且在封闭的环境中我仍然认为它有它的位置。特别是当关注速度时。 （我不得不有点不同意远程处理不可靠的说法。对于 LAN 通信，我根本没有遇到任何问题。）
我更喜欢 WCF 的是，您必须创建代理对象，然后运行调用。您可以更轻松地看到您正在进行远程调用。在我看来，远程处理在某种程度上隐藏了这一点。
需要注意的一件事是，通过 WCF 设置事件比通过远程设置事件要做更多的工作，但这只是一个很小的代价。一旦您了解了 WCF 以及如何针对您的特定场景对其进行最佳配置，您就不会再回头了。它比远程处理更灵活，并且可以在更大的距离上使用，而远程处理不太擅长（根据我的经验）。
请务必在 WCF 中选择适合您需要的传输通道，即 tcp、命名管道或肥皂。
There's an old, but good article called "Migrating .NET Remoting to WCF (and even ASMX!)" which you should take a look at.
I've done plenty of remoting myself, and in closed environments I still think it has it's place. Specially when speed is of concern. (I have to somewhat disagree that remoting is unreliable. For LAN communication I've had no issue at all.)
What I like more with WCF is that you have to create your proxy object, and then run the calls. You can much more easily see that you are doing a remote call. Remoting somewhat hides this imo.
One thing to note is that it's more work to set up events over WCF than it is to do it over remoting, but that's a small price to pay. Once you get to know WCF and how to configure it optimally for your particular scenario, you will not go back. It's much more flexible than remoting, and can be used over bigger distances, which remoting is not too good at (from my experience).
Be sure to pick a transport channel in WCF for your need, that be tcp, named pipes or soap.