WCF vs .NET Remoting vs Socket Programming - Which one to use? RRS feed

  • Question

  • What is the difference .NET Remoting and Socket Programming? Are they the same?

    A desktop application on a Client Machine should have consistant knowledge about the status of an application on the Server.

    Proposed solutions:

    1. WCF:
    I can't use WCF I think since we have only .NET 2.0 on the Client machines which requires basicHttpBinding, so we can't use its Duplex feature. We also don't want to use Polling.

    2. .NET Remoting:
    possible option

    3. Using Sockets
    possible solution

    Any thoughts which one is the best?

    Wednesday, September 16, 2009 1:27 PM

All replies

  • .Net remoting uses TCP IP protocol and is best opted when clients is on .Net platform
    .NET Remoting is built on Socket programming.
    Sockets are lower level; you might get slightly better performance, but at the cost of lot of manual implementation.
    Remoting is a higher layer on Sockets and provides lot of functionality like serialization, etc. out of box.
    Remoting is getting Obsolete with WCF Services.


    Wednesday, September 16, 2009 1:41 PM
  • Thanks Sudhanshu,

    So, netTcpBinding provides a stateful communication?

    If yes,

    My client application only supports .NET 2.0, is it possible to use this service from a .NET 2.0 machine? or it must have .NET 3.5?
    Wednesday, September 16, 2009 1:56 PM
  • netTCPBinding supports stateful communication.
    You can consume it in .Net 2.0 client

    p.s- kindly mark the thread complete if it solves the problem.

    Thursday, September 17, 2009 4:35 AM
  • As you mentioned earlier, stateful communication can be achieved by enabling Session for the service contract, so I think almost no matter what binding we use, it's fine.

    that's great if it does that but I seriously doubt; How do you configure netTcpBinding for a .net 2.0 client? (System.ServiceModel element can't be used in .NET 2.0)
    Thursday, September 17, 2009 6:46 AM
  • Hi
    If you are implementing Remoting for .Net 2.0 server and clients
    use  System.Runtime.Remoting and not System.ServiceModel

    Use System.Runtime.Remoting.Channels.Tcp for implementing TCP channel between client and server.

    System.ServiceModel is for WCF based Services and i dont think you are planning to use WCF services due to limitations earlier raised.

    hope this helps.
    Friday, September 18, 2009 6:45 AM
  • Thanks Sudhanshu,

    Yes, I am going to build it using .NET Remoting.

    I noticed that TCP Channel in .NET Remoting doesn't support bi-directional communication.

    I guess I have to create a custom TCP Channel which implements IChannelReceiver and IChannelSender; not sure how. Any idea?

    Friday, September 18, 2009 8:33 AM
  • Hi Dynamic,

    If you are planning to use TCP with single connection then Indigo might be your answer.

    There are sample which will be able to help you.

    Though you have remoting i would also suggest using Sockets will give the flexbility of building solution for your requirements

    .net provides System.Net.Sockets.

    Mark this as answer if this helps


    Sunday, September 20, 2009 3:14 PM
  • Finally, I chose Sockets and implemented the first phase of application; it wasn't that challenging.
    Tuesday, October 6, 2009 9:10 PM
  • How much performance gain can we expect out of using sockets compared to using remoting over TCP channel
    Tuesday, September 21, 2010 4:44 PM
  • Depends on what you're doing.

    Both use sockets to communicate but the do it yourself approach you wrote a process that runs on the remote server, listens on a port and handles data you send it.

    With remoting you're starting the process on the remote server from your machine but otherwise it's kind of similar.

    WCF is 99% likely to be your best option. 


    Wednesday, September 22, 2010 7:37 AM