Use server-initiated track queries to induced client backpressure #48
Description
In a scenario when the server sends notify messages to the client at a high rate, for a long period of time, a long backlog of unprocessed messages may build up on a slow client.
If, at that point, the server decided to initiate a track query to assure the client is still alive, the response to this query may be much delayed, due to head-of-line blocking, assuming the client processes the messages in order.
Today, the server relies on than transport connection back-pressure to detect client overload. The host buffers and the network can potentially keep many messages buffered/in-flight. One thing the server could do is to insert track queries into the stream of other notification (e.g., subscription matches). The server could just allow a few such outstanding queries, and delay the transmission of more non-track notifications until a track reply is received. In such a way, the server could ensure that the number of in-flight messages is kept at a reasonable level.
A client could process messages from different transactions out-of-order, and provide track queries with higher priority. That would invalidate the above assumption, but would on the other hand solve the original issue (track replies not getting through).