Add support for automatic pinging in WebSocket server implementation with configurable rate #102
Comments
|
Automatic server-side ping is not mandatory in the spec and it's not implemented so far. In any case, just setting the rate would always help for one specific networking setup. The only robust solution is providing backpressure throughout the whole processing chain. For Websocket this means that there needs to be some frame sending management that organizes how data from these three sources should be sequenced and backpressured:
User-data will be back-pressured through the existing streaming API, PONG answers will effectively start to backpressure the incoming side, and auto-generated PING could theoretically be dropped if there's backpressure from the network. |
|
So, for user-code the rule is that it needs to support the backpressure from the streams API. Relying on the rest of the stack (server-side websocket, server-side networking configuration and implementation, network, peer-side networking configuration and implementation, peer-side websocket implementation, peer-side application) to provide any guarantees on being backpressure-free will always be brittle. Even if things seems to work in the good cases (localhost, big enough buffers, good enough network, etc.) it will fail rarely and unexpectedly under load. |
|
It is simple to do with a GraphStage. I planned to have an "idle-inject" stage which is the counterpart of the "idle-timeout" stage. |
|
We nowadays have keepAlive, we can investigate how to apply it here perhaps. |
|
Auto ping also requested by people from Play community BTW akka/akka#18126 (comment) |
|
Some kind of support for ping/pong frames in Akka Http would be nice - at the moment we have to handle this much higher up at the application level with ping binary messages and our own sequence numbers. It certainly requires some careful thought, but it would be useful to have. 👍 |
ktoso
added
1 - triaged
|
👍 I'd also like to see this supported on the client side. I'm currently migrating my slack client from spray-websocket and not having any form of access to Ping/Pong frames prevents me from adequately detecting dropped connections at the websocket level. |
jrudolph
added
the
help wanted
|
Why not implement |
|
Feel free to give it a shot and send in a PR :) As you can see, it's a |
|
@ktoso the problem is |
ktoso
added
the
2 - pick next
|
I'll work on this, this week |
ktoso
added
3 - in progress
* +htc #102 transparent keep-alive Ping/Pong for websocket fix docs include * fir compilation for 2.11, forgot main build is 2.12 nowadays and applied change too eagerly * review feedback * move mima filters
ktoso
added
t:core
|
Done, will ship in 10.1.1 shortly |
Sunday Jul 12, 2015 at 11:01 GMT
Originally opened as akka/akka#17968
@jrudolph I just realised there doesn't appear to be a way to specify the ping rate from the server to the client. This is not something that the application level code should be concerned with.
It's actually a really big pain in the wandoulabs implementation because even if the user's code uses proper backpressure, then protocol layer
Ping/Pongs can still blow up the network stack and that means a lot more error handling is required a lot higher up the stack than desirable. I worked around this in smootoo/simple-spray-websockets@17ea453 (note that we forked wandoulabs, because it seems to be a zombie project)The text was updated successfully, but these errors were encountered: