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.