Custom uv_stream_t implementations

[jnicholls]

libuv should add a stream interface to allow developers to add their own uv_stream_t types, in order to build pluggable steams directly on top of the friendly libuv interface. This way, if someone wants to create a TLS stream for example, they can do so and consume that stream exactly the way they would consume a TCP stream for example. This would greatly help the libuv ecosystem, solve the TLS gap, yet not fill that gap by relying directly on a particular TLS implementation.

Apologies if this is a dupe.

[coderkevin]

I've also been looking into using libuv in some new and interesting ways, and am staring at all the special case handling in stream.c and other places. It looks like the stream type inheritance is implemented data-wise, but not code-wise. I think some well-placed function pointers could really make the streams extensible. Maintainers, would you like to chime in on something like this? I bet it could be done incrementally, but ultimately we would be talking about some fundamental refactoring here.

[saghul]

What things would you need? Do you have any concrete proposal in mind? At a quick glance I see 2 types of possible extensions:

• extending an existing stream: TLS on top of TCP, for example
• new streams: a file i/o stream, for example

The first type is already possible, but the second not so much, is this what you have in mind?

[coderkevin]

I'm more interested in something like the second one. I'm actually investigating this for a work project. We need a platform abstraction layer we could use in embedded and desktop environments. This would include Windows, Linux, QNX, and potentially RTOSes like SYS-BIOS and others. Part of this would include streams that represent inter-processor communications for multi-core devices (e.g. from the main ARM to a DSP or auxiliary core). On the more experimental side, we are also looking to try out async audio, and if the streams were extensible enough, we would use it. Also, in a few cases, it could make sense to have an in-process memory stream.

At any rate, most of these streams wouldn't make much sense to code directly into libuv. However, loading them as shared libraries would work very nicely. We're prepared to do a good amount of work here with libuv as the basis of our platform abstraction layer, but I'm looking to work with you to see how much of this could be given back to benefit libuv.

I've been looking at this the last few days and have the beginnings of a proposal. Please let me know your thoughts:

1. Add ability in libuv to load stream modules from shared libraries.
2. Each custom stream type would need to somehow append to the UV_HANDLE_TYPE_MAP
3. Add function pointers to the uv_stream_t structure to do the work of uv__stream_open, uv_udp_open, etc. This could also help break up some of the stream-dependent code that exists in stream.c. This may be able to be done incrementally.

I am willing to whip up a prototype for this to see what it would look like.

There's only one thing I'm still not sure of. For certain stream types, the fd and flag parameters may not apply. I wonder if that could be fully encapsulated in the separate functions for each stream or if there are pitfalls I'm not aware of.

[jnicholls]

Both of those use cases.

You say the first is possible, but that's not really true. For example
with TLS on top of TCP, I would expect to be able to use uv_write to write
plaintext data to a uv_tls_t stream type, and under the hood the data is
encrypted and written to the TCP stream.

To achieve that, we would need deeper integration into libuv. The idea
here is to create new stream types (whether they ride on top of existing
types or not) and use the standard read/write stream APIs directly. In
other words, no wrappers.

On Friday, March 20, 2015, Saúl Ibarra Corretgé notifications@github.com
wrote:

What things would you need? Do you have any concrete proposal in mind? At
a quick glance I see 2 types of possible extensions:

• extending an existing stream: TLS on top of TCP, for example
• new streams: a file i/o stream, for example

The first type is already possible, but the second not so much, is this
what you have in mind?

—
Reply to this email directly or view it on GitHub
#275 (comment).

Sent from Gmail Mobile

[deleisha]

Tend to have the same feeling as @jnicholls.

Though we can write wrappers like uv_tls_write, which is done at libuv-tls . Having uv_write to handle a pluggable handle will be great.
Last time when I tried, It asserted somewhere on the type of stream,

Currently, in case of OpenSSL, Intergrating it with libuv is easy with BIO pair.
But other SSL engine which does not have BIO like facility will not be easy.

If we have a pluggable stream type, which module writer to take care of uv_read_start and uv_write
might help.

[saghul]

I've been looking at this the last few days and have the beginnings of a proposal. Please let me know your thoughts:

1. Add ability in libuv to load stream modules from shared libraries.
2. Each custom stream type would need to somehow append to the UV_HANDLE_TYPE_MAP
3. Add function pointers to the uv_stream_t structure to do the work of uv__stream_open, uv_udp_open, etc. This could also help break up some of the stream-dependent code that exists in stream.c. This may be able to be done incrementally.

At a first glance that sounds like a lot of internal changes. Here is a counter proposal:

1. Add a new "custom" stream type, which takes a few function pointers to fo the reading and writing.
2. Make uv_read_start and uv_write dispatch to the right place based on the stream type.
3. Profit?

This is at a back-of-a-napkin-design-level. If you want to pursue this you'll need to write a LEP (https://github.com/libuv/leps) and be ready to provide an implementation with tests.

[jnicholls]

I think that proposal is fine and the appropriate step to take that doesn't affect current streams. If it's implemented correctly, it would be the basis for migrating existing streams over to it. Having that in place is half the work.

[txdv]

saghuls approach sounds easier to implement, is anyone up for writing a lep?

[coderkevin]

@saghul , I like your proposal, it would definitely be less intrusive that my original proposal. I also agree with @jnicholls , that this could the the basis for a larger internal refactoring if so desired later on. I'm all for incremental steps.

I'm willing to start the process here and write a LEP, although I've never done this and probably don't know what I'm in for. However, I've been wanting to get more involved in open-source--looks like this could be a good opportunity.

[saghul]

@coderkevin great! You can check the example LEP and the ones sent as pull-requests.

[deleisha]

@coderkevin, If you need a hand. Please let me know. Would be happy to dirty my hand with this.

[coderkevin]

Thanks @deleisha. I'll get started and let you know when I have something to review.

[coderkevin]

I have submitted a PR for the Custom UV Streams LEP. It's the first draft, so please look it over and let me know what is missing or wrong. Thanks!
libuv/leps#7