Jeroen, my understanding of video streaming protocols that use video fragments is that the client should be in control of which segments to select next because it may decide that it needs a higher/lower resolution version, so it may switch to a different version of the stream.
Moreover, there is no great advantage in a server pushing the next fragment, because the time to play the current segment is almost always going to be longer than the round trip time to request the next segment. Thus all pushing a segment will do is to send the segment to the client before it actually needs it. It may actually want to pause, skip, rewind or change resolution. So given that there is no latency penalty from a users point of view, it is better to just let the client ask for the next segment. HTTP2 does allows streams to be reset. Give us more info about how/when you want to do that and we'll see if we can provide and API. On the server-side HttpTransport#abort() will translate into a reset. cheers On 4 February 2015 at 20:40, Jeroen van der Hooft < [email protected]> wrote: > Hello Simone and Greg, > > Thank you for your response. I understand that a new stream is created and > assigned to each of the pushed resources, and that there is no sequential > requirement from the HTTP/2 point of view. However, in a use case where > video segments are pushed (e.g. as soon as they are available in a live > stream scenario), consecutive segments should be pushed in the right order. > I made sure this is the case by checking if there are no active, open push > streams before calling the push function in HTTPTransportOverHTTP2. Of > course, it would be nice to know if there are other ways to achieve this > behaviour. I was considering a priority based mechanism at one point, could > you elaborate on why this could lead to flaws from a server point of view? > > Also, I was wondering if there is a way to cancel a started, open push > stream? Let's say the server is pushing a large resource A, and logic > dictates that at one point it is better to stop sending this resource and > move on to resource B? As far as I observed, streams are only cancelled if > a timeout exception occurs (default is 15s), but there is not yet a > possibility to cancel a stream from e.g. the HTTPTransportOverHTTP2 class. > > Kind regards, > > Jeroen van der Hooft > > On 2015-02-03 23:54, Greg Wilkins wrote: > > Jeroen, > > the push mechanism creates new streams in the multiplexed connection for > each of the pushed resources. This is explicitly so that they can overtake > each other and there is no sequential requirement. > > In HTTP2, it is the priority mechanism that might be able to set some > kind of sequential relationship between resources, but that comes from the > client and is only advisory. Plus Jetty currently does not implement > priority and probably will not due to flaws with it from a server > throughput point of view. > > There is actually no way I can think of in HTTP/2 to maintain strong > ordering between resources - pushed or requested. > It would be good to know your use-case for this. > > cheers > > On 16 January 2015 at 19:26, Jeroen van der Hooft < > [email protected]> wrote: > >> Hello all, >> >> I have been using a customized version of Jetty 9.3.0 to enable the >> pushing of content from server to client, using HTTP/2-14. I have done some >> preliminary experiments, and noticed that when pushing resources a, b and c >> from the resource handler: >> >> baseRequest.getHttpChannel().getHttpTransport().push(a); >> baseRequest.getHttpChannel().getHttpTransport().push(b); >> baseRequest.getHttpChannel().getHttpTransport().push(c); >> >> It is possible that resource b is pushed before a, or resource c is >> pushed before a or b. How can I make sure that resources are pushed >> sequentially in the current HTTP/2 implementation? >> >> Kind regards, >> >> Jeroen van der Hooft >> _______________________________________________ >> jetty-users mailing list >> [email protected] >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> https://dev.eclipse.org/mailman/listinfo/jetty-users >> > > > > -- > Greg Wilkins <[email protected]> @ Webtide - *an Intalio subsidiary* > http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that > scales > http://www.webtide.com advice and support for jetty and cometd. > > > _______________________________________________ > jetty-users mailing [email protected] > To change your delivery options, retrieve your password, or unsubscribe from > this list, visithttps://dev.eclipse.org/mailman/listinfo/jetty-users > > > -- > Jeroen van der Hooft > Department of Information Technology > Internet Based Communication Networks and Services (IBCN) > Ghent University - iMinds > Gaston Crommenlaan 8 (Box 201), B-9050 Gent, Belgium > T: +32 (0)9 33 14942; T Secr: +32 (0)9 33 14900 > F: +32 (0)9 33 14899 > E: [email protected] > W: www.ibcn.intec.UGent.be > > > _______________________________________________ > jetty-users mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins <[email protected]> @ Webtide - *an Intalio subsidiary* http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales http://www.webtide.com advice and support for jetty and cometd.
_______________________________________________ jetty-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
