Many years ago, we used to start a streaming session with an http request, then upgrading to websockets after obtaining a response (this was our original "StreamSense" mechanism). In recent years, we changed StreamSense to go websocket first and fallback to http streaming or http long polling in case of issues.
At Lightstreamer, we started streaming data 25 years ago over http, then moving to websockets. We've seen so many different behaviors in the wild internet and got some much feedback from the fieldsl in these decades that we believe our current version of Lightstreamer includes heuristics and mechanisms for virtually every possible aspect of websockets that could go wrong. From massive disconnections and reconnections, to enterprise proxies with deep inspections, to mobile users continuously switching networks.
I recall when a big customer required us to support one million live websocket connections for each server (mid-sized) keeping low latency. It was challenging but forced us to come up with a brand new internal architecture. So many stories to tell covering 25 years of evolution...
Hey jaennaet, that's so cool! I work at Lightstreamer and we have never met before.
I often use the urine tank level as an example in my presentations. It’s a fun way to demonstrate streaming real-time data from space (literally) to web and mobile apps.
For a bit of background: NASA selected us back in 2010 for a project called SSLive, aimed at making telemetry data from the ISS publicly accessible in real time via an open feed.
A quick comment based on our experience. We have been providing a proprietary messaging server based on WebSockets and HTTP Streaming for many years now, mainly used for financial trading, online betting, and aerospace. The increased popularity of MQTT in recent years pushed us to find some good points of contact between MQTT and our well established practices to deliver real-time data through the Internet. Simply tunneling MQTT over WebSocket didn't seem to be enough in some scenarios (perhaps corner cases, perhaps not, we don't know yet). In particular, what is completely lacking in MQTT (and in MQTT over WebSockets) is the ability to throttle and resample the data on the fly based on the available bandwidth.
To make a long story short, we decided to "add" this and other features to MQTT by creating a gateway that transparently remaps MQTT over our proprietary but open protocol (TLCP). The result is a solution that exposes very standard MQTT API (Mosquitto-like), but is much more Internet-friendly than MQTT over WebSockets (both for throttling and other reasons, which I don't list here to keep it short).