HTTP/2 server-initiated streams

sbordet commented 8 years ago

It would be nice if the HTTP/2 implementation supported server-initiated streams to a client, after the connection prefaces have been exchanged.

A quick look at what this would require is:

to emit a "ready" event after the preface has been successfully received (both on client and on server). This would allow a server to know the first available moment to initiate a stream towards the client.
to handle server-initiated streams in HTTP2ClientSession.onHeaders(), as currently they are dropped. The implementation would be trivial and basically be a copy of what the server does.

chanh1964 commented 5 years ago

Hi all,

How is this thread going?

I'm currently working on Adaptive Streaming over HTTP/2, in which the video is split into multiple 1-second segments; the client only needs to request for the very first segment and the server will periodically push the rests. In this case, the server needs to initiate a stream for each segment to push the it to the client.

At this point, I'm still struggling with how to create a server-initiated stream. I hope I can receive some suggestions. The Jetty version I use is 9.4.x

Thank you in advance.

gregw commented 5 years ago

Shouldn't server initiated streams be done via push promises so that any intermediaries will understand what is going on? For @chanh1964's video example, the client needs to make a request to the server, which will then be held pending a response.... during which time push promises can be made every second to send more content. The question is, will this be sufficient to stop the initial request stream from idling out?

chanh1964 commented 5 years ago

@gregw Thank you for your response.

Shouldn't server initiated streams be done via push promises so that any intermediaries will understand what is going on?

Hmm, I'll investigate this part to understand the flow behind.

For the suggestion that push promises be made during the pending of the first response, I've already done that to test whether the push feature can be applied to video stream, which was then successful, but just for a few first segments. However, the video contains >700 segments so I think this won't be a good strategy.

Also I think I'll need to explain more about Adaptive Streaming. In Adaptive Streaming, a video has multiple quality versions and in each version it is split into multiple short segments. Then, an algorithm run at the client side will periodically monitor the network condition, based on which request the next video segment with the suitable quality version. Most of the big streaming services are now using this mechanism (but in HTTP/1.1). So, considering your suggestion, in HTTP/2, let's say if we can send push promises for all the remaining segments during the pending of 1st request, the video will stay at 1 quality version only, which will cause problems if the network doesn't meet the requirements at some moment.

sbordet commented 5 years ago

The original goal for this issue was to allow true server-initiated streams, since the http2 protocol, after the preface, is symmetric.

sbordet commented 5 years ago

Regarding adaptive streaming, the client could make a request and the server reply with a response for low-res, a push promise for mid-res, and a push promise for hi-res. It could then interleave content until the client knows what's the best resolution, at which point the client cancels the other streams.

gregw commented 5 years ago

@sbordet I'm dubious any client will allow a server to open a stream without a prior push promise!

sbordet commented 5 years ago

@gregw our low level http2 client could.