I confirm that Lightstreamer provides no guarantee that all the requested websocket connections can be opened.
The last word on this pertains to the user agent, which may obey the current recommendations.
Lightstreamer Client Libraries, if unsuccessful in creating a websocket, will try to resort to http streaming and then to http long polling.
However, if the requested connections were even more than the overall open sockets made available by the user agent, the only possible workaround would be the use of traditional "short" polling; but this case should be handled by the application.
What we suggest is that the components share a single LightstreamerClient object.
Their subscriptions and "sendMessage" would still be treated independently, with different listeners.
So, this wouldn't mean sharing the state, which could still be handled by the Server.
Lightstreamer Client Libraries provide a help, with their support for connection sharing.
This allows each component to see only a local instance of LightstreamerClient, provided that a global instance of LightstreamerClient is maintained in the page.
See the
ConnectionSharing object. Note that the communication between the local and global LightstreamerClient requires some conditions, but, as long as all the instances belong to the same underlying page, there should be no problems.
