c# - What is the difference between making an Async web service call and making a Synchronous web service call in another thread? -


and/or, when use either one? matter of preference or there technical difference?

bit of background on why asking: have app running .net 2.0 cf app , user making several quick actions. don't 1 block actions, want ui show either wait icon or progress icon bar.

the long-running actions due web service calls , processing of returned data on device itself.

edit after reviewing jim's answer , quote below, best practice perform asynch calls while avoid putting load on ui thread? call begingetresponse in separate thread?

the begingetresponse method requires synchronous setup tasks complete (dns resolution, proxy detection, , tcp socket connection, example) before method becomes asynchronous. result, method should never called on user interface (ui) thread because might take considerable time (up several minutes depending on network settings) complete initial synchronous setup tasks before exception error thrown or method succeeds.

if make asynchronous web service call, ui might tied brief period during dns resolution. begingetresponse method resolves dns before makes asynchronous method call response. if dns resolution takes time (it's quite fast, can take seconds), ui unresponsive period.

see is asynchronous? more details.

beyond that, long process response in callback (which executed on separate thread), there no difference in ui responsiveness. difference here asynch requests, separate thread active during processing result. thread doing synchronous request, thread active entire duration of request , processing. web service calls, processing takes lot less time making request , waiting result.

if make lots of requests, run risk of resource exhaustion 1 thread per call. on modern hardware you'd have making dozens of requests per second become issue.

all said, should using asynchronous web requests. if you're hitting same domain (or small number of domains) requests, dns resolution satisfied local cache, meaning won't take time @ all. , reduce (almost eliminate) risk of resource exhaustion due many concurrent threads.

it's interesting note documentation httpwebrequest.begingetresponse says:

the begingetresponse method requires synchronous setup tasks complete (dns resolution, proxy detection, , tcp socket connection, example) before method becomes asynchronous. result, this method should never called on user interface (ui) thread because might take considerable time (up several minutes depending on network settings) complete initial synchronous setup tasks before exception error thrown or method succeeds.

whereas that's general advice, comment above still applies: if calls going same server or same group of servers (which case in-house app), warning irrelevant. dns cached, proxy set up, etc. if proxy setup takes lot of time on per-connection basis, need department resolution. in experience, asynchronous web requests way go.


Comments

Popular posts from this blog

c# - DetailsView in ASP.Net - How to add another column on the side/add a control in each row? -

javascript - firefox memory leak -

Trying to import CSV file to a SQL Server database using asp.net and c# - can't find what I'm missing -