On Thu, Jul 12, 2012 at 6:24 PM, Danny Coward <
So it looks to me that for the JSR API, this means:-
a) API to send pings, something like: public void sendPing(byte
applicationData) on RemoteEndpoint.
b) A ping-pong should reset the idle timeout on the connection.
c) API to receive pongs, something like: public void onPong(byte
applicationData) on MessageListener
d) implementations should answer a ping with a pong with the same
data as soon as possible after receiving it.
Sounds good. A few things to add:
* As well as sendPing and onPong, we also need to support the opposite direction for when the client initiates the ping. i.e. onPing, sendPong.
* Whatever the result of the streaming API discussion, we should offer equivalent methods for the ping/pong application date (e.g. chunking, streaming, whatever).
* Most (but not all) applications don't care about implementing their own ping/pong rules. It should be easy for applications to use predefined ping/pong strategies (e.g. reply to pings from client, send heartbeat pings from server with timeout, etc), without having to duplicate code. Maybe this is a vendor specific feature - or maybe it could be implemented in user-space with a Filter equivalent for the WebSockets.