Is there interest in a std.http?

[Dmitry Olshansky]

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