On 02/11/2014 09:42 PM, Nikhil Saraf wrote: > Hello Folks, > > I've been trying for more than a week to figure out a way to handle > MHD_OPTION_CONNECTION_LIMIT; but no breakthrough yet. > > As of now, with the latest version of microhttpd, if I configure max.no.of > connections to, say, 3, then a 4th connection just "waits" until one of the > earlier connection closes down. I want the 4th connection to not even get > through. Is there a way to achieve this? > > I was thinking to let the "handler" insert "Connection: close" header into > the response; but the question is: how does handler become aware that > MHD_OPTION_CONNECTION_LIMIT has reached? > > Please advise/suggest/help.
Ok, first of all, the behavior that MHD won't even accept the 4th connection if your limit is 3 is totally intended by design. Once one of the first three is done, MHD will move on to #4. Now, the number of connections that will be in this queue to be accepted "next" is limited by the "listen" call to 32 (by default). If that queue is too long for you, you can open your own listen socket with a different queue size and pass that to MHD. Again, having this listen queue is part of the design of TCP and generally a very good idea, because you drop fewer requests and can achieve a higher throughput by having a request pending in the queue while you process other requests. That said, if you, for whatever strange reason, really really want the behavior that the 4th connection is accepted "immediately" and then simply "closed", what you could do (again, not recommended) is set the connection limit for MHD to say 4 (anything above 3), implement your own counting logic, and if your counter hits 4 simply return "MHD_NO" from the main callback. That'll cause MHD to instantly close the connection, without handling it. Again, I would generally think this is a terrible idea, but it would work and give you the semantics you asked for. Happy hacking! Christian
0x48426C7E.asc
Description: application/pgp-keys
