Can we not use "realtime" for what is just really "interactive" features? Or even just "duplex" ?
"realtime" has a long history in the computing and technology realms, and this ain't it.
"realtime" has a long history in the computing and technology realms, and this ain't it.
People that know enough to care will know within 1 second what the article is about.
"Soft real-time" is probably the correct term here, but that is actually more confusing for 99% of people.
"Interactive" is not descriptive. "Duplex" is certainly not obvious.
TFA is just about the design and deployment of a two-way ("duplex") communication system that makes distributed applications "feel modern, collaborative, and up-to-date"
These sorts of systems have existed for decades; TFA provides a brief overview of 3 design patterns associated with them.
In particular
> Soft real-time systems are typically used to solve issues of concurrent access and the need to keep a number of connected systems up-to-date through changing situations
That's exactly what this post is about. "Real-time" on the web often just means an app that allows multiple users to concurrently make updates to some piece of state, and for the changes to that state to be broadcast to all users so that all clients are kept consistent within a reasonable time frame, preferably as quickly as possible.
While the deadlines aren't as hard as in e.g. audio programming, "real-time multiplayer" apps can be said to be broken if there is a very large noticeable delay between a user editing something and the other users seeing that edit reflected in their local client.
Hard disagree. There is no deadline to meet time wise, only that a specific task must be completed in a specific order as quickly as possible. This implies managing state while keeping latency low which is a QoS problem.
Agreed. The best term to use for this scenario is low-latency as real time implies a deadline. low-latency deals with QoS where you ascribe a quality parameter to the service.
There are patterns for "real time". Things such as:
- What matters is the slowest case, not the average case.
- What has to be real time, and what can run in background?
- Avoiding priority inversions.
- Is there a stall timer that trips if you miss the control loop timing? What happens when the stall timer trips?
- What influence do caches have on time repeatability? What's the worst case? Can you keep the worst case from being the nothing-in-cache case?
“Realtime” in this sense is akin to real-time strategy games which has been a named genre since at least 1992 (and is also not real-time in the classical computing sense).
It basically just referes to a system that reacts in a predictable time. Traditionally that time is short, but that isn't part of the definition.
As a audio DSP programmer my deadline is determined by the samplerate and the size of my buffer, and that is a hard deadline, as any dropouts might be audible. For game people their deadline is more flexible as there the framerate can drop without it being completely unacceptable. How low of an framerate is too low isn't a clear deadline, but the clear deadline isn't part of the definition. You can run any realtime code in an environment where it can't perform.
So what about a webservice that guarantees that every internal state update is communicated to clients via a websocket within an acceptable timeframe? Like the game people they don't have a clearly formalized deadline, but when a websocket update takes a minute that would surely be unacceptable. So the original definition of "a system that reacts in a predictable time" can still hold — just not for the reason that people colloquially think ("I get updates as they happen or, in realtime").
And to be frank, I think when some dev says "realtime updates" we all understand what they meant and that is the point of language right?
We understand despite the muddling of terms, but let's not pretend that precise language isn't desirable to the best extent possible.