I have a client app that exposes a http endpoint on localhost. This way, windows of the app itself, but also external applications using embedded browsers can display data of the app. The app needs to push data towards the browser sessions.
On a previous version of the app, i used a self made polling mechanism (NOT long-polling) to prevent the connection limit of embedded browsers.
Now there have been a total rewrite of the app, changes made to the whole design because of this and that, but also including switching from self made polling to SignalR. Which works beautifully with websockets - i tested it and it worked GREAT! So i thought i was done...untill i installed it at a customer with a windows 7 client OS. Then, websockets aren't supported, the transport falls back to long-polling, thus hitting the connection limit fast. Especially with embedded browsers, where you don't know whats already going on.
The most easy way, is to let signalR use either WebSockets or polling and no alternative methods of transport, but from what i can find, signalR does not support polling. (just SSE, foreverframe and long-polling with said problem). The fact that polling is not that performant, doesn't bother me because its on localhost only anyway.
Is there an easy way to fall back to polling, using as much of existing code as possible? I mean, everything is already there, if signalR would just support polling, there would be no problem...
It feels like i'm overlooking something that is about to cost me a lot of extra time and hooks into existing code.
The app is using a selfhosted persistent connection.