Inactivity in networked RDP

[Manuel Simoni]

I'm wondering how to model inactivity in a networked RDP implementation, similar to [1]:

In normal, "local" RDP it's easy for a downstream behavior to not do any work when its input signal is inactive.

But in networked "remote" RDP, even when the input signal is inactive, the behavior has to do work: namely to send messages to the signal from time to time to find out if it is still inactive.

With a large number of behaviors, this could lead to a lot of background work.

Any ideas on how to address this problem?

[1] http://axisofeval.blogspot.com/2015/08/restful-rdp-with-big-values.html

[David Barbour]

Ultimately your question can be reduced to: "how do we deal efficiently with polling of stable data?"

An 'input' signal that is stable, predictable for potentially days at a time, encounters the same challenges regarding unnecessary 'background work' regardless of whether it is stable-active vs. stable-inactive. . . or even stable with predictable duty cycle of 1 second active, 2 seconds inactive.

HTTP doesn't have any built-in features to support publish-subscribe. That is, PUT and GET are understood as one-off verbs. Hence, naive use of HTTP GET for time-varying information will encounter all the conventional engineering challenges surrounding polling:

* Polling is inefficient for stable data (poll frequently without updates)

* Polling adds a large amount of latency (up to the period of polling)

* Polling is imprecise (you might miss important intermediate states)

Obviously, it would be preferable to avoid these problems. If we must use HTTP and pull-based communications, then the conventional answer is generally Comet based mechanisms (long polling, streaming updates - time series data, append-only logs, etc.). Unfortunately, these techniques are notoriously unreliable in the long term, and we'd still face a lot of 'background work' just for reconnecting.

For efficiency, it is favorable to switch to push-based communication where feasible. 

I.e. instead of PUT the demand signal then GET a response, you PUT the demand signal and also PUT a continuation indicating where to send the response. Some variant of HTTP PATCH might be applied to work with changes in very large values. Update representations are easily kept idempotent, so it's easy to repeat in case of network error. 

Obviously, there are limits to use of push-based communications when feeding information to the browser. (While there have been experiments with shoving a web server into a web page, those techniques require firewall and browser configurations that make IT administrators cringe.) However, providing lightweight proxy servers and Comet adapters is feasible.