In C #, The getrequeststream execution efficiency of httpwebrequest is too low, and even occasionally dies.

[Problem]

In C #, before submitting the corresponding post-Type HTTP request, execute:

Stream postdatastream = Req. getrequeststream ();

Then fill in the corresponding post data and submit the HTTP request.

However, during debugging, it is found that every execution of getrequeststream is slow.

If the request is slow, the system finds that the execution of Req. getrequeststream () is killed.

[Solution process]

1. I found it online. Why is the efficiency of getrequeststream so low? The explanation is that. NET will automatically search for the proxy each time, so it is very slow. If no proxy is set here, it should be copied as null:

Req. Proxy = NULL;

Then execute getrequeststream, so that it will not be slow.

Then I tried it, as if it was the effect.

2. The result is the same on the second day.Code, Debug, and the location of the getrequeststream result is still dead.

The cause is unknown.

3. Later on, the same code, run again, will not die, although it is still sometimes low efficiency, slow response, but will not die. The root cause is still unknown.

4. After multiple debugging, we found that:

Req. Proxy = NULL;

It seems that there is no effect.

I just happened to find the original official explanation about setting proxy to NULL:

Chapter 14. Networking of "C #3.0 in a nutshell, Third Edition: a desktop Quick Reference:

Warning If you don't have a proxy, you must set the proxy property to null on all WebClient and webrequest objects. otherwise, the framework may attempt to "auto-detect" your proxy settings, adding up to 30 seconds to your request. if you're wondering why your Web requests execute slowly, this is probably it!

But here, the problem that the execution of getrequeststream will die is not helpful.

5. the result of multiple debugging is:

Stream postdatastream = Req. getrequeststream ();

If it is a single-step debugging, it seems that very few will die.

However, if you run it directly without hitting a breakpoint, it is often easy to die.

6. See getrequeststream throws timeout exception randomly. I tried it:

?

12345

Using (Stream postdatastream = Req. getrequeststream ()){Postdatastream. Write (postbytes, 0, postbytes. Length );Postdatastream. Close ();}

It will still die.

7. httpwebrequest. getrequeststream () hangs appears to be a bug officially recognized.

However, even if it is a bug, it is explained in. net 4.0 beta2 is solved, and I cannot use it here.. Net 4.0, only. NET 2.0/3.0/3.5, so if it's a bug, it's really a tragedy...

Let's see if there are other solutions.

8. Tried the following code:

?

1234567891011

Try{Stream postdatastream = Req. getrequeststream (); Postdatastream. Write (postbytes, 0, postbytes. Length );Postdatastream. Close ();}Catch (Webexception ex){MessageBox. Show (ex. Message );}

One-step debugging:

Stream postdatastream = Req. getrequeststream ();

After a long time, it was found that an exception webexception ex was caught, and an error "unable to connect to the remote server" occurred. The details are as follows:

?

123456789101112131415161718192021222324252627282930313233343536

Ex {"unable to connect to the remote server"} system. net. webexception Base {"unable to connect to the remote server"} system. invalidoperationexception {system. net. webexception} Base {"unable to connect to the remote server"} system. systemexception {system. net. webexception} Base {"unable to connect to the remote server"} system. Exception {system. net. webexception} _ Classname Null String _ DATA null system. Collections. idictionary _ Dynamicmethods Null Object _ Exceptionmethod null system. reflection. methodbase _ Predictionmethodstring Null String _ Helpurl Null String _ Hresult-2146233079 int _ Innerexception {"A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond failed: 443"} system. exception {system. net. sockets. socketexception} _ Message "unable to connect to the remote server" String _ Remotestackindex 0 int _ Remotestacktracestring Null String _ Source Null String _ Stacktrace {sbyte [96]} object {sbyte []} _ Stacktracestring Null String _ Xcode-532459699 int _ Xptrs 0 system. intptr Data {system. Collections. listdictionaryinternal} system. Collections. idictionary {system. Collections. listdictionaryinternal} Helplink Null String Hresult-2146233079 int Innerexception {"A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond failed: 443"} system. exception {system. net. sockets. socketexception} Istransient false bool Message "unable to connect to the remote server" String Source "system" String Stacktrace "at system. net. httpwebrequest. getrequeststream (transportcontext & context) \ r \ n at system. net. httpwebrequest. getrequeststream () \ r \ n at insertskydrivefiles. skyDrive. beforeuploadfile () "String Targetsite {system. Io. Stream getrequeststream (system. net. transportcontext byref)} system. reflection. methodbase {system. reflection. runtimemethodinfo} Static members Internalstatus servicepointfatal system. net. webexceptioninternalstatus M_internalstatus servicepointfatal system. net. webexceptioninternalstatus M_response null system. net. webresponse M_status connectfailure system. net. webexceptionstatus Response null system. net. webresponse Status connectfailure system. net. webexceptionstatus

What I cannot understand here is that I only call getrequeststream to obtain the request stream, not the response from the server. Why should I link to remote server instead of calling a local library function, obtain the corresponding stream ???

 

[Postscript]

Later, I found that it seems that this problem is the same as the occasional death of getresponse, and then solved the problem. For specific procedures and methods, see:

Http://www.cnblogs.com/summer_adai/archive/2013/04/26/3045253.html