.NET Asynchronous Sockets vs Background worker
I need to write a TCP / IP client application in .NET. (The server is actually an embedded device, so it doesn't touch the server side.)
I'm wondering, instead of using asynchronous socket read / write calls to maintain my main application, why not just use a background worker and use synchronous calls inside that background loop?
They will serve the same purpose, no, and are they easier to program and debug?
By the way, I'm limited to .NET 3.5, so can't use the async / await calls that are from another thread here ( Async / await vs BackgroundWorker ), it looks like everyone suggests using this instead.
Based on the many helpful comments below, I realize this was a little more detailed in my OP above.
The embedded device is a Digi WiFi module ( http://www.digi.com/products/wireless-wired-embedded-solutions/zigbee-rf-modules/point-multipoint-rfmodules/xbee-wi-fi#overview )
I am NOT sending and receiving at the same time. The embedded device is connected to one of our data collection systems. DAQ receives command and sends response - ONLY ONE command / response at a time.
I am sending a command to an embedded device. Then I wait for an answer. If I get a response, I will process it and then send the following command. If I don't get a response within x seconds, I will send the same command again. If I don't get a response even after n attempts, then I assume the connection is broken (ok to do it this way?) Then show an error message and stop? Close the socket connection and start again and try again a few times?)
So it's ok if the backgroundworker thread is blocking on receiving / sending. It's either sending or receiving, not both.
source to share
I'll go over what others are saying and suggest using the Begin / End methods. Using a different thread will probably achieve the same functionality, but why reinvent the wheel when you can use what's already built into the Framework?
My personal experience with Begin / End on sockets has been nothing short of good. I find it much easier to use than blocking calls because I don't have to worry about the application being responsive - .NET will take care of this for me. There is, of course, more work to tweak, but I think it scales much better than if you were using blocking calls. I also don't see how Begin / End is supposed to give you more trouble than using blocking versions of these calls.
Another thing you should be thinking about - and I need to wonder because you didn't specify - how do you plan to handle dispatches AND receives on the same background thread when any call blocks that thread? You will need to have two background threads unless your application / protocols are designed so that you know exactly when the application should send and when it should be received. And even then, with one thread, you will be limited to one of these operations at a time (since they will block).
source to share
I have never used BackgroundWorker
it and I hate it. Let's forget about that and assume it's a worker thread.
They will serve the same purpose, no and easier to program and debug?
You are ignoring async API s, there is no thread behind it for a true async method . Socket BeginXXX
and EndXXX
are based on IOCP . This way, you don't waste resources using asynchronous methods.
In the case of a worker thread, you lose a thread (1mb stack, cpu resource) which is not good. If the operation is inherently asynchronous, then waiting for it consumes resources synchronously on the resource.
Prefer asynchronous methods over synchronous.
Also I don't understand how async methods make it difficult to debug.
source to share
There is nothing wrong with using synchronous I / O. All this costs you 1MB of stack memory. If you're willing to spend that amount (and it's a small amount) and productivity is important to you, keep going.
I've written about this before. Weigh the pros and cons. These days Async is all anger. You pretty much won't find anyone on Stack Overflow recommending synchronous code. I find that compromise is often not rational.
source to share
I need to write a TCP / IP client application in .NET. (The server is actually an embedded device, so it doesn't touch the server side.)
First rule: try to increase the abstraction level of the protocol. WebSockets are infinitely preferred over raw TCP / IP.
If you absolutely need to use TCP / IP (i.e. the embedded device is off the shelf and their tech support doesn't want to support WebSockets) then be sure to check my TCP / IP.NET Networking FAQ.
I'm wondering, instead of using asynchronous socket read / write calls to maintain my main application, why not just use a background worker and use synchronous calls inside that background loop?
Depending on how reliable your application needs to be. 24x7 reliable systems (like industrial automation, one of my areas of expertise) definitely prefer asynchronous TCP / IP. This can be done using streams / BGW, but note that you need two streams per connection, not one. This is because you need to always read as well as write periodically.
There are some "simple" examples (I'm looking at you, MSDN) where there is only an infinite loop that alternates between reading and writing. But this is simply not a realistic approach for any reliable software.
source to share