Pings are only sent from a server connection, yes?

[Rich C]

Pings are only ever sent from a server-side connection, yes?

[Peter Thorson]

There is no protocol restriction against clients sending pings. I don't know of any mainstream browser that sends them. Websocket++ clients can send them.

On Mar 4, 2016, at 17:55, Rich C <rchomi...@gmail.com> wrote:

Pings are only ever sent from a server-side connection, yes?

--
You received this message because you are subscribed to the Google Groups "WebSocket++" group.
To unsubscribe from this group and stop receiving emails from it, send an email to websocketpp...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[andrew]

Forgive the naive question, but isn't "ping" a rather arbitrary term since it's just a message sent over a socket, is there something specific about a "ping" that separates it technically from another kind of message content? Since any websocket server or client can send and receive messages, as that is the point of websocket technology, I would think that regardless of using websocket++ or some other tool, you could always send a ping from a client, no? It just simply depends on the "API" of the server and the kinds of messages its programmer has setup to handle.

[Peter Thorson]

Ping in this context likely refers to the RFC6455/WebSocket Protocol defined “ping” control message, rather than the more generic concept of a message used as a liveness check.

You are correct in that any application level websocket subprotocol can define a particular message format as a ping/liveness check without the cooperation of the underlying protocols or libraries.

The WebSocket Protocol level ping/pong messages however, work a little differently and their behavior cannot be replicated via an application level subprotocol using data messages. Specifically, because the WS ping message is a control message rather than a data message it does not show up or affect the application level stream of messages. It won’t trigger onmessage in browsers or the message handler in WebSocket++ (most other WebSocket libraries are similar). This allows a server or proxy to perform a live-ness check on a connection without worrying about confusing the application level subprotocol.

Additionally, control messages can be interleaved with data messages. If one endpoint is sending a very long message or just sending one very slowly and it fragments the message appropriately the two endpoints can perform the ping/pong steps during receipt of the data message without corrupting it.

Some WebSocket libraries/APIs (particularly those in browsers) do not expose the protocol level control messages to their API. WebSocket++, as it is designed to be able to be used in lower level contexts, does provide handlers for being notified about and changing the default behavior of these control messages. This behavior is the same for both clients and servers. Generally though, servers care more about things like disconnecting broken clients and so much of the literature & documentation is focused on that use case.

[Rich C]

Understood, but I'd have to write some code to do that (I'm assuming on the server-side WebSocket++ creates a timer to periodically send pings).

[Rich C]

The websocket protocol describes ping/pong control frames.

[Peter Thorson]

WebSocket++ does not automatically send pings. It automatically responds to pings with a pong (per RFC6455 requirements). This can be overridden in the ping handler if you want different behavior. There is also a pong timeout handler that can be used (if your transport supports timers) to easily detect when a ping that you have sent has not been answered.

On both the client and server side your application logic is responsible for deciding when it wants to send pings and what to do if one is not responded to. This is commonly done with a thread or with WebSocket++’s set_timer method (no threads needed here).