Question

Is there a specific metric which a system should meet to be considered/classified as real-time web application or a near- real time web application?

When I see a non-functional requirement for a system on which I am working which states the solution shall return data in real time/near real time. I understand the definition of the terms (as found http://en.wikipedia.org/wiki/Near_real-time), but I was wondering if there were standards like one might find for an application UI (example: Gnome recommendations http://developer.gnome.org/hig-book/3.5/feedback-response-times.html.en) for expectations of near real time in a web application.

This is a variant of another question: Define realtime on the web for business

Was it helpful?

Solution

Real-time computing has nothing to do with performance, but rather the guarantee that an event can be completed in a set amount of time. Real-time requirements have implications throughout the architecture from CPU scheduling algorithms to the operating system all the way to the application being built.

Real-time requirements are specified in terms of the amount of time in which an operation must be completed. Again, this must be guarantee and systems will often fault when the deadline is not met (this is not expected).

See also What constitutes 'real time'

OTHER TIPS

At the high level (quite abstract):

http://cs.brown.edu/~ugur/8rulesSigRec.pdf

At the low level, basically it means (whether it is hardware or software):

a. no caching: software cache, hardware cache etc.

b. no pipelining of instructions: this is simply because at each branch points a lot of executed instructions may have to be thrown away, resulting in indeterminacy.

c. no asynchronous mechanism (eg, interrupt). use polling whenever possible. this is because in interrupt mehanism, we are not sure when the event will happen.

d. highly clock-based or clock triggered mechanism: this usually means a sophisticated way of distributing the clock signals inside the hardware (lookup "Clock Tree Sythesis").

e. I have used LynxOS RTOS before. It has high responsiveness and predictability in its processing. But if you look at its internals, you will see that it skips a lot of unlikely event error processing - especially if it is hardware resources (eg, memory). so memory is always assume to be available - simply because it has low threshold in its entire design - to ensure maximum limits are seldom reached. Of course, the moment you pushed the numbers to its limits (eg, spawning lots of processes) the realtime behavior of LynxOS does not exhibit anymore.

When seen in a Business requirements document, the technical nature of the application should be taken into consideration. Context aids in determination of whether the requirement is truly real-time, is web real-time, or is near real time meaning as soon as processing allows without having to wait for a scheduled/batch process (for example, a trickle feed of data as opposed to a data load every 15 minutes).

According to the developers of SignalR, this is the ability to have your server-side code push content to the connected clients as it happens, in real-time.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top