No more Framework, upcoming server features

[Benjamin van der Veen]

Hi all,

Just a quick update on the status of Kayak.

The framework part of Kayak is no more. No more KayakService, no more [Path] and [Verb] attributes. Going forward Kayak is only a web server. I was never very happy with the structure of the framework bits—I could never get it to be sufficiently modular in a satisfying way. I realize now that a composition of OWIN 'middleware' is the best way to approach issues like routing, method invocation, [de]serialization, authentication, and the like. Furthermore, I no longer feel that C# is well-suited to writing user-facing web frameworks. I may revisit the framework later, likely as a separate F# project which is pitched as a collection of OWIN middleware.

Upcoming for Kayak-the-web-server:

- Significantly improved performance, memory efficiency, standards-compliance, and security of request parsing, with HTTP/1.1 support. I'm making a new evented HTTP parser using Ragel (see: https://github.com/bvanderveen/httpmachine)
- A new IO engine based on Oars, my libevent2 bindings for C# (see: http://code.google.com/p/oars/). This will significantly improve the performance of Kayak on Mono, making it a single-threaded, evented server. The existing native .NET IO engine (based on System.Net.Sockets.Socket) will continue to be supported for .NET and Mono (and .NET Micro Framework, if it's not too hard).
- Full support of the final OWIN spec. OWIN is super, super close to being 1.0, and as soon as it is, Kayak will be a best-of-breed OWIN host implementation.

I realize that to date I have not been the best steward of an open source project in terms of releases, making the source code easy to build and test, accurate and up-to-date website/documentation, etc. This is something I want to get better at in the future, but as a one-man show my resources are limited. So, I'm very grateful for everyone's bug reports, suggestions for how to make Kayak easier to learn about, hack on and use, etc—keep them coming! My head is very much in the guts of Kayak and I appreciate any help making Kayak easier for developers to use.

Kayak is approaching a stable state and I look forward to a 1.0 release in the coming months. Thank you for your continued interest, and please stay tuned.

Benjamin

[mythz]

Hey Benjamin,

Thanks for the update.
Its good to hear you're going back to your web-server roots, I'm sure
it will end up being an awesome implementation!

As Kayak is foremost an async, evented, non-blocking web server, will
this new direction include an adapter implementation for hosting
synchronous web frameworks?



On Jan 18, 9:33 pm, Benjamin van der Veen <b...@bvanderveen.com>
wrote:

[Gonzalo]

On Jan 18, 7:51 pm, Benjamin van der Veen <b...@bvanderveen.com>
wrote:

> On Jan 18, 2011, at 4:19 PM, mythz wrote:
>
> > As Kayak is foremost an async, evented, non-blocking web server, will
> > this new direction include an adapter implementation for hosting
> > synchronous web frameworks?
>

> The .NET IO driver does IO using the asynchronous methods of System.Net.Sockets.Socket. In .NET and Mono the callbacks come in on ThreadPool threads, i.e., there are multiple worker threads for this driver. Thus, you can do blocking IO on those worker threads without choking the server. So synchronous frameworks should just work on that driver.
>
> Caveat on Mono: async methods of socket are implemented with sync methods delegated to the ThreadPool, so there's actually a performance penalty to doing async IO using the .NET APIs on Mono rather than just doing a synchronous call (since, for a round-trip, both the work and the result callback must be queued to the ThreadPool). It should be possible (and not too difficult) to implement a truly synchronous IO driver (with a "stack watcher" which would reschedule callbacks if the stack got too high) to work around this performance problem on Mono. Of course, you'd be better off using the Oars driver with an async framework. ;)

Some clarification about how Mono thread pools are related to Socket
asynch IO:

In Mono, prior to the upcoming 2.10, async socket calls add the socket
to epoll(linux)/poll(everything else). Once the socket is ready, a
work item is queued in the IO thread pool and once that is executed,
the callback, if any, is scheduled in the regular thread pool.

As of 2.10, the socket is still added to epoll/poll but using a faster
code path, the work item in the IO thread pool is faster and the
callback is scheduled into the regular thread pool from unmanaged code
whenever possible. Also SocketAsyncEventArgs support is properly
implemented. There were also a bunch of nice improvements to the
regular threadpool in Mono 2.8+: per threadpool thread work-stealing
queues, lock free scheduling when adding a threadpool work item from a
threadpool thread, much better dynamic adjustment of the number of
threadpool threads based on workload,...).

-Gonzalo

[Benjamin van der Veen]

On Jan 18, 2011, at 5:53 PM, Gonzalo wrote:

> Some clarification about how Mono thread pools are related to Socket
> asynch IO:
>
> In Mono, prior to the upcoming 2.10, async socket calls add the socket
> to epoll(linux)/poll(everything else). Once the socket is ready, a
> work item is queued in the IO thread pool and once that is executed,
> the callback, if any, is scheduled in the regular thread pool.
>
> As of 2.10, the socket is still added to epoll/poll but using a faster
> code path, the work item in the IO thread pool is faster and the
> callback is scheduled into the regular thread pool from unmanaged code
> whenever possible. Also SocketAsyncEventArgs support is properly
> implemented. There were also a bunch of nice improvements to the
> regular threadpool in Mono 2.8+: per threadpool thread work-stealing
> queues, lock free scheduling when adding a threadpool work item from a
> threadpool thread, much better dynamic adjustment of the number of
> threadpool threads based on workload,...).
>
> -Gonzalo
>

This is great information Gonzalo, thank you for clarifying! I'll definitely play with this when 2.10 comes round.

[ged...@gmail.com]

This sounds like great news. Looking forward to this.

Pity about talk of dropping c#, I like NodeJs but cant see it holding together well for large applications. I must be lazy bit i like compile errors :)

Ged

[ged...@gmail.com]

"httpmachine". Thats the same name for the Erlang one ??

I used it for a bit. 

ged

[ged...@gmail.com]

Ok so the httpmachine is based on c code.

this all sounds very much like NodeJS. By this i mean that you code in c#, but the underlying performance and good stuff is provided by highly optimised code that just gets the job done.

Am i correct in my assertions ??

[Benjamin van der Veen]

On Jan 23, 2011, at 6:31 AM, ged...@gmail.com wrote:

> Ok so the httpmachine is based on c code.

HttpMachine is a C# library. It uses Ragel to generate a state machine. Ragel supports several other languages (including C), so it would be easy to port HttpMachine to any language supported by Ragel.

> this all sounds very much like NodeJS. By this i mean that you code in c#, but the underlying performance and good stuff is provided by highly optimised code that just gets the job done.

It's somewhat similar, but Kayak is largely implemented in C#. It will be possible to have an unmanaged IO loop however (node also takes this approach).