CODEWITHSUNDEEP
c#.netvisual-c++
mauzinister
mauzinister

Reputation: 41

Real time communication

I have the same dilemma as the one who posted this topic, Real-time communication with WCF except that my problem is not about games programming. I would like to know what's the best method to use to be able to have a real time communication in between two windows applications (server-client). I am using visual c++/c# to date and i would like to be able to display all the Feeds that are being received by my server to the client in real time.

I have started trying to use .NET remoting but in my continuous research, it appears that it will use SOAP-http, and might affect the speed of the communication. My server and client will communicate using the internet and .NET remoting does not permit the use of TCP Channel when communicating in between a firewall or the internet.

Your inputs will be greatly appreciated.

Upvotes: 3

Views: 2308

Answers (2)

BradleyDotNET
BradleyDotNET

Reputation: 61349

If you are willing to do your own message parsing, you can use standard TCP sockets with the TcpClient and TcpListener classes. If your data is already a serializable object, you could serialize it into a text stream and just send it over the socket, deserializing it on the client side.

To get it to work over the internet, the server needs to have the port forwarded on your router, the client would just attach to the server's public IP. You would obviously need to add an exception in your firewall for this port as well.

The biggest problem with WCF and large data is setting up the streaming, by default WCF sends everything at once, which isn't practical for large files.

Upvotes: 0

Jorge Alvarado
Jorge Alvarado

Reputation: 2674

I guess it depends on your escenario, if you want "real-time" and you are willing to lose some packages in the process you are better with UDP, take a video conferencing tool for example, by the time you recover your slow packages you will have to move and display the next frame in the video or audio; that is a good example for the use of UDP. This is the reason why UDP is much faster than TCP.

If however, you are not willing to lose a single bit of your message, then TCP was made for you because if you lost a package the protocol will request it again to have your complete message as complete as possible.

Additionally it depends on the way the communication is being sustained, is the information flowing from one to many?, from many to many?, one to tone?

Take NetNamedPipeBinding for instance, this will be much faster process, but is only deployed in a single machine but accross processes. Whereas NetMsmqBinding will help you to build queues and it will be amazingly reliable and scalable for scenarios where your load will be a massive number of connections.

In the end, it all boils down to your concrete escenario and your business goals.

Hope it helps

Upvotes: 2

Related Questions