Merge streams handling code for http2 streams & net.Socket

[addaleax]

Hey :)

It would be great if we could unify all the code from net and http2 that is only concerned with pushing data to/from the underlying stream, ideally into a common base class of net.Socket and Http2Stream, so that we could also maybe port some of the other native streams (zlib, fs) to using StreamBase on the native side & generally just share a lot of code.

This is probably not an easy task, and probably not doable in one pass, because the http2 and net implementations are always just slightly different, but if anybody wants to try to start working on this, feel free to reach out by commenting here.

[inidaname]

Hello
@addaleax I will like to take this up, if you point me to the right files
Thank You

[apapirovski]

@addaleax Are you sure this is a good first issue? This relies on knowledge of both JS & C++, and pretty good grasp of Node streams, net & http2. I would keep it as help wanted but can't imagine someone would want to start contributing with this particular issue.

[addaleax]

@apapirovski Yeah, I would talk with people who volunteer for it in more detail about that :) Then again, this doesn’t really require C++ knowledge, although that’s certainly helpful – it’s only about refactoring the JS, as the C++ parts should be identical between those two systems…

I’ve removed the label for now.

@inidaname The relevant code is in lib/net.js and lib/internal/http2/core.js. As a start, you might want to just try to make _write look identical for both of these, so that they can be merged into being the same function.

I think we’d want to create a new file internal/ for a resulting new base class, but that doesn’t have to happen right now.

[inidaname]

@addaleax Okay thank you

[SirR4T]

Hi @addaleax : would like to take a shot at this, though would need some beginner help too.

For instance, _write in lib/internal/http2/core.js seems to use LibuvStreamWrap, whereas in lib/internal/net.js, it seems to use fs.write(). Is the intent of this issue to change lib/internal/net.js 's _write to use LibuvStreamWrap instead?

[addaleax]

would like to take a shot at this

@SirR4T Sure! But maybe take a different bit of the code, unless @inidaname says that they aren’t working on it anymore.

For instance, _write in lib/internal/http2/core.js seems to use LibuvStreamWrap

Well, the underlying stream isn’t a LibuvStreamWrap, it’s an Http2Stream – that shouldn’t matter in practice, because both of these C++ classes use a common interface, which is exposed via the StreamBase class. (Side note: You probably don’t have to modify C++ for this in any way.)

whereas in lib/internal/net.js, it seems to use fs.write().

The code from lib/internal/net.js isn’t what I’m thinking about – it can probably stay as it is.

For net.Socket, the main implementation of _write() and _writev() can be found in lib/net.js and looks a lot more similar to what’s used in lib/internal/http2/core.js.

Is the intent of this issue to change lib/internal/net.js 's _write to use LibuvStreamWrap instead?

There’s quite a few common pieces between lib/net.js and lib/internal/http2.js that just deal with how the StreamBase C++ API is matched to the “normal” Node streams API.

_write() and _writev() are part of that, but there is other code (e.g. onread in lib/net.js and onStreamRead in lib/internal/http2/core.js) that could also be merged. Maybe take a look at that first? It’s going to be trickier than the write functions, but I hope it’s independent enough for that to work.

If that sounds like a lot, or turns out to be too tricky: A first part of this might be getting rid of the _socketEnd event in lib/net.js. It should be possible to figure out in onread whether self.destroy() should be called or not, based on the writable state of the stream, so we don’t need to create an event listener in afterShutdown. I think this is essentially being done in #19241

[inidaname]

Hello @addaleax
Thank you for the chance but I guess @SirR4T understand the direction been battling with other projects for sometime will be okay if you can take it up
Go for it.

[addaleax]

@SirR4T Are you still interested in this?

[SirR4T]

I am, but looks like I may be out of my depth here. Maybe further hints might help? Or I'll try my hand at other issues first.