Akka-http: Add support for automatic pinging in WebSocket server implementation with configurable rate

Created on 8 Sep 2016  路  13Comments  路  Source: akka/akka-http

Issue by fommil
_Sunday Jul 12, 2015 at 11:01 GMT_
_Originally opened as https://github.com/akka/akka/issues/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 https://github.com/smootoo/simple-spray-websockets/commit/17ea453cf453af522255206cd971835fa897293d (note that we forked wandoulabs, because it seems to be a zombie project)

help wanted core

Most helpful comment

Done, will ship in 10.1.1 shortly

All 13 comments

Comment by jrudolph
_Monday Jul 13, 2015 at 09:13 GMT_


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:

  • outgoing user data
  • auto-generated PINGs (maybe only on idle connections?)
  • PONG answers in response to peer PINGs

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.

Comment by jrudolph
_Monday Jul 13, 2015 at 09:22 GMT_


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.

Comment by ktoso
_Tuesday Oct 20, 2015 at 12:07 GMT_


Doesn't sound like we have a clear idea how to solve this yet, such that PINGs don't starve the actual user-code etc... right?

Marking as 1.x for now // cc @rkuhn @sirthias @jrudolph

Comment by drewhk
_Tuesday Oct 20, 2015 at 12:14 GMT_


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.

Comment by ktoso
_Thursday Apr 07, 2016 at 13:32 GMT_


We nowadays have keepAlive, we can investigate how to apply it here perhaps.

Comment by ktoso
_Thursday Apr 07, 2016 at 13:40 GMT_


Auto ping also requested by people from Play community BTW https://github.com/akka/akka/issues/18126#issuecomment-129270050

Comment by ianclegg
_Thursday Jul 14, 2016 at 10:28 GMT_


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. :+1:

:+1: 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.

Why not implement PingMessage as a sub-class of Message and update MessageToFrameRenderer to be aware of it, at least to allow sending ping messages from the application code?

Feel free to give it a shot and send in a PR :) As you can see, it's a help wanted one, after all :)

@ktoso the problem is Message is sealed and introducing another descendant will break compatibility.

I'll work on this, this week

Done, will ship in 10.1.1 shortly

Was this page helpful?
0 / 5 - 0 ratings