Prev: ASPNET credentials keep on resetting
Next: remoting is knocking down CPU
From: Malcolm Hall on 19 Nov 2009 22:47
UploadStringAsync is supposed to be asyncronous but I can make it hang
by passing it an invalid url. It looks to me like it does a
synchronous DNS request first that makes it hang. I don't want my app
to hang under any circumstances when making this web client request,
especially not long DNS requests, does anyone know a work around? Btw
if testing this you need to change the url to a different duff one
every time.

string server = "http://www.google.duffurl";
string param = "test=5";
WebClient wc = new WebClient();
wc.Headers["Content-Type"] = "application/x-www-form-urlencoded";
wc.Encoding = Encoding.UTF8;
wc.UploadStringCompleted += new UploadStringCompletedEventHandler
(wc_UploadStringCompleted);
Uri u = new Uri(server);
wc.UploadStringAsync(u, "POST", param); // hangs if can't find server
Debug.Writeline("upload sent");
From: Peter Duniho on 20 Nov 2009 00:53
Malcolm Hall wrote:
> UploadStringAsync is supposed to be asyncronous but I can make it hang
> by passing it an invalid url. It looks to me like it does a
> synchronous DNS request first that makes it hang. I don't want my app
> to hang under any circumstances when making this web client request,
> especially not long DNS requests, does anyone know a work around?

Sorry. Not repro here (Windows 7, .NET 3.5).

For what it's worth, the detailed remarks in the MSDN documentation only
promise that the sending of the string is done asynchronously. They
don't rule out the possibility that the method may attempt to resolve
the server address prior to starting the asynchronous operation.

I took a quick look at the implementation in Reflector, but didn't see
any obvious attempts to resolve the URI before the UploadStringAsync()
method returns. That doesn't mean it doesn't, but if it does it's
well-buried under a bunch of initialization code.

I would have tried stepping through the actual .NET code, but the
symbol/source server has been acting up again and for some reason my
..NET source-level debugging is broken again. :(

It might help if you would be more specific about your problem. What
version of .NET are you using? What version of Windows? When you write
"hang", what do you really mean? Does your program literally never
return from that method? Or are you (inaccurately) using the word
"hang" simply to mean the method call takes longer than you expect?

> Btw
> if testing this you need to change the url to a different duff one
> every time.

I just modified your code example to incorporate
"DateTime.Now.Ticks.ToString()" in the URI, to guarantee a new URI each
time I execute the test.

Pete
From: Malcolm Hall on 21 Nov 2009 08:27
I too didn't see anything obvious in Reflector. I added current time
debug output before and after the line:

21/11/2009 13:19:55
21/11/2009 13:20:07

As you can see its taking 12 seconds to complete the call to
UploadStringAsync. This blocks the UI thread and causes (Not
responding) to appear in the Form's title. This is more or less the
same time it takes DNS to error if I type ping and a bad domain into
CMD so it does appear to be a DNS problem.

I'm running Windows 7 and .NET 3.5. I'm going to try some of the async
methods its using internally to see if they have the same problem. I
think BeginGetRequestStream was one of them... Or I'll try source
debugging because not tried that before.
From: Peter Duniho on 21 Nov 2009 14:10
Malcolm Hall wrote:
> I too didn't see anything obvious in Reflector. I added current time
> debug output before and after the line:
>
> 21/11/2009 13:19:55
> 21/11/2009 13:20:07
>
> As you can see its taking 12 seconds to complete the call to
> UploadStringAsync.

Well, like I said, I was unable to reproduce the problem. In fact, I
did the same kind of timing modification to the code example when I
original tested it, and while the call to UploadStringAsync() took
almost all of the total execution time, it was generally less than 100ms
to return.

> This blocks the UI thread and causes (Not
> responding) to appear in the Form's title. This is more or less the
> same time it takes DNS to error if I type ping and a bad domain into
> CMD so it does appear to be a DNS problem.

Well, given that it's controlled by whether the domain is valid or not,
I figured that was obvious. :) Why my system is so quick to reject the
URL, I don't know.

Maybe I've got an Internet provider with faster DNS servers, or lack of
redirection (in fact, my ISP defaults to DNS redirection so they can
serve up fake page results to sell ads, but I'm able to turn that off
and have), or their DNS servers don't have a fallback (i.e. query
additional servers), or some combination of the above.

In the end, however, I think the fundamental answer is that the
UploadStringAsync() method is probably working as designed.
Specifically, it never promised that the DNS lookup itself would be
asynchronous, and to the extent that the delay cause by a DNS lookup is
not under your control, you may always suffer some delay in the code
using that method.

> I'm running Windows 7 and .NET 3.5. I'm going to try some of the async
> methods its using internally to see if they have the same problem. I
> think BeginGetRequestStream was one of them... Or I'll try source
> debugging because not tried that before.

Good luck. I'd be curious to know if you get it working. Like I said,
on my computer it's broken again. Last time, that was because the
Microsoft servers weren't working right, and I wasted so much time
trying to debug the problem before, I really don't have any interest
messing around with it again. But if you can confirm the servers are
working properly, that might suggest it'd be worthwhile for me to reset
things and try again. :)

Pete
From: Goran Sliskovic on 21 Nov 2009 14:41

"Peter Duniho" <no.peted.spam(a)no.nwlink.spam.com> wrote in message
news:OIAIG5taKHA.5608(a)TK2MSFTNGP05.phx.gbl...
....
> Well, like I said, I was unable to reproduce the problem. In fact, I did
> the same kind of timing modification to the code example when I original
> tested it, and while the call to UploadStringAsync() took almost all of
> the total execution time, it was generally less than 100ms to return.
>
....

You have to test probably with non-existant DNS server, not non-existant
domain. DNS servers are very fast in getting the IP from name. That means
that they are also fast in finding the domains that do not exist. ;)

Try to set a DNS server to a non-existant IP address in your network. Don't
use IP of online computer.

Regards,
Goran

 |  Next  |  Last
Pages: 1 2 3
Prev: ASPNET credentials keep on resetting
Next: remoting is knocking down CPU