11/20/2012 8:26 AM, Andrei Alexandrescu пишет:
On 11/19/12 3:38 PM, Tyler Jameson Little wrote:
I'd like to see an HTTP module in Phobos, but I wanted to gauge interest
first and see if this has been discussed before.
I can say the following. We sorely need a server expert on board with
the time and inclination to write a good server-side networking
framework. We have a couple, but for various reasons I have been unable
to convince them (through newsgroup and private exchanges) to invest
time in such an endeavor. That's mostly because lack of time - speaking
for myself, I wish I found the time to learn about all that, which as
far as I understand gravitates around notions such as asynchronous I/O,
libevent/libevt, select(), and the such. I've never used them so I'd
need to start from scratch.
Having done quite some work on this before - both with frameworks and
barehanded. The recipe for scalable and fast server itself is not that hard:
asynchronous I/O
+ event-based notification
+ separate thread pool for user-defined handlers
Asynchronous I/O is well understood to have far less overhead then
thread per client/descriptor model. Both in terms of memory usage and
time spent on the context switching.
Event based notification can be traded for select() polling but then
you'd waste a lot of cycles (in kernel mode) walking through huge
descriptor sets when number of simultaneous clients is high enough.
A separate "worker" thread pool insures your event-loop is not ever
blocked thus insuring responsiveness w.r.t dispatching I/O requests.
Arguably this could be an opt-in.
If this combo is implemented even half-decently it should give us great
speed. The fine-tuning and topping the performance however is the other
70% of work and that makes the real difference. The devil is in the
details. Not to mention fiddling with socket options and imposing limits
on transfer rate/timeouts etc.
I currently had to work with Java (a painful journey after D) to create
a couple of server components and surprisingly found the Netty project
to be quite nice.
Though being overly Java-escue it has some great ideas (aside from the
above basic concepts):
- The composable pipeline abstraction that allows passing user data
through a series of transformations seamlessly. Think the stack of
TCP|HTTP|encryption/compression or TCP|framing|ProtocolBuffers etc.
- Flexible and zero-copy (quite hard for Java I guess) buffer
abstraction. It reminds the power of ranges but in a heck of a more
limited scale - it's more about chaining and slicing. These limitations
are mostly because of the way the OS works.
We really need an expert. Look at the Go programming language - it's not
remarkable, but it benefits of full-time dedication of experts in
server-side programming, so it has acquired excellent library support
for networking servers.
Can help with a proper asynchronous (network) I/O support on Windows. I
doubt I'll find time to flesh out the whole design though.
What it irks me that I haven't seen a good enough backend for Windows in
the open source (of those I've peeked at the source of). A lot of
event-based backends seem to just ignore this OS or fallback to
select-loop.
Meanwhile M$ introduced the new RIO socket API targeted at high-load
servers. Was planing to try it out since the day it was introduced.
And they milk that for all it's worth: any
discussion, article, or blog post about Go gravitates toward the
five-lines HTTP server with the same implacable reach as conversations
with ideologists, which inevitably converge towards their ideological
stronghold.
I see no reason we can't beat them in their favorite game.
--
Dmitry Olshansky
