C# Remoting / WCF Client Server app what comms technology to use

cremoting

I am after so advice really. I have been thinking about a client server project for a while and am going to be using .NET. Originally is was just going to use 2.0 but recently got VS2008 and thought I should really explore 3.5 as well.

The application will have one server and many clients connected. Both the client and the server will need to talk to each other, (i.e. two way comms). This will be running across the internet.

I was going to just use remoting for this but is there anything or any reason I should use a different approach with 3.5?

I realize I may have some problems with firewalls when ports could be blocked at the client when I use remoting.

Really I am looking for suggestions to be the best way to handle communications between a client and server that will work across the net using .NET (would like the client to be able to be running other languages as well really but that is not vital I guess). Both the client and the server must be able to call each others methods.

Thanks,

and merry Christmas.

Jon

Best Answer

I'm just starting out in WCF and have asked a few questions around this topic here on SO. Some things I've learned over the past week or so:

This article is excellent: MS Pub-Sub with WCF
WCF is the way to go. It's dynamic configuration and single programming model should make it your preferred choice over traditional web services or remoting.
Through configuration your WCF service can be exposed via a simple HTTP binding allowing it to consumed by traditional web services.

Related Solutions

C# – .NET Remoting – How to the Server update the client

I once deployed a system wich used remoting, and where the server launched some events to which the client could subscribe to.

In order to make it possible, you have to set the typeFilterLevel to full, and, you also have to create an 'intermediate' object that is known on the client and on the server in order to be able to handle your events.

For instance: This is the class that is known on the server & on the client side.

public abstract class MyDelegateObject : MarshalByRefObject
{
   public void EventHandlerCallback( object sender, EventArgs e )
   {
      EventHandlerCallbackCore(sender, e);
   }

   protected abstract void EventHandlerCallbackCore(object sender, EventArgs e );

   public override object InitializeLifetimeService() { return null; }
}

At the client-side, you create another class which inherits from the above class, and implements the actual logic that must be performed when the event is raised.

public class MyConcreteHandler : MyDelegateObject
{
   protected override EventHandlerCallbackCore(object sender, EventArgs e)
   {
       // do some stuff
   }
}

You simply attach the eventhandler to the event of the remote object like this:

MyConcreteHandler handler = new MyConcreteHandler();
myRemoteObject.MyEventOccured += new EventHandler(handler.EventHandlerCallback);

Offcourse, if you update Winform controls in your EventHandler class, that class should also implement ISynchronizeInvoke.

Wcf – .NET Remoting vs. Web Services vs. Windows Communication Foundation (WCF)

I actually switched our software from traditional .NET Remoting to WCF. The bloat in communication that occurred from Remoting was amazing (just look at a wireshark trace). Before moving to WCF i thought about using just a traditional .NET webservice, but the interfaces we implimented for our remoting calls would require to much modification (We had used some out and ref parameters which an Asp.Net webservice cant do if I am not mistaken).

Really, I cant think of a reason to go with an Asp.Net webservice, but Im not an Asp.Net guy. To me, it offers no advantages over WCF. It may be easier to go with a webservice, but the flexibility WCF offered was what I needed. Especially in the area of message formatting.

I like my WCF service because with one service I can either serve up JSON or SOAP/XML and all the protocols are supported (ipc, tcp, and http).

The bummer with WCF is that its strict bindings require you to define an endpoint for both HTTP and HTTPS if you wish to use it in a web based scenario. Unlike a traditional Webservice which "just works" regardless if its secure or not.

Related Topic