HTTPWebRequest and Accept bug/feature

I don’t want to stir the hornet’s nest. I know about the socket Accept issue and ways to work around it. Years ago I modified the code from http://netmftoolbox.codeplex.com/ to workaround the issue. What are people doing today? Does HTTPWebRequest work reliably (for months, even if the connectivity is less than excellent)? I am updating some projects and would like to depend more on the core if it is really reliable.

So, no one is using NetMF as an HTTP client?

You are right that Socket.Accept is not needed for an http client, but it does use Socket.Connect under the hood. If the destination location is not available Socket.Connect will wait not time out, which causes the program to hang. From what I have read this is still the case. I originally used HttpWebRequest, but found that after some random amount of time my program would hang. I switched to using the codeplex Toolbox implementation because it allowed me use the delegate thread workaround whenever using the socket. It also provides a somewhat nicer interface.

I was just wondering what people are doing now to get reliable http client code.

That’s what I do when I write code that uses a socket directly. Does HttpWebrequest do this by itself, or do you know if it would work to wrap that call instead? As I recall, there was a reason I didn’t do that and chose the codeplex toolbox path instead. It looks like the Toolbox code has been updated to work with 4.3, so that might be the easiest path.

I will say this is one thing that is really annoying about NetMF and networking. I am not using SSL or I am sure I would be annoyed at that too.

Thanks for the confirmation that the issue still exists.

https://msdn.microsoft.com/en-us/library/system.net.httpwebrequest.timeout(v=vs.110).aspx

See the timeout value, which does not work in NetMF but does in .Net.

So, yes it is a bug. Perhaps one that will never be fixed, but still seems to be one.