[sokrates]

Personal peeve: There is still a name collision beetween the popular use of "real-time" to describe "live" updates (usually as the defining aspect being "without polling") versus the definition of "real-time", implying that events are delivered to the customer in a guaranteed period of time. Which is obviously not true.

[j_s]

Can you give an example of any 'true "real-time"' projects implementing any aspect of HTTP? I think this ship has sailed.

[peterwwillis]

Yeah, for example, there are web services whose design goal is <30ms completed request so they can guarantee their client timely data based on a SLA. If this "real-time" project can't guarantee time of transactions, it's not "real-time".

[sctechie]

How is this even possible? All it takes is a clogged router buffer 'somewhere' along your network path and that <30ms web request is gonna get blown away. Am I missing something here?

I'm probably just being ignorant lol. Can you point me to an example company offering a service like this?

Thanks.

[peterwwillis]

I can't, but you could for example look at the financial services industry or providers of real-time data feeds.

In general these services are not available through the public internet so routers with clogged buffers are not usually an issue. But it depends on the SLA.