Newtonsoft JSON Deserialize Dictionary as Key/Value List from Datacontractjsonserializer

Local Inter-process Communication via TCP Sockets in C#

You are using the wrong constructor.

TcpClient(IPEndPoint)

Initializes a new instance of the TcpClient class and binds it to the specified local endpoint.

What you probably want is this:

TcpClient(String, Int32)

Initializes a new instance of the TcpClient class and connects to the specified port on the specified host.

See TcpClient constructors

Some knowledge: A client needs a free port too. Normally it will binds to a random free port. For a local connection are two sockets required - one for the client and one for the server.

What's the fastest IPC method for a .NET Program?

Named pipes would be the fastest method, but it only works for communication between processes on the same computer. Named pipes communication doesn't go all the way down the network stack (because it only works for communication on the same computer) so it will always be faster.

Anonymous Pipes may only be used on the local machine. However, Named Pipes may traverse the network.

I left out Shared Memory since you specifically mentioned that you don't want to go that route. Shared Memory would be even faster than named pipes tho.

So it depends if you only need to communicate between processes on the same computer or different computers. Any XML-based communication protocol (eg. Web Services) will usually be slower due to the massive overhead in XML.

Communicate between 2 processes

You have several options:

Using WCF will allow you to switch between bindings easily. So if you have two processes on the same machine you can use a named pipe binding which is a type of inter-process communication. If you later decide to separate processes onto different machines you can just change configuration to, say, tcp binding and everything will continue working
If you are into REST, there will be client-server frameworks, such as as self-hosted ASP NET Web API or Nancy
If it is something dead simple, you can just write to a file and read from a file, combined with a global named mutex to synchronise access
There is also a choice of a memory-mapped file, where one process writes to a file and the other reads from it. It's a bit geeky approach and I have rarely seen this in use.
Or yet another conventional approach is to use a 3-rd party, such as a database or a message queue system

What is the best choice for .NET inter-process communication?

WCF is the best choice. It supports a number of different transport mechanisms (including Named Pipes) and can be completely configuration driven. I would highly recommend that you take a look at WCF.

Here is a blog that does a WCF vs Remoting performance comparison.

A quote from the blog:

The WCF and .NET Remoting are really comparable in performance. The differences are so small (measuring client latency) that it does not matter which one is a bit faster. WCF though has much better server throughput than .NET Remoting. If I would start completely new project I would chose the WCF. Anyway the WCF does much more than Remoting and for all those features I love it.

MSDN Section for WCF

Inter-Process communication options

Named pipes are one of the fastest way to do IPC (inter-process communication) on the same machine. The have existed for a long while (was NT4 the first OS?) and not specific for WCF.

I would however not use WCF/Named pipes through ASP.NET as IIS do not use named pipes for it's communication. that means that your app will close if IIS have not received HTTP requests for a while.

How you should host your IPC depends on the type of application. If you want to always have your server running you should host it in a windows service. Otherwise you could just include it in your desktop app.

You do not necessarily have to use WCF, you can use named pipes directly (look at the link in the beginning of my message). It all depends on how complex your communication is.