I am using TCPClient
and TCPListener
to send data between to applications running on the same computer. I am targetting Framework 4.5 so the applications run on Windows Vista SP2 and upwards if I'm not mistaken.
I am using very simple code for this:
Client:
Try
Using c = New Net.Sockets.TcpClient()
c.Connect("localhost", 7643)
If c.Connected Then
Dim Specs As New List(Of Spectrum)
' Generating some data here to send
Using stream = c.GetStream
Dim xml As New Xml.Serialization.XmlSerializer(GetType(List(Of Spectrum)))
xml.Serialize(stream, specs)
End Using
End If
End Using
Catch sEx As Net.Sockets.SocketException
MessageBox.Show("Could not send the data." & vbCrLf & _
"This can have multiple reasons:" & vbCrLf & _
"(i) The receiver is not running" & vbCrLf & _
"(ii) A firewall is blocking the connection")
Catch ex As Exception
MessageBox.Show("An unexpected exception occured while sending the data: " & vbCrLf & _
ex.Message)
End Try
Server:
Private Async Sub DoListen()
Do
Dim client = Await datagrabber.AcceptTcpClientAsync
If client IsNot Nothing AndAlso client.Connected Then
Dim t = Task.Run(Sub() HandleClient(client, Date.Now))
End If
Loop
End Sub
Private Sub HandleClient(client As Net.Sockets.TcpClient)
Dim specs As New List(Of RelaxIS_Shared.CSSpectrum)
Using stream = client.GetStream
Dim ser As New System.Xml.Serialization.XmlSerializer(GetType(List(Of RelaxIS_Shared.CSSpectrum)))
specs = CType(ser.Deserialize(stream), List(Of RelaxIS_Shared.CSSpectrum))
client.Close()
End Using
' Do stuff with data
End Sub
This works well, but I started wondering if that is really a clever way to send data between applications. For example does this always work on a modern Windows machine or what if the computer in question does not have a network card? Are TCP connections somehow virtualized to work on the localhost IP, regardless of actual hardware in the system?
I found a lot of information about multiple network cards but really nothing about no network cards.
I already tried deactivating all network cards in Windows. In this case it still worked, but is that always the case or can there be a hardware/software configuration that does not allow the use of TCPClient connections?
I like the principle because it works very smoothly and way less clunky than say sharing files for example. I am not experienced in stuff like the Windows Communication Framework and therefore stuck to methods I knew first.
Both answers in C# or VB.NET are very much appreciated, if code is neccessary.
A short update: Based on usr's accepted answer below I have implemented the communication using named pipes. It is basically the same code, it's working flawlessly and definitely worth a look for anyone who may find himself in the same position as me. You cannot run into problems with firewalls as well, which are especially rampant on business PCs.
And one more update: usr was even more right. Named pipes are well and good, but it is more than worth it to read up on WCF. It may seem overwhelming at first, but implementing a small data transfer interface between your applications is very brief and easy. And it goes many miles to be able to just "call a method in the other application" once it's up and running. No type conversions, no serializing data on your end in any way...it's great and worth the learning curve.
TCP always works for local connections. These are called loopback connections. You do not need to plug an Ethernet cable two times into your computer to get it to talk to itself...
For local-only communications named pipes are a nice alternative. They are simpler and a little faster. .NET supports them well.
If possible abandon TCP and any other stream-based interface. Use a higher-level RPC mechanism such as .NET remoting (very simple, works over named pipes) or WCF. WCF does not need a website project to be hosted in.
Basically, anything is better than writing an RPC mechanism yourself.