C# byte streams through TCP

views:

108

answers:

+1 Q:

C# byte streams through TCP

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 2008

If you just want a raw byte stream, then a Socket or the slightly more encapsulated TcpClient 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.

Albin Sunnanbo 2010-09-14 17:11:05

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.

Pat Daburu 2010-09-14 17:18:09

If you are interested, here is a link to another post on the subject of using sockets: http://stackoverflow.com/questions/3609280/tcpclient-send-data-and-recieve-data-over-network/3609784#3609784

Pat Daburu 2010-09-14 17:30:30

Thanks for your reply. Is this also a good approach if I'm looking into handling multiple clients/connections at the same time? I tried working with threads in the server while forever listening for new clients, but I think it locks up in the infinite while loop. Any good reads on threads?

John H. 2010-09-14 17:43:24

I tend to think that this is a good way to handle multiple clients. Just as you mentioned, I spawn a thread for each new connection, though I haven't seen the lock up problem. In the other thread I posted some sample code with comments that I think is a reasonably good start on a server. That code doesn't create each new connection in its own thread, though one of my comments describes that. If you find any of that useful, I would be happy to answer any subsequent questions. Fortunately there are lots of articles on socket programming in C#...

Pat Daburu 2010-09-14 18:22:57

...like this one http://www.codeguru.com/csharp/csharp/cs_network/sockets/article.php/c7695

Pat Daburu 2010-09-14 18:24:01

Great examples, thank you sir.

John H. 2010-09-16 16:27:24

I have one more question: Is it possible to send a byte stream without pre-defining a byte buffer? Like I'm also using the COM ports/USB port for serial communication and there is a "BytesToRead." Is there something similar (that can be easily fit to your example) to do that? I have a 15 byte length so far, but there are certain frames in there are variable.

John H. 2010-09-22 21:57:38

I apologize for the delayed response. Assuming you haven't already come up with an answer, I'll take a stab here: I'm assuming (please let me know if I'm wrong) that the problem is if you use a 15 byte buffer, but get 17 bytes of data, you have a trouble. If that's so, one easy solution is just to use a byte buffer large enough to hold your largest message. Having said that, however, another option to consider would be to have a string buffer in addition to the byte buffer. It would go like this: each time you get bytes, you convert them to a string and add them to a StringBuilder...

Pat Daburu 2010-09-28 16:45:40

If your messages have control characters (like end-of-text) or if you can in any other way detect that you have a complete message, you can then just keep accepting bytes, putting the data into the StringBuilder until you know you have a complete one. Then you can get the StringBuilder's contents and process the full message. In this way, your messages can be arbitrarily large.

Pat Daburu 2010-09-28 16:46:22

ansaurus

tags:

views:

answers:

C# byte streams through TCP

related questions