Replacing TCP/IP pipe with 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 startin开发者_开发百科g 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!

Mikael already touched on most of the relevant points in his post - pick the netTcpBinding which 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.

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.