You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ah for http1... Well, not necessarily. We could actually implement an Http1Application in core that could engage the native parser at that level, before data flows into js
Activity
ronag commentedon Aug 8, 2020
@jasnell: Will quic sockets support the consume/unconsume API that net/tls sockets support?
jasnell commentedon Aug 8, 2020
Not sure which consume/unconsume API you mean
ronag commentedon Aug 8, 2020
The node core HTTPParser has a
consumemethod that can take a socket handle. See, https://github.com/mcollina/undici/blob/master/lib/client.js#L719-L725.This allows the socket to send data to the parser without doing a native->js->native roundtrip.
jasnell commentedon Aug 8, 2020
Ah... Yeah totally different model. It will fully consume a UDPWrap but the model is completely different in terms of how it does so
ronag commentedon Aug 8, 2020
Then I guess the native-js-native roundtrip is the only way.
jasnell commentedon Aug 8, 2020
No, in quic, all of the actual data flow is at the native layer. Data only comes to js via a QuicStream.
ronag commentedon Aug 8, 2020
Yes, I mean we will have to go from quic native layer -> js (QuicStream) -> native http parser
jasnell commentedon Aug 8, 2020
Ah for http1... Well, not necessarily. We could actually implement an Http1Application in core that could engage the native parser at that level, before data flows into js
jasnell commentedon Aug 8, 2020
As the implementation evolves, I plan to make it possible for native add-ons to create and register their own QuicApplication impls