I think you ask this question because of the the comments on one of the answers or questions, where one member and myself commented that SignalR has nothing to do with real-time, and I added that there are many different unrelated and confusion uses of the term "real time".
You can read about real-time computing, and hence, programming, for example, here:
https://en.wikipedia.org/wiki/Real-time_computing[
^].
It would be important to know that, in this sense, any processing related to Internet is never real time, because of the nature of its physical layer. At the same time, real-time networking is possible. One important example is some designs of elementary particle accelerators. In such designs, real-time technology was used, which also included real-time networks. Such network architectures are specialized and have nothing to do with Internet.
There are many other uses of the term, related or unrelated to the understanding or real-time programming, which I would consider the basic:
https://en.wikipedia.org/wiki/Real-time[
^].
In particular, on these site, I've seen many posts where "real time" is used simply due to bad knowledge or English; a number of illiterate members just use the term which is repeated many times by others. Some use "real time" in the same sense as "in real life". You can find a number of such uses in the "Related Questions" on right of this page. On this forum, there are a number of false "terms", even simply misspelled words which live such ghost life, which is, of course, very bad for everyone.
Read and try to decide by yourself what is related to real-time computing and what not. For example, the expressions like "real-time strategy", "real-time data", or, say, "real-time transcription" are related to computing, but have nothing to do with real-time computing. Some have something in common though, but not so much.
As very few people, compared to a mass of software developers working these days, actually worked at real-time processing, there are many most ridiculous myths about real time. One of these myths is that real-time is associated with high performance. This myth is dismissed in the article I referenced first, but I would add that, on given hardware, real time can only slow down processing. Real time, basically, is the approach which can guarantee certain processing in certain time, and the way to guarantee it needs more time.
As to SignalR, it is related to a important different aspect of computing, no related to real time directly, but it could be associated to one of those loosely phased "real-time" notions. It is related to the
push technology, which is problematic with HTTP. Please see my past answer for some relevant considerations:
Application 'dashboard' for website accounts[
^].
If I'm not mistaken, in those recent comments, we mentioned that there is no "real-time programming" with C#. If you asked if it is possible to write a real-time application in based on .NET (or, rather, CLI), the answer would be: no. In real life, present-day, this is impossible. It is impossible just because all systems where you can use CLI have nothing to do with real-time computing. But nobody knows what can happen in future. I see no fundamental limitation to real time, but it is impossible with presently existing implementations of CLR.
(See also:
https://en.wikipedia.org/wiki/Common_Language_Infrastructure[
^],
https://en.wikipedia.org/wiki/Common_Language_Runtime[
^].)
But you are asking if this is possible with "managed code". The problem is: "managed code" reflects just the idea of memory managed technology. Again, if you mean the memory management currently implemented in existing implementations of CLR (or, say, JVM), we cannot talk about real time. But this is not the law of nature. I cannot say the same about some hypothetical implementation design.
—SA
Submit an article or tip