Applicative ping and/or keepalive about rsocket HOT 4 CLOSED

I had a chat on this with @tmontgomery and the opinion at that point was that it can be an optional (but a prescribed best practice) application concern and not a part of the protocol.

For the request type, I think it should be a REQUEST_SUBSCRIPTION request so that it can be subject to flow control semantics as opposed to every heartbeat being a new request. Also, the keepalive should be acknowledged by the peer to handle half-close TCP connections. So, it will be a ping-pong as opposed to a ping :)

from rsocket.

This falls into the area of handling the unexpected. Liveness for a duplex channel should be dual, but it should be 1 ends responsibility to initiate. If the protocol needs to provide this to the applications, then it should be baked in and should handle half-open sockets as well as any lack of response.

SUBSCRIPTION semantics aren't quite right. It does inform one side, but not the other. REQUEST_RESPONSE is closer, but still not quite right for all cases.

Application keepalive covers a lot of ground.

1. loss of continuity of physical network
2. loss of continuity of transport
3. loss of continuity of ReactiveSocket layer on 1 side
4. loss of continuity of application layer on 1 side

If this should be a protocol concern, we can add a PING frame much like WebSockets has. Optionally used.

from rsocket.

KEEPALIVE frame is being added that this can utilize.

from rsocket.

Closing this issue:
KEEPALIVE has been added, and applicative ping should be a normal request/response (in order to properly measure application queuing time).

from rsocket.