How to use socket based client with WCF (net.tcp) service?

I have developed a WCF service that uses the net.tcp adapter and listens to a specific port. I want to connect to that service using a normal .net client that uses sockets to send data to the port and listens to responses.
When I try to send data to this service, I get the error: "The existing connection was forcibly closed by remote host".
However, i am able to connect with the service by another client which uses the Address/Binding/Contracts of the WCF service.
Is there a way that enables me to communicate with a WCF service by using an ordinary socket based client?

Solution 1:

The key decision is whether or not to make the WCF service conform to the socket client or whether to make the socket client conform to the WCF service.

It will be simplest to attempt to conform to the WCF service, rather than trying to implement something custom within WCF, which is never easy. At the bottom of the Other Resources section below you will see a link that describes the message inspection that is necessary in order to attempt to conform to a WCF service.

Having said that, .NET sockets do not natively communicate with WCF.

Any attempt to do so will require custom programming on the WCF side of things.

Whether you are using TcpClient or raw sockets in .NET to connect to and communicate with WCF does not matter. Any such interoperability must be handled with custom logic within WCF. Note that Net.Tcp is a custom transport protocol. It is not technically using TCP in the same way that the TcpClient is.

For example, UDP is very commonly used by socket servers in the Linux world. WCF does not provide a built-in UDP transport. However, there is a UDP sample for WCF that implements UDP for WCF. Unfortunately, that sample does not illustrate communicating to and from a non-WCF UPD socket server.

I have an outstanding question that is rather detailed where I explain my effort to get sample code to generically be testable for using UDP...

Is it possible to make the WcfTestClient work for custom transport channels?

Nobody has answered my question yet. So, if you succeed in making this work, I am very interested. My case was driven by a desire for the WCF Service to be able to call out to a UDP socket server running on Linux without having to clutter my service with non-WCF coding. I don't want to mix approaches.

Other Resources...

• Choosing a Transport
  This article states that "The WCF TCP transport is optimized for the scenario where both ends of the communication are using WCF".

  http://msdn.microsoft.com/en-us/library/ms733769.aspx

• Trying to connect a non-WCF client to a WCF service that uses the BasicHttpBinding.
  The developer ends up writing custom code via the WebClient (as opposed to TcpClient).
  
  http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/c2d72c2d-c095-4ae1-b8ae-d15f32a4e0be/

• WCF vs. Raw .NET Sockets
  The answer points out that TCP + binary serialization or UDP + binary serialization might be needed. There is a UDP binding sample, as I mentioned above.
  
  http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/c0520111-c1ca-4ffd-a4e0-ac68e86130ee/

• Writing Custom Requests to Simple WCF Services
  The author explains how to figure out the format of the message that needs to be sent to the service, so that the TcpClient or other non-WCF sockets client can send the write information to the WCF service. The implication here is that you are not attempting to conform the WCF service, but rather you are forcing the socket client to do the heavy lifting. Even so, you not get the built-in advantages of the WCF bindings if you are expecting that.
  
  http://blogs.msdn.com/carlosfigueira/archive/2008/01/13/writing-custom-requests-to-simple-wcf-services.aspx

Solution 2:

The Net.TCP binding uses a custom wire-level framing format that is not really documented, though Nicholas Allen started a series of blog posts on the topic recently. The series start here: http://blogs.msdn.com/drnick/archive/2009/01/19/message-framing-part-1.aspx

To be honest, Net.TCP is really, currently, more useful for WCF to WCF communication. if you want to interop with a custom TCP format that you need to handle, you're much better off either using raw sockets or creating your own custom WCF transport channel (which might not be trivial, btw)