This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
How about adding new attributes to control ping/pong frames. // ping-pong handling attribute unsigned long pingInterval; attribute unsigned long pongTimeout; If pingInterval is specified, a browser will send ping frames in every pingInterval msec. If pongTimeout is specified, a browser will _fail_ the connection if any pong is received in the last pongTimeout msec. It's very important for some applications to know the server can not send some critical event to the client immediately. So to detect unstable network connection is very useful. Of course, this feature can be implemented on the top of WebSocket connection as a user level protocol. But, it's effective to use RFC6455 defined ping/pong frames here.
(In reply to comment #0) > How about adding new attributes to control ping/pong frames. > > // ping-pong handling > attribute unsigned long pingInterval; > attribute unsigned long pongTimeout; > > If pongTimeout is specified, a browser will _fail_ the connection if any pong > is received in the last pongTimeout msec. Should not this be "a browser will _fail_ the connection if NO pong is received in the last pongTimeout msec." meaning there is no response to ping within specified time frame, failing on pong makes no sense to me
Oops, I revise my proposal as > If pongTimeout is specified, a browser will _fail_ the connection if no pong > is received in the last pongTimeout msec. Thank you for correction. And do you mean that you still disagree with this proposal? Actually, we don't have a reliable mechanism to tie a received pong frame with a sent ping frame. It will be based on some heuristics and predictions. Also RFC6455 allows unsolicited pong frames. These are the reason why I propose it as not pingTimeout, but pongTimeout.
I agree completely, we are missing a lot of more low level functionality in WS (ping/pong, intercepting/sending frames, etc.) any step to increase control over WS is a good thing. And this is a good approach. Though maybe I add attribute DOMString pingMessage [TreatNonCallableAsNull] attribute Function? onping; //message event [TreatNonCallableAsNull] attribute Function? onpong; //message event but I think it may be enough to start with your suggestion and gradually extend it
we may also consider exposing ping/pong functions directly But if considered, your original proposal should be the start (I assume it would be the most common use case)
Thank you for supporting my idea. Yes, as you suggested, ping/pong event handlers and direct API to control ping/pong frame are also useful for advanced use cases. I also agreed that it's important to improve and extend API gradually because we don't have enough real use cases for now.
Well we have :) e.g. framing for streaming, sure people may say that we have video/audio API for that... but that's Web specific, so instead of using generic protocol allowing streaming, writing server that would not care what kind of app would connect to it (browser, other desktop app), one have to start from WebRTC to reimplement it to other enviroment to work in browser and other app. What if I do not want to stream audio/video? What if I want to download 100MiB file from server using WS? How about progress? In desktop it's very easy, in browser, impossible... I sometimes wonder, how many times we do not have use case, because we do not have technology... Not everyone who has a good idea writes here or is in some mailing list.
I don't really understand why ping/pong frames are part of the WebSocket protocol rather than being implemented by the author at the subprotocol level.
(In reply to comment #7) > I don't really understand why ping/pong frames are part of the WebSocket > protocol rather than being implemented by the author at the subprotocol level. Nevertheless they are, and we can either recreate the same functionality to have keepalive/isaliverequest or use what is native in protocol.
A similar proposal was previously discussed and resolved in Bug 13104 - Enable keepalive on WebSocket API. https://www.w3.org/Bugs/Public/show_bug.cgi?id=13104 The new charter for the IETF HyBi group also includes work in this area to make the values more discoverable: http://www.ietf.org/mail-archive/web/hybi/current/msg09424.html 3. Timeout-handling capabilities to reduce the chattiness of the protocol (draft-thomson-hybi-http-timeout is a likely starting point). http://tools.ietf.org/id/draft-thomson-hybi-http-timeout-01.txt
As Ian said at #7, we can implement application specific ping/pong at the subprotocol level. But, it will reduce opportunity to use Blob and ArrayBuffer effectively. Because sending a large file as a Blob will suspend subprotocol level ping/pong, and it will fire timeout easily. Of course we can create another special WebSocket instance for ping/pong. But, no one assure that other WebSocket connections are sanity when ping/pong connection is alive. If we can use multiplexing, situation will be improved. But no one know which connections actually share the one TCP connection after all. Protocol level ping/pong might be primitive and simple. But it can be injected in the middle of a fragmented message. It means that when application send a large data, ping/pong frames can be handled periodically. This is a big motivation to use protocol level ping/pong frames.
Fair enough. I guess this is something to add to the next major version of the API then.
Marking this LATER to separate it from more urgent bugs; will reopen and reconsider in January.