The main problem that someone have to implement HTTP-server and websocket-handling code on top of that, since existing implementations (Nowin, websocket implementations on top of XSockets, SuperSockets.NET, etc) are bound to thread pool model. I think it's much better to find some existing HTTP/WebSocket server library, wrap it and use for hosting ASP.NETvNext applications. It will safe a lot of pain. Althrough it's possible to patch something like Nowin in a way, that it would be able to use both models and switch between them.
2014-05-15 21:59 GMT+04:00 Nikita Tsukanov <kek...@gmail.com>: > Now I'm digging the source code and it seems that second one is quite > close to what is needed. > > > 2014-05-15 21:51 GMT+04:00 Nikita Tsukanov <kek...@gmail.com>: > > There are some existing wrappers: >> https://github.com/kersny/libuv-csharp - Dead, no commits for 3 years >> https://github.com/txdv/LibuvSharp - uses Task ( >> https://github.com/txdv/LibuvSharp/blob/master/Examples/TcpAsync.cs ), >> so it should have same problems with thread pool >> >> >> 2014-05-15 21:41 GMT+04:00 Greg Young <gregoryyou...@gmail.com>: >> >> That would make sense as the models are different. Also that libuv >>> wrapper from looking looks fairly promising. >>> >>> >>> On Thu, May 15, 2014 at 8:38 PM, Nikita Tsukanov <kek...@gmail.com>wrote: >>> >>>> I think we should have something like Mono.Sockets with abstraction of >>>> event loop and I/O code based on libuv or whatever, and build classes like >>>> HttpListener on top of it. >>>> >>>> >>>> 2014-05-15 21:30 GMT+04:00 Nikita Tsukanov <kek...@gmail.com>: >>>> >>>> I suspect that having libuv behind socket code won't help much, since >>>>> most of socket performance problems are related to the fact that >>>>> BeginSend/Recieve, event loop and AsyncCallback run in different threads. >>>>> Because of that we have overhead even with simple >>>>> void ReadNext() >>>>> { >>>>> _socket.BeginRecieve(buf, blablabla, res=> >>>>> { >>>>> _socket.EndRecieve(res); >>>>> ReadNext(); >>>>> }); >>>>> } >>>>> On windows that works fine because of IOCP behind that abstraction >>>>> that is designed to be used with thread pool. *nix platforms doesn't have >>>>> anything like IOCP, only epoll/kqueue, so for actual performance >>>>> improvement one have to use single-threaded approach (with round-robin >>>>> connection dispatch between workers), when all I/O operations and event >>>>> loop run in single thread. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> 2014-05-15 20:55 GMT+04:00 Miguel de Icaza <mig...@xamarin.com>: >>>>> >>>>> Hello, >>>>>> >>>>>> Well, i want to see a prototype, and then decide. >>>>>> >>>>>> So this needs to be done with some kind of peer framework where this >>>>>> is done. >>>>>> >>>>>> >>>>>> On Thu, May 15, 2014 at 9:29 AM, Greg Young >>>>>> <gregoryyou...@gmail.com>wrote: >>>>>> >>>>>>> Yes I would say moving both to libuv would be a good move :) >>>>>>> >>>>>>> >>>>>>> On Thu, May 15, 2014 at 4:22 PM, Roope Kangas < >>>>>>> ro...@grandcrugames.com> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> On a tangent... >>>>>>>> >>>>>>>> It would be really nice if something like libuv would the thing >>>>>>>> behind Socket code. >>>>>>>> >>>>>>>> Could that be something to investigate? >>>>>>>> >>>>>>>> Mono could basically piggyback on nodejs development. >>>>>>>> >>>>>>>> -- >>>>>>>> Roope Kangas >>>>>>>> >>>>>>>> On 15.5.2014, at 15.00, Greg Young <gregoryyou...@gmail.com> wrote: >>>>>>>> >>>>>>>> So the one issue I have seen with the libevent implementation is >>>>>>>> that it seems to perform very poorly in windows (+-5k hello >>>>>>>> worlds/second >>>>>>>> where as its closer to 100k/second in linux). From researching libevent >>>>>>>> they supposedly now use IOCP in windows and should be better but I >>>>>>>> have not >>>>>>>> been able to make this happen. It may also be worth looking at libuv >>>>>>>> which >>>>>>>> is pretty close to a drop in replacement for libevent as it seems to >>>>>>>> get >>>>>>>> much better performance in windows and similar performance in linux. >>>>>>>> @Nikita I will hopefully have some time next week and likely will send >>>>>>>> some >>>>>>>> more pull requests in relation to the memory allocation patterns. >>>>>>>> >>>>>>>> >>>>>>>> On Thu, May 15, 2014 at 6:56 AM, Miguel de Icaza < >>>>>>>> mig...@xamarin.com> wrote: >>>>>>>> >>>>>>>>> Hello Nikita! >>>>>>>>> >>>>>>>>> Your approach looks fabulous! I look forward to trying it out! >>>>>>>>> >>>>>>>>> Miguel >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, May 14, 2014 at 11:40 AM, Nikita Tsukanov < >>>>>>>>> kek...@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> I'll try to implement OWIN host on top of my libevent built-in >>>>>>>>>> http server ( https://github.com/kekekeks/evhttp-sharp ) since >>>>>>>>>> for now it's the fastest thing for handling HTTP-requests on Mono I >>>>>>>>>> know >>>>>>>>>> (now it has host implementation for NancyFx which we are using in >>>>>>>>>> production for half of a year). >>>>>>>>>> Although both evhttp-sharp and FastCGI servers like HyperFastCGI >>>>>>>>>> and Fos, are incapable of serving websockets (one because of >>>>>>>>>> underlying >>>>>>>>>> implementation, another because of limitations of FastCGI protocol), >>>>>>>>>> so it >>>>>>>>>> would be great to wrap something like >>>>>>>>>> https://github.com/kekekeks/evhttp-sharp which has websocket >>>>>>>>>> support and positioned as evhttp drop-in replacement. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Nikita >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2014-05-14 19:29 GMT+04:00 Marcelo Zabani <mzab...@gmail.com>: >>>>>>>>>> >>>>>>>>>> Wow! This is such great news!! >>>>>>>>>>> >>>>>>>>>>> As for running Owin applications with Unix HTTP servers, I've >>>>>>>>>>> developed Fos <http://github.com/mzabani/Fos> on a very >>>>>>>>>>> permissive license and a focus on good documentation and running >>>>>>>>>>> with Mono >>>>>>>>>>> on *nix. I would very much love getting contributions on this, >>>>>>>>>>> because my >>>>>>>>>>> spare time is running lower these days. >>>>>>>>>>> >>>>>>>>>>> Hope it helps, >>>>>>>>>>> Marcelo. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, May 14, 2014 at 12:44 AM, Miguel de Icaza < >>>>>>>>>>> mig...@xamarin.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hello guys! >>>>>>>>>>>> >>>>>>>>>>>> Microsoft has open sourced ASP.NET vNext: >>>>>>>>>>>> >>>>>>>>>>>> http://github.com/aspnet/home >>>>>>>>>>>> >>>>>>>>>>>> This is an entire new web stack that only needs the core of >>>>>>>>>>>> Mono (does not even use System.Web.dll!). >>>>>>>>>>>> >>>>>>>>>>>> So these are of course great news, because (a) The core Mono >>>>>>>>>>>> has been in active development, and (b) that means that Mono's on >>>>>>>>>>>> the >>>>>>>>>>>> server can be used without all those pesky limitations that have >>>>>>>>>>>> been >>>>>>>>>>>> plaguing us for years. >>>>>>>>>>>> >>>>>>>>>>>> So we ran into a couple of limitations in Mono: some classes >>>>>>>>>>>> that they need are not implemented (I filed a bug, and a couple of >>>>>>>>>>>> Xamarin >>>>>>>>>>>> folks decided to take on that on their copious spare time) and we >>>>>>>>>>>> have a >>>>>>>>>>>> couple of bugs on FileSystemWatcher on OSX. >>>>>>>>>>>> >>>>>>>>>>>> But this is a great time to: >>>>>>>>>>>> >>>>>>>>>>>> - Get involved with the github.com/aspnet project and >>>>>>>>>>>> submit contributions that will make the software run on Unix. >>>>>>>>>>>> >>>>>>>>>>>> - Look into technologies like Owin and Katana (sp?) and >>>>>>>>>>>> help us have a story that plugs into Unix HTTP servers (the >>>>>>>>>>>> equivalent of >>>>>>>>>>>> our bridge between Apache and mono: mod_mono, or our Fast CGI >>>>>>>>>>>> bridge to >>>>>>>>>>>> mono). >>>>>>>>>>>> >>>>>>>>>>>> - Take Mono's new profiling tools and performance counters >>>>>>>>>>>> for a spin and help us fine tune the runtime to run .NET code >>>>>>>>>>>> faster on >>>>>>>>>>>> Unix than you can on Windows. While this is a tall order, my >>>>>>>>>>>> friend David >>>>>>>>>>>> Miller would expect nothing less from us. >>>>>>>>>>>> >>>>>>>>>>>> Hugs and love, >>>>>>>>>>>> Miguel >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Mono-devel-list mailing list >>>>>>>>>>>> Mono-devel-list@lists.ximian.com >>>>>>>>>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Mono-devel-list mailing list >>>>>>>>>>> Mono-devel-list@lists.ximian.com >>>>>>>>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Mono-devel-list mailing list >>>>>>>>>> Mono-devel-list@lists.ximian.com >>>>>>>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Mono-devel-list mailing list >>>>>>>>> Mono-devel-list@lists.ximian.com >>>>>>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Studying for the Turing test >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Mono-devel-list mailing list >>>>>>>> Mono-devel-list@lists.ximian.com >>>>>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Mono-devel-list mailing list >>>>>>>> Mono-devel-list@lists.ximian.com >>>>>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Studying for the Turing test >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Mono-devel-list mailing list >>>>>>> Mono-devel-list@lists.ximian.com >>>>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Mono-devel-list mailing list >>>>>> Mono-devel-list@lists.ximian.com >>>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Mono-devel-list mailing list >>>> Mono-devel-list@lists.ximian.com >>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>>> >>>> >>> >>> >>> -- >>> Studying for the Turing test >>> >> >> >
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list