RejectedSoftware Forums

Am 14.02.2018 um 00:08 schrieb FraMecca:

Reading about the http2 support for vibe proposed on GSoC 2018 I was wondering what is the status of the http2-botan branch on the official vibe.d repo and if it is abandoned.

Supposing a group of person needs to tackle the problem of http2 support, could they start from there?

The http2-botan-cleanup branch is the one that is closest to being ready
to merge into master. However, it generally suffers from two major
issues. Firstly, it simply performs a huge amount of changes, including
refactoring and API changes, in a single step, which makes it de-facto
impossible to review, and then it also contains code from another
library, with a different license, which I'd really like to avoid.

Nowadays, there is also the plan to redesign the HTTP module in general
to remove performance bottlenecks, especially those that ironically
surfaced with the new vibe-core module, which is actually designed to
improve performance.

For these reasons it is unlikely at this point that the branch will ever
be merged. Instead, the redesigned HTTP module will be built for HTTP/2
from the ground up. For now I have added some very basic design
considerations: https://github.com/vibe-d/vibe-http/wiki

Am 16.02.2018 um 01:38 schrieb gallafrancesco:

FraMecca and I are two students from University of Turin, Italy. We would like to have HTTP/2 support built inside vibe.d and contribute to it, even if it means working on a design of the whole HTTP module.

Nowadays, there is also the plan to redesign the HTTP module in general
to remove performance bottlenecks, especially those that ironically
surfaced with the new vibe-core module, which is actually designed to
improve performance.

For these reasons it is unlikely at this point that the branch will ever
be merged. Instead, the redesigned HTTP module will be built for HTTP/2
from the ground up. For now I have added some very basic design
considerations: https://github.com/vibe-d/vibe-http/wiki

We would like to know if it is actually possible to start working on this, and if so, if you or someone else is already on it.

Could you give us a more detailed explanation of your design from the vibe wiki?

On Wed, 14 Feb 2018 10:08:22 +0100, Sönke Ludwig wrote:

Am 14.02.2018 um 00:08 schrieb FraMecca:

Reading about the http2 support for vibe proposed on GSoC 2018 I was wondering what is the status of the http2-botan branch on the official vibe.d repo and if it is abandoned.

Supposing a group of person needs to tackle the problem of http2 support, could they start from there?

The http2-botan-cleanup branch is the one that is closest to being ready
to merge into master. However, it generally suffers from two major
issues. Firstly, it simply performs a huge amount of changes, including
refactoring and API changes, in a single step, which makes it de-facto
impossible to review, and then it also contains code from another
library, with a different license, which I'd really like to avoid.

Nowadays, there is also the plan to redesign the HTTP module in general
to remove performance bottlenecks, especially those that ironically
surfaced with the new vibe-core module, which is actually designed to
improve performance.

For these reasons it is unlikely at this point that the branch will ever
be merged. Instead, the redesigned HTTP module will be built for HTTP/2
from the ground up. For now I have added some very basic design
considerations: https://github.com/vibe-d/vibe-http/wiki

So basically so far there is just the design constraints from the wiki
and the existing API as a guide for the new design. The new high level
API should be as compatible as possible to the old one, from the typical
library user's point of view, while the a low-level API can be freely
redesigned for minimal overhead.

There could also be an alternative high-level API, such as something in
the direction of the HTTPInterchange draft in the wiki, but I'd see
that as something that only makes sense if the existing approach shows
severe weaknesses in a certain area. Otherwise that would be a topic for
a 2.0 version.

How all of this translates into a concrete design is yet to be
determined and would be part of the process. Unfortunately my priorities
are currently (for the next few months) forced to be more or less
focused only on our internal project, so that I have very little time
left to invest into this. Depending on your time constraints I could try
to squeeze out a little dedicated time per week, though, because this
really is something that I'd like to see materialize sooner rather than
later.

I could also try to commit a very basic code skeleton that accepts
connections, including the TLS based HTTP version negotiation, so that
there is something to start from.

On Sun, 18 Feb 2018 10:46:44 GMT, gallafrancesco wrote:

I could also try to commit a very basic code skeleton that accepts
connections, including the TLS based HTTP version negotiation, so that
there is something to start from.

Can you give us the code skeleton for reference?
We are eager to try and to take on the challenge to rewrite the api given your guidelines.
At this point we can analyze your code and come up with a draft of the new API for a further discussion.

It's not written yet and I'm currently having trouble allocating the time for it, but if you want to start now, I'd just recommend to maybe take the basic listenHTTP code (plus HTTPListener etc.) and start to implement the low level API from there (pulling bits out of the old code as necessary).

I would try my best to offer timely feedback (maybe we can open a channel on the dlang Slack for that, or I could create a separate forum). But you should be willing to potentially reshape the API during the process, as I'm sure that part of the design process will only become clear after the first code has been written.

But I'll commit at least the package skeleton later today, so that the repository can be used for development.

Regarding your wiki, there's a point which states:

no stream proxy objects or dynamic dispatch by default - all combinations of
encryption/encoding/compression streams must be instantiated as static types

• need to keep in mind how to minimize the amount of template bloat this produces

Do you have any example of this in the current vibe implementation?

InterfaceProxy is the main offender in that regard. It currently still needs to be used in a few places in the HTTP module, because the code previously relied on streams being class objects and thus supporting efficient dynamic dispatch by nature. Since the new streams from vibe-core are usually structs now, this rather ineffcient workaround is needed.

The goal would be to only store concrete (template instance) types, or at least to not perform any dynamic dispatch in potential hot code paths.

However, there is at least one place where this will still be necessary in the high level API, HTTPServerResponse.bodyWriter. Instead of InterfaceProxy, I'd use asInterface there to avoid its additional wrapper layer.

On Mon, 19 Feb 2018 20:03:09 +0100, Sönke Ludwig wrote:

Okay, now there is a very basic start in the repository:
https://github.com/vibe-d/vibe-http

Thank you for your help. We'll start working on it, forking your repo and committing the first changes this week. Hopefully we will be able to provide you with some documentation as well, so that you can review our design.

In the meantime, we are fine using Slack, so if you are interested in creating a new channel we'll keep you updated from there.

On Wed, 21 Feb 2018 13:01:20 GMT, gallafrancesco wrote:

We have another question regarding this specification in the wiki:

support letting a connection "sleep" (no task allocated while waiting for the next request)

For this reason we were thinking of an event based approach that leverages the existing listenTCP function that currently states:

• 'connection_callback' will be called for each client that connects to the server socket. Each new connection gets its own fiber. The stream parameter then allows to perform blocking I/O on the client socket.

If the callback can be called every time the socket is triggered (instead of just "new connection event") there is no need to keep a task allocated while waiting for new data.
This means exposing an API to add events to the event loop or adding every socket that gets accepted to the event loop and removing it accordingly.

Do you think this is the right approach? Did you have something else in mind?

What I had in mind was a new method TCPConnection.waitForDataAsync(void delegate(bool)) that would work just like waitForData, just that it doesn't call asyncAwaitAny, but instead directly calls eventDriver.sockets.read and performs the rest of the functionality from the passed callback (which would be called as runTask(callback, ...)).

With this, the connection handler could then simply call waitForDataAsync after handling all immediately available requests and can then return to the caller immediately. The internal reference counting should make sure that the connection stays alive as long as necessary.

This would only be implemented for vibe-core, we don't have to care for backwards compatibility with vibe-d:core.