I'm a Jr. Engineer hoping to seek some advice from all of the experienced people in here in regards to how to approach this.
I've been assigned a project to create a server/client application that does byte streaming through TCP. Our company deals with 2-way radios with GPS with a dispatch software and we would like to make a server/client application out of that. Currently the dispatch software can be hooked up to a central base station where a user has to be, but we want to make this software accessible from a remote location (if the base station is by a repeater miles away from where a dispatcher can be at).
User/Client -> poll location of a mic -> server -> base station -> OTA signal -> radio and back
I've been looking at Windows Communication Foundation, but what are other ways I can approach this?
I'll be primarily using C# / .NET / Visual Studio 2008Answer1:
We have used UDP to send GPS updates from cars to a server that processes the updates. In applications like that (where you often have limited bandwidth) you can really tell the difference (in terms of how long it takes to get the data from the remote host to the server) between UDP and momentary TCP connections (like HTTP). A UDP packet will get to its destination in what seems like an instant, and the setup for the TCP connection is very conspicuous, often taking several seconds to complete. I like the WCF framework, but if your app is the sort of system I've been working with, I doubt you'll be happy with it (...unless it's OK to have a long interval between updates).
Lately, I've been working with persistent TCP connections (using raw Sockets), which is a good way to go if you want to make sure your packets arrive at their destination. Though the way to do that, I believe, is to leave the connection open as long as you can and incorporate code to reconnect it if it breaks.Answer2:
If you just want a raw byte stream, then a <a href="http://msdn.microsoft.com/en-us/library/system.net.sockets.socket.aspx" rel="nofollow">
Socket</a> or the slightly more encapsulated <a href="http://msdn.microsoft.com/en-us/library/system.net.sockets.tcpclient.aspx" rel="nofollow">
TcpClient</a> might be a more light weight solution.
But if you want to send complete data structures and "call functions" then WCF seems like a good choice.
With WCF you have a programming experience close to calling regular methods with real objects as parameters, but with a
Socket you just send byte arrays and need to interpret the result all by your self.