32

Would this be a good example of a scalable HttpListener that is multi-threaded?

Is this how for example a real IIS would do it?

public class Program { private static readonly HttpListener Listener = new HttpListener(); public static void Main() { Listener.Prefixes.Add("http://+:80/"); Listener.Start(); Listen(); Console.WriteLine("Listening..."); Console.WriteLine("Press any key to exit..."); Console.ReadKey(); } private static async void Listen() { while (true) { var context = await Listener.GetContextAsync(); Console.WriteLine("Client connected"); Task.Factory.StartNew(() => ProcessRequest(context)); } Listener.Close(); } private static void ProcessRequest(HttpListenerContext context) { System.Threading.Thread.Sleep(10*1000); Console.WriteLine("Response"); } }

I'm specifically looking for a scalable solution that DOES NOT rely on IIS. Instead only on http.sys (which is the httplistener class) -- The reason for not relying on iIS is because the govt. area I work in requires extremely reduced surface area of attack.

Improve this question
0

4 Answers 4

Reset to default
25

I've done something similar at https://github.com/JamesDunne/Aardwolf and have done some extensive testing on this.

See the code at https://github.com/JamesDunne/aardwolf/blob/master/Aardwolf/HttpAsyncHost.cs#L107 for the core event loop's implementation.

I find that using a Semaphore to control how many concurrent GetContextAsync requests are active is the best approach. Essentially, the main loop continues running until the semaphore blocks the thread due to the count being reached. Then there will be N concurrent "connection accepts" active. Each time a connection is accepted, the semaphore is released and a new request can take its place.

The semaphore's initial and max count values require some fine tuning, depending on the load you expect to receive. It's a delicate balancing act between the number of concurrent connections you expect vs. the average response times that your clients desire. Higher values mean more connections can be maintained yet at a much slower average response time; fewer connections will be rejected. Lower values mean less connections can be maintained yet at a much faster average response time; more connections will be rejected.

I've found, experimentally (on my hardware), that values around 128 allow the server to handle large amounts of concurrent connections (up to 1,024) at acceptable response times. Test using your own hardware and tune your parameters accordingly.

I've also found that a single instance of WCAT does not like to handle more than 1,024 connections itself. So if you're serious about load-testing, use multiple client machines with WCAT against your server and be sure to test over a fast network e.g. 10 GbE and that your OS's limits are not slowing you down. Be sure to test on Windows Server SKUs because the Desktop SKUs are limited by default.

Summary: How you write your connection accept loop is critical to the scalability of your server.

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

Is there a difference between using semaphores and the ServicePointManager.DefaultConnectionLimit?
ServicePointManager.DefaultConnectionLimit handles HTTP connections to clients and shouldn't affect the server's connection accepting/handling capacity.
Another open source project is NoIIS: github.com/SommerEngineering/NoIIS It's also about avoiding the IIS. There, you can also see the mentioned pattern about multi-threaded handling of client request.
5

Technically you're right. To make it scalable you probably want to have multiple GetContextAsync running at the same time (performance testing needed to know exactly how many, but "a few for each core" is probably the right answer).

Then naturally, as pointed out by comments; not using IIS means you need to be pretty serious about security for a lot of things IIS gives you "for free".

Improve this answer

Comments

1

I know I'm tremendously late to the party on this, but I published a library (source here https://github.com/jchristn/WatsonWebserver) on NuGet which encapsulates an async webserver.

Improve this answer

2 Comments

could you please take a look on stackoverflow.com/questions/78233284 ?
done, feel free to email me (see my github) if I can help further.
-1

Here's a pattern to use a cancellation token to shut the listener down cleanly:

try { while (active) { Task<HttpListenerContext> listenTask = httpListener.GetContextAsync(); listenTask.Wait(myCancelToken.Token); HttpListenerContext listenerContext = listenTask.Result; // Do something with listenerContext in a seperate thread or task.. } } catch (System.OperationCanceledException) { // This is expected! } httpListener.Close();

Note that this should be executed in its own thread or task to prevent blocking of other code.

Improve this answer

2 Comments

Wait and Result make this solution blocking, and so not scalable.
Also the listenTask.Wait(myCancelToken.Token) doesn't cancel the task, it only cancels the waiting of the task. The task will be awaited fully in the subsequent call to Result.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.