Implemented essential parts of HttpListenerTimeoutManager

[tekhedd]

Adds support for a subset of HttpListenerTimeoutManager's timeouts, improving the network code's worst case failure modes.

This is the same as the previous pull request, but with the nonessential reusable-timer code removed.

[tekhedd]

Here you go! IMO this does the bare minimum to make this HttpListener code useful in production.

[tekhedd]

And now it has conflicts. Should I just close the PR and maintain a fork?

[LukePulverenti]

You're welcome to keep the pull request open because I think the feature is interesting and could always incorporate it later. But for immediate resolution you should put them on a separate fork. I have a requirement of being able to consume this from both .NET and .NET Core, so I've chosen to go the route of PCL since our application already has the necessary abstractions such as a socket factory.

I'm not putting those changes here in this repository because I do not want to disrupt people who are already using the nuget package. For now on a temporary basis I've embedded the PCL into our application, although I may extract it later:
https://github.com/MediaBrowser/Emby/tree/dev/SocketHttpListener.Portable

I did add a nice optimization that can be added to this repository as time allows. I was able to remove the need for the ResponseStream wrapper class except in the case of chunked responses. I also switched the whole stack be async Task-based since that's all that's allowed in PCL.

[tekhedd]

Thanks, that all makes perfect sense now. The PCL version is much cleaner. I hacked some workarounds into my app, and am getting by with the Nuget version for the moment, but I'm pretty sure I'm still losing threads occasionally. Why does my code always seem to be deployed in the worst case scenario? :) I may temporarly clone the code, there's not a lot of code there really.

FYI, taking a quick look at the Portable branch/fork/version, with an infinite socket timeout you can still leak resources (thread pool threads) if the client fails to use timeouts. Async by itself does not protect you, but async with timeouts does, and the Listener code will close the socket from the parent thread when the handler returns. However it is important that 100% of remote I/O use a timeout around the async calls, both in the client code and internally. Or hack it and hard code a "large" timeout on the socket, chosen to be 20% longer than the largest application timeout. This is what I'd recommend, if it were my app.