WebClient Freezes for Ten Seconds on First Connect

I've build a client-server application in which the client communicates with
the server by making calls to WebClient.UploadValuesAsync().

In a given client session, hundreds of calls will be made and generally
speaking I'm pleased with the performance. It only takes a few milliseconds
from the time UploadValuesAsync() is called to the time the server receives
the request and begins processing it. The problem is that the FIRST call of
the session takes around ten seconds to get from client to server.

During this ten second period, the UploadValuesAsync() call blocks.
Repeatedly running "netstat -n" at the command line indicates that the
connection is not established during this period. Then, after ten sesconds,
netstat shows the new connection, UploadValuesAsync() unblocks, and all is
well.

I can't for the life of me figure out what is causing this problem. The ten
second hang time wouldn't really bother me in production mode, but it makes
development a real pain, because each time I make a change to the code and
want to test it, I have to deal with it. Any ideas?

Jules

Re: WebClient Freezes for Ten Seconds on First Connect

Here's the solution for anyone who is interested:

WebClient internally makes use of HttpWebRequest. HttpWebRequest exposes a
property called Proxy which for some reason is, by default, set to a
non-null value. This is despite the fact that I do NOT USE A PROXY, nor is
Internet Explorer configured to use one.

Anyway, the fact that this Proxy property is non-null is not problematic in
most cases. My case is somewhat unusual, however, in that my development
machine is connected via PPTP VPN to a remote network. Now, this shouldn't
really matter since the server to which my app is connecting isn't on the
other side of the VPN. The VPN isn't involved in the client-server
transaction at ALL, but I noticed that when the VPN was disconnected, the
ten second delay mentioned in my original post went away. Weird! It turns
out that by manually setting the Proxy property to null on the WebClient
(which in turn sets the Proxy property to null on the underlying
HttpWebRequest), the problem is resolved. When the Proxy property is set to
null, the delay goes away, regardless of whether or not the VPN is
connected.

Hopefully this will help someone else that runs into this bizarre bug.

Jules