November 20, 2012
On Tuesday, 20 November 2012 at 03:49:57 UTC, Tyler Jameson Little wrote:
> Would a minor refactor of vibe.d be acceptable? This is pretty much what I'm looking for:
>
> https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/http/common.d
> https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/http/server.d
>
> Except that I'd remove some parts of it, like JSON parsing.
>
> I think that vibe.d could benefit from moving some of the code there into Phobos. I guess it comes down to whether it makes sense to make a standard HTTP library.

BTW, the actual JSON module in viba.data.json in richer in functionality and easier to use than the one in std.json. The module has virtually no dependency on other parts of vibe.d. I whish it was also moved to Phobos or at least inspired a refactoring of std.json.

Nicolas


November 20, 2012
On Tuesday, 20 November 2012 at 04:26:02 UTC, Andrei Alexandrescu wrote:
> We sorely need a server expert on board with the time and inclination to write a good server-side networking framework.

I agree with this but it really should be generic; working at probably the file descriptor level, so we can do whatever protocols along with files, pipes, ... and ideally, any kind of injected event. I'd really like it if we could run one event loop and be able to do keyboard/joystick input, timers, GUI, threads, etc., including third party libraries, as well as networking. (Combining two different event loops is a pain in the butt.)

I have an implementation in mind (I'd use select() because I don't know libev, but we should be able to change that without changing the interface)...

... but I'm behind on my other work and have yet another deadline looming so can't do it myself right now. I can't wait till I'm retired!

> 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.


You know, I'll never understand this. Anybody can do a five line http server. Hell, with my lib:

import arsd.cgi;
void hello(Cgi cgi) { cgi.write("hello!"); }
mixin GenericMain!hello;


Look, tiny http server (on port 8080)! Also works as cgi, fastcgi, scgi, and easy command line testing with a different compile option.

But not really that special language wise... yay, you can call a library function. Who can't do that?
November 20, 2012
On Tuesday, 20 November 2012 at 12:12:27 UTC, Nicolas Sicard wrote:
> On Tuesday, 20 November 2012 at 03:49:57 UTC, Tyler Jameson Little wrote:
>> Would a minor refactor of vibe.d be acceptable? This is pretty much what I'm looking for:
>>
>> https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/http/common.d
>> https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/http/server.d
>>
>> Except that I'd remove some parts of it, like JSON parsing.
>>
>> I think that vibe.d could benefit from moving some of the code there into Phobos. I guess it comes down to whether it makes sense to make a standard HTTP library.
>
> BTW, the actual JSON module in viba.data.json in richer in functionality and easier to use than the one in std.json. The module has virtually no dependency on other parts of vibe.d. I whish it was also moved to Phobos or at least inspired a refactoring of std.json.
>
> Nicolas

vibe.d is MIT licensed. (Like almost every other WEB related library) Guess you have to ask Soenke for a permission.

November 20, 2012
On Tue, Nov 20, 2012 at 03:09:23PM +0100, Adam D. Ruppe wrote:
> On Tuesday, 20 November 2012 at 04:26:02 UTC, Andrei Alexandrescu wrote:
> >We sorely need a server expert on board with the time and inclination to write a good server-side networking framework.
> 
> I agree with this but it really should be generic; working at probably the file descriptor level, so we can do whatever protocols along with files, pipes, ... and ideally, any kind of injected event. I'd really like it if we could run one event loop and be able to do keyboard/joystick input, timers, GUI, threads, etc., including third party libraries, as well as networking. (Combining two different event loops is a pain in the butt.)

The event loop itself should be a generic component in Phobos, not specific to anything else. It should work at the file descriptor level, perhaps even combining with signal handling (using the self-pipe trick), and handle timers and scheduled events as well. Everything else should be pluggable into this generic module.

I have written such things before in C/C++, but in D this will be much easier to implement, thanks to delegates (which make writing event-loop based programs so much less painful).

Having a standard event loop will make it much less painful to integrate many components together in a seamless way. Combining two event loops, as Adam says, is a royal pain in the neck. Making the generic event loop a Phobos standard will eliminate this problem.


> I have an implementation in mind (I'd use select() because I don't
> know libev, but we should be able to change that without changing
> the interface)...

The interface should be generic enough that you don't have to worry about whether select or poll (or whatever the windows equivalent is) is used. I think it's a good idea to implement the select version first, as that's generic across Posixes, whereas libev is Linux-specific IIRC.


T

-- 
2+2=4. 2*2=4. 2^2=4. Therefore, +, *, and ^ are the same operation.
November 20, 2012
> whereas libev is Linux-specific IIRC.

Libev is a polling abstraction. It has select, epoll and kqueue backends (and there may be others I don't know about). So it is particulary useful for unices, where epoll (linux) and kqueue (OSX and BSD) are preferred async IO mechanisms. It can also be used on Windows, but with the select() backend, which doesn't scale well with many file descriptors. select() is also limited to 64 file descriptors by default on windows IIRC (that limit can be raised, but only to 4096 if I am not mistaken).


November 20, 2012
On Tuesday, 20 November 2012 at 15:21:12 UTC, H. S. Teoh wrote:
> It should work at the file descriptor level, perhaps even
> combining with signal handling (using the self-pipe trick)

I was thinking we'd send pointers and a type hash through a pipe. It'd keep the read/write very simple.

Now, the event data must be defined to be transient, unless specifically told otherwise (e.g. immutable types), because then we can reuse the data structures to avoid allocations.

But take a gander at this:
http://arsdnet.net/dcode/typehash.d

We can take any type tuple, do a mangle of and get a unique
name for any combination of arguments. Then hash it, and we
have a nicely unique, fixed size message to send down the pipe.


One one end, we'll cast to a void* and send that along with the hash.

On the other side, only listener functions who's ParameterTypeTuple matches the typehash will receive a message. They can then cast the void* back to the argument type with confidence.



This lets us define custom messages as plain types:

struct MyMessage {
   string text;
}


event.listen((MyMessage m) { writeln("Received: ", m.text); }
event.send(MyMessage("hello!"));

event.loop(); // we should receive the message and call the above func



If there's no listener that matches the hash, we ignore the message. Now there'd be some care needed to not send pointers to stack data down the pipe, as that could be destroyed, but eh.

Some details gotta be worked out but I really like the idea of using type names like this.
November 20, 2012
On Tuesday, 20 November 2012 at 16:09:37 UTC, Adam D. Ruppe wrote:
> But take a gander at this:
> http://arsdnet.net/dcode/typehash.d

I have such a hard time focusing on work when there's something like this to play with.... updated the link to show the concept actually working, not just hashing.

All event listeners must take exactly one argument and it is all statically typed, but it works and can do the hash+pointer message.

The hash function down there is borrowed from druntime. I couldn't find it accessible as a stdlib import so I copy/pasted. But ignoring that, the rest is actually simple code.


Problem is  this probably isn't @safe... and might not be @trusted either because you can send stack info.. maybe we could do further constraints, or copy the data into a queue, or something. I really think we could make it work though and it'd be pretty cool.
November 20, 2012
On Tuesday, 20 November 2012 at 12:12:27 UTC, Nicolas Sicard wrote:
> BTW, the actual JSON module in viba.data.json in richer in functionality and easier to use than the one in std.json. The module has virtually no dependency on other parts of vibe.d. I whish it was also moved to Phobos or at least inspired a refactoring of std.json.
>
> Nicolas

I have not yet looked at the vibe.d JSON yet, but I certainly will. I agree with you that the std.json could use some improvement, it's not all that fun to use that's for sure.

--rt
November 20, 2012
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
November 20, 2012
11/20/2012 11:45 PM, Dmitry Olshansky пишет:
[snip]


> 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.

The obligatory link: https://netty.io/

-- 
Dmitry Olshansky
1 2
Next ›   Last »