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.
