Introducing vibe.d!

[Sönke Ludwig]

Am 27.04.2012 10:10, schrieb Dmitry Olshansky:
> On 27.04.2012 0:46, Sönke Ludwig wrote:
>> During the last few months, we have been working on a new
>> framework for general I/O and especially for building
>> extremely fast web apps. It combines asynchronous I/O with
>> core.thread's great fibers to build a convenient, blocking
>> API which can handle insane amounts of connections due to
>> the low memory and computational overhead.
>>
>> Some of its key fatures are:
>
> In short: meet the new boss of the web development :)
>
> Few things I think worth looking at.
> 1. Add cool auto-magic API generator in Adam's style:
> route.wrapModule!(module_name)("/url");
> The effect is that it "binds" /url/function_name for each function found
> in module, automatically gets parameters from post (or get) using
> arguments names of function. Last but not least it issues necessary
> calls to std.conv.to as needed.
> Ah and the result is again converted to string (if needed) and packed
> into response body.
>
> Example:
> module factorial;
>
> long fact(int k)
> {
> return k > 1 ? k*fact(k-1) : 1;
> }
>
> Wrapped via wrapModule!(factorial)("/"); will work as
> /fact?k=10 will out the result in plain-text. MIME type and conversion
> should be configurable of course.

Now on the TODO list!

>
> 2. By the very nature of your framework you should be well prepared to
> small-scale DDoS attacks. But there is much more in DoS assortment these
> days. It would be shame if your framework doesn't handle e.g.
> slow-writer attack. Imagine attacker spoon-feeds HTTP request to your
> server by 1 byte per 10msec. Bump simultaneous request count to few
> thousands and your nice event loop freezes to a crawl. You gotta check
> upload rates ;)
>

There is already a HttpServerOptions.maxRequestTime that would help - 
but this is currently still ignored. Also, keep-alive connections are 
kept open too long right now. But both is on the list.

Maybe something like a LRU limiter that closes old connections in case 
of too many open connections would also be a good alternative barrier...

My plan is also to switch all modules to @safe as soon as Phobos and 
Druntime have a bit better support. I guess this is type of application 
can be considered the prototype for which SafeD is useful.