Possible support for HTTP/2+SSE transport in CometD
115 views
Skip to first unread message
marekgregor
Oct 7, 2016, 3:41:32 PM10/7/16
to cometd-users
I have found that CometD doesn't support Server-Sent Events (SSE) because of connection opening cost: https://github.com/cometd/cometd/issues/272
Question 1.: Will CometD team reconsider support for SSE with combination of HTTP/2 ? Combination is explained in more detail here: https://www.infoq.com/articles/websocket-and-http2-coexist
I think this transport will be ideal for application where server to client direction of communication is pervasive.
Question 2.: If yes, do you have any rough plan when you will support this feature ?
Question 3.: Do you see any obstacles in these implementation from implementation point of view ? Some application servers (Jetty, Wildfly(Undertow) ...) already supports HTTP/2 - question is if it enough to implement functional SSE+HTTP/2 transport for CometD or we need to wait e.g. for Servlet API 4.0 implementation in application servers.
thanks for response
Marek Gregor
Simone Bordet
Oct 7, 2016, 4:15:43 PM10/7/16
to cometd-users
Hi,
On Fri, Oct 7, 2016 at 6:48 PM, marekgregor <marek....@gmail.com> wrote:
> I have found that CometD doesn't support Server-Sent Events (SSE) because of
> connection opening cost: https://github.com/cometd/cometd/issues/272
Yes.
> Question 1.: Will CometD team reconsider support for SSE with combination of
> HTTP/2 ? Combination is explained in more detail here:
> https://www.infoq.com/articles/websocket-and-http2-coexist
> I think this transport will be ideal for application where server to client
> direction of communication is pervasive.
It's not that simple.
Hello world examples may work fine, but the problem is to support all
those weird cases where the client or the server closes, or when they
just disappear.
For example we need to check if client closes are properly implemented
in HTTP/2 with a RST_STREAM.
If not, that's a problem. With HTTP/1.1 it is even more problematic.
SSE is not really a well designed protocol. Sure it's simple, but too simple.
The client still needs to ping the server to see if it's alive, even
if the data flows only from server to client.
This mechanism in Bayeux is carried by the /meta/connect messages.
With SSE we would need to open a new stream, and replace the previous
one, kinda like BOSH but with streams, not connections.
> Question 2.: If yes, do you have any rough plan when you will support this
> feature ?
No plans.
> Question 3.: Do you see any obstacles in these implementation from
> implementation point of view ? Some application servers (Jetty,
> Wildfly(Undertow) ...) already supports HTTP/2 - question is if it enough to
> implement functional SSE+HTTP/2 transport for CometD or we need to wait e.g.
> for Servlet API 4.0 implementation in application servers.
I think with HTTP/2 SSE may make more sense than with HTTP/1.1.
It's going to be some effort to implement, and I'm not sure what
benefits would bring to the table.
For example, deciding to implement WebSocket was easy because it had
so many benefits over HTTP.
It was a pain to implement and support because of browsers
incompatibilities etc, but it was worth the effort.
What would SSE bring to improve over WebSocket or even over plain HTTP/2 ?
I see nothing, so while the exercise to implement it may be
interesting, to me it does not have the appeal to do it.
I'm not rejecting it, but I need a strong reason to implement it.
If you want to contribute, I can definitely guide you.
--
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.
On Fri, Oct 7, 2016 at 6:48 PM, marekgregor <marek....@gmail.com> wrote:
> I have found that CometD doesn't support Server-Sent Events (SSE) because of
> connection opening cost: https://github.com/cometd/cometd/issues/272
> Question 1.: Will CometD team reconsider support for SSE with combination of
> HTTP/2 ? Combination is explained in more detail here:
> https://www.infoq.com/articles/websocket-and-http2-coexist
> I think this transport will be ideal for application where server to client
> direction of communication is pervasive.
Hello world examples may work fine, but the problem is to support all
those weird cases where the client or the server closes, or when they
just disappear.
For example we need to check if client closes are properly implemented
in HTTP/2 with a RST_STREAM.
If not, that's a problem. With HTTP/1.1 it is even more problematic.
SSE is not really a well designed protocol. Sure it's simple, but too simple.
The client still needs to ping the server to see if it's alive, even
if the data flows only from server to client.
This mechanism in Bayeux is carried by the /meta/connect messages.
With SSE we would need to open a new stream, and replace the previous
one, kinda like BOSH but with streams, not connections.
> Question 2.: If yes, do you have any rough plan when you will support this
> feature ?
> Question 3.: Do you see any obstacles in these implementation from
> implementation point of view ? Some application servers (Jetty,
> Wildfly(Undertow) ...) already supports HTTP/2 - question is if it enough to
> implement functional SSE+HTTP/2 transport for CometD or we need to wait e.g.
> for Servlet API 4.0 implementation in application servers.
It's going to be some effort to implement, and I'm not sure what
benefits would bring to the table.
For example, deciding to implement WebSocket was easy because it had
so many benefits over HTTP.
It was a pain to implement and support because of browsers
incompatibilities etc, but it was worth the effort.
What would SSE bring to improve over WebSocket or even over plain HTTP/2 ?
I see nothing, so while the exercise to implement it may be
interesting, to me it does not have the appeal to do it.
I'm not rejecting it, but I need a strong reason to implement it.
If you want to contribute, I can definitely guide you.
--
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.
marekgregor
Oct 10, 2016, 8:00:55 AM10/10/16
to cometd-users, sbo...@webtide.com
Hello Simone,
Dňa piatok, 7. októbra 2016 22:15:43 UTC+2 Simone Bordet napísal(-a):
thank you for your invaluable insight into possible implementation issues with SSE. From my point of view the only advantage of SSE comparing to websocket is that it should work seamlessly under HTTP/2 (as far as I know there is no specified solution how to run websocket under HTTP/2). But after reading your response, I totally agree with you that implementing SSE does not add value for systems running on HTTP/1.1.
Question is what to do for systems where HTTP/2 will be preffered version of HTTP protocol. Currently there is no possibility to use websocket with HTTP/2. I know that using HTTP/2 connections to same host are very cheap - it's always physically one connection which is multiplexed. So I am not sure, but I assume that CometD long-polling/callback-polling+HTTP/2 will be sufficient alternative with comparison to websocket+HTTP/1.1. Do you think it is viable alternative now or in near future ?
Disclaimer: I am now architecting application for visualisation of real-time data, planned production use is in 2017. I plan to use HTTP/2 as preffered version of HTTP protocol with fallback to HTTP/1.1 for older browsers.
Thank you a lot for response
Marek
Dňa piatok, 7. októbra 2016 22:15:43 UTC+2 Simone Bordet napísal(-a):
Simone Bordet
Oct 10, 2016, 9:12:31 AM10/10/16
to marekgregor, cometd-users, Bordet, Simone
Hi,
On Mon, Oct 10, 2016 at 2:00 PM, marekgregor <marek....@gmail.com> wrote:
> Hello Simone,
>
> thank you for your invaluable insight into possible implementation issues
> with SSE. From my point of view the only advantage of SSE comparing to
> websocket is that it should work seamlessly under HTTP/2
Sure, but so does long polling.
> (as far as I know
> there is no specified solution how to run websocket under HTTP/2).
Indeed there is no solution yet for carrying WebSocket frames inside
the same HTTP/2 connection.
> But after reading your response, I totally agree with you that implementing SSE does
> not add value for systems running on HTTP/1.1.
And neither for those running on HTTP/2.
> Question is what to do for systems where HTTP/2 will be preffered version of
> HTTP protocol. Currently there is no possibility to use websocket with
> HTTP/2. I know that using HTTP/2 connections to same host are very cheap -
> it's always physically one connection which is multiplexed. So I am not
> sure, but I assume that CometD long-polling/callback-polling+HTTP/2 will be
> sufficient alternative with comparison to websocket+HTTP/1.1. Do you think
> it is viable alternative now or in near future ?
I don't see such a big problem using WebSocket for what it has been
designed for: bidirectional web communication.
As such I would totally understand if you designed a HTTP/2 +
WebSocket application: use HTTP/2 for landing pages and other
(non-main) pages, and use WebSocket for your "event" pages.
Max total connections opened to server: 2.
If you really want to save that additional WebSocket connection to
only use the HTTP/2 one, then HTTP/2 long polling can do it for you.
There is no strict need for SSE.
> Disclaimer: I am now architecting application for visualisation of real-time
> data, planned production use is in 2017. I plan to use HTTP/2 as preffered
> version of HTTP protocol with fallback to HTTP/1.1 for older browsers.
As I said, either HTTP (1.1 or 2) + WebSocket is a fine solution.
Either HTTP (1.1 or 2) + long polling is a fine solution too.
As I said, I would give SSE a shot if it carried some evident benefit
like WebSocket did.
I can't see any benefit, so I'm reluctant.
As a simple example, it's fairly easy in a HTTP + long polling
scenario to enable gzip *transparently* and have the communication
data compressed by the Servlet Container.
This can effectively improve performances and latencies (and we have
seen this in real deployments).
You cannot do gzipping in SSE, so if you have large JSON messages
(that typically compress very well), you would be stuck with non-gzip
and therefore worse latencies.
On Mon, Oct 10, 2016 at 2:00 PM, marekgregor <marek....@gmail.com> wrote:
> Hello Simone,
>
> thank you for your invaluable insight into possible implementation issues
> with SSE. From my point of view the only advantage of SSE comparing to
> websocket is that it should work seamlessly under HTTP/2
> (as far as I know
> there is no specified solution how to run websocket under HTTP/2).
the same HTTP/2 connection.
> But after reading your response, I totally agree with you that implementing SSE does
> not add value for systems running on HTTP/1.1.
> Question is what to do for systems where HTTP/2 will be preffered version of
> HTTP protocol. Currently there is no possibility to use websocket with
> HTTP/2. I know that using HTTP/2 connections to same host are very cheap -
> it's always physically one connection which is multiplexed. So I am not
> sure, but I assume that CometD long-polling/callback-polling+HTTP/2 will be
> sufficient alternative with comparison to websocket+HTTP/1.1. Do you think
> it is viable alternative now or in near future ?
designed for: bidirectional web communication.
As such I would totally understand if you designed a HTTP/2 +
WebSocket application: use HTTP/2 for landing pages and other
(non-main) pages, and use WebSocket for your "event" pages.
Max total connections opened to server: 2.
If you really want to save that additional WebSocket connection to
only use the HTTP/2 one, then HTTP/2 long polling can do it for you.
There is no strict need for SSE.
> Disclaimer: I am now architecting application for visualisation of real-time
> data, planned production use is in 2017. I plan to use HTTP/2 as preffered
> version of HTTP protocol with fallback to HTTP/1.1 for older browsers.
Either HTTP (1.1 or 2) + long polling is a fine solution too.
As I said, I would give SSE a shot if it carried some evident benefit
like WebSocket did.
I can't see any benefit, so I'm reluctant.
As a simple example, it's fairly easy in a HTTP + long polling
scenario to enable gzip *transparently* and have the communication
data compressed by the Servlet Container.
This can effectively improve performances and latencies (and we have
seen this in real deployments).
You cannot do gzipping in SSE, so if you have large JSON messages
(that typically compress very well), you would be stuck with non-gzip
and therefore worse latencies.
Reply all
Reply to author
Forward
0 new messages