[Mono-dev] HttpListener

Wed May 20 02:18:46 UTC 2015

Since we're talking about the HttpListener..    Any thoughts on making
HttpListener more friendly to longer running, blocked tasks.?   Such as
Event Queues.   Almost all of these edge cases involve reading the input
stream for paths/queryparams/etc, blocking the thread while doing some work
or waiting some amount of time, then servicing the response.   With the
current HTTPListener this leads to lots of precious threadpool threads
blocked and not doing anything but also counting against the mono
threadpool thread limit.  The simplest way that this can be done is simply
decoupling the HttpListener threads from the threadpool thread limit..
 that way the threadpool threads are limited separately.     The more
complicated way could be to allow some sort of thread sleep call that puts
the IO streams for the http requests into a pool of streams managed by a
single worker thread while they're waiting and then restores them to it's
own thread once the work is done to send the response.   I have previously
done the second method with a third party HttpListener replacement and it
saved a lot of threads which freed them up to do other useful things in a
highly parallel server without forcing the end user to manually specify a
larger mono maximum threadpool thread limit.

Regards

Teravus

On Tue, May 19, 2015 at 2:28 PM, Greg Young <gregoryyoung1 at gmail.com> wrote:

> Yes exactly my intention. The problem is I am only given http prefixes
> in that code.
>
> Consider the case I have an interface 192.168.1.1 and an interface
> 10.114.1.112
>
> Given a http prefix of http://my.elasticip:8080 which interface should it
> pick?
>
> As you can see here the prefixes are being used for both:
>
> https://github.com/mono/mono/blob/master/mcs/class/System/System.Net/EndPointManager.cs#L77
> as well as some odd error conditions which I imagine are to match MS
> implementation but would need to verify that.
>
> If there was a separation between which interface to pick vs which
> http prefixes to use this would solve the problem and is essentially
> what I was talking about putting in as an overload. I know mono is as
> a whole a bit reluctant to add mono specific overloads (which is
> completely understandable). I just find kind any other reasonable way
> here of handling the windows/mono differences.
>
>
> https://github.com/mono/mono/blob/master/mcs/class/System/System.Net/HttpListener.cs#L269
> leads to
>
> https://github.com/mono/mono/blob/master/mcs/class/System/System.Net/EndPointManager.cs#L48
>
> I could do this in a couple of ways (add state to HttpListener is an
> obvious one + an overload that only changes behaviour if its used).
>
> Greg
>
> On Wed, May 20, 2015 at 12:18 AM, Miguel de Icaza <miguel at xamarin.com>
> wrote:
> > Shouldn't we bind on the interface based on the IP address?
> >
> > Would that not solve the problem?
> >
> > miguel
> >
> > On Tue, May 19, 2015 at 4:00 PM, Greg Young <gregoryyoung1 at gmail.com>
> wrote:
> >>
> >> I was thinking a basic code api that allowed the specification of
> >> interface to bind to separately from which prefixes to accept to start
> >> with. The biggest issue here is that the ms api is basically using
> >> httpprefix to mean two very different things.
> >>
> >> On Tue, May 19, 2015 at 10:58 PM, Miguel de Icaza <miguel at xamarin.com>
> >> wrote:
> >> > Well, it might be best if you explain what you have in mind, before we
> >> > waste
> >> > time with a pull request.
> >> >
> >> > But either way works.
> >> >
> >> > On Tue, May 19, 2015 at 3:50 PM, Greg Young <gregoryyoung1 at gmail.com>
> >> > wrote:
> >> >>
> >> >> Miguel,
> >> >>
> >> >> Would it be best to just take a stab at an alternative interface and
> >> >> send a PR for discussion?
> >> >>
> >> >> Greg
> >> >>
> >> >> On Sun, Apr 26, 2015 at 4:43 PM, Greg Young <gregoryyoung1 at gmail.com
> >
> >> >> wrote:
> >> >> > This is the code handling the prefixes its here
> >> >> >
> >> >> >
> >> >> >
> https://github.com/mono/mono/blob/master/mcs/class/System/System.Net/EndPointManager.cs#L43
> >> >> >
> >> >> > There is quite a bit of odd code around this in general. I
> understand
> >> >> > much of it is trying to reach compliance with MS but ...
> >> >> >
> >> >> > On Sun, Apr 26, 2015 at 4:40 PM, Miguel de Icaza <
> miguel at xamarin.com>
> >> >> > wrote:
> >> >> >> Hello Greg,
> >> >> >>
> >> >> >> Is that in HttpListener, or somewhere else?
> >> >> >>
> >> >> >> Miguel
> >> >> >>
> >> >> >> On Fri, Apr 24, 2015 at 12:41 PM, Greg Young
> >> >> >> <gregoryyoung1 at gmail.com>
> >> >> >> wrote:
> >> >> >>>
> >> >> >>> Here is some of the code in question:
> >> >> >>>
> >> >> >>> IPAddress addr;
> >> >> >>> if (host == "*")
> >> >> >>>     addr = IPAddress.Any;
> >> >> >>> else if (IPAddress.TryParse(host, out addr) == false){
> >> >> >>>     try {
> >> >> >>>         IPHostEntry iphost = Dns.GetHostByName(host);
> >> >> >>>        if (iphost != null)
> >> >> >>>             addr = iphost.AddressList[0];
> >> >> >>>        else
> >> >> >>>             addr = IPAddress.Any;
> >> >> >>>    } catch {
> >> >> >>>         addr = IPAddress.Any;
> >> >> >>>    }
> >> >> >>> }
> >> >> >>>
> >> >> >>> On Fri, Apr 24, 2015 at 7:29 PM, Greg Young
> >> >> >>> <gregoryyoung1 at gmail.com>
> >> >> >>> wrote:
> >> >> >>> > I have been going through a bunch of this code lately after
> >> >> >>> > seeing
> >> >> >>> > many ... interesting behaviours. I understand that much of the
> >> >> >>> > derp
> >> >> >>> > in
> >> >> >>> > this code is due to not having IIS and MS having an IIS centric
> >> >> >>> > API
> >> >> >>> > but wow. Some gems I have found...
> >> >> >>> >
> >> >> >>> > 1) synchronous dns calls being made...
> >> >> >>> > 2) I want to listen on 192.168.0.1:1234 but I want to support
> a
> >> >> >>> > host
> >> >> >>> > header of whateverdomain can't resolve whatever domain then
> bind
> >> >> >>> > listeners to all ips on machine.
> >> >> >>> > 3) Same as above but dns entry has multiple ips it resovles to
> >> >> >>> > [0]
> >> >> >>> > doesnt match see #2
> >> >> >>> > 4) Anything at all to do with elastic ips
> >> >> >>> > 5) Exceptions thrown to calling code with http status codes in
> >> >> >>> > them
> >> >> >>> > (I
> >> >> >>> > think this is ms legacy but is a pretty biog wtf)
> >> >> >>> > 6) failure parsing ip address says bind all interfaces on
> machine
> >> >> >>> > (huh?)
> >> >> >>> >
> >> >> >>> > Perhaps it makes sense to expose a "Microsoft Http
> Compatibility
> >> >> >>> > Layer" and then have a "Sane API if you want to use it"
> >> >> >>> >
> >> >> >>> > I dont mind putting some time in on these but is this even
> >> >> >>> > worthwhile
> >> >> >>> > or is the plan to just burn this code with fire and move to
> >> >> >>> > something
> >> >> >>> > sane in general?
> >> >> >>> >
> >> >> >>> > Cheers,
> >> >> >>> >
> >> >> >>> > Greg
> >> >> >>> > --
> >> >> >>> > Studying for the Turing test
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>> --
> >> >> >>> Studying for the Turing test
> >> >> >>> _______________________________________________
> >> >> >>> Mono-devel-list mailing list
> >> >> >>> Mono-devel-list at lists.ximian.com
> >> >> >>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Studying for the Turing test
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Studying for the Turing test
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Studying for the Turing test
> >
> >
>
>
>
> --
> Studying for the Turing test
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20150519/c337b510/attachment-0001.html>