How to detect if a websocket connection is established?

cwt237

I would like to be able to detect what type of connection is established on the client (with both the JavaScript and .NET client library). Is that possible and if yes, how?

As far as I can see I can detect whether the connection is streaming or polling, e.g. by implementing IConnectionListener and using that when opening the connection from the client. However, I have a hard time finding out what this means exactly.

Does streaming mean web sockets - or could it be either websockets or pushing HTTP chunks back via the same http connection?

Thanks

Giuseppe Corti

In the JavaScript client API you should use the onStatusChange event of ClientListener to be informed about the change of connection status.
The range of event is DISCONNECTED, CONNECTING, and CONNECTED. Among CONNECTED status you can distinguish between the cases:
- "CONNECTED:STREAM-SENSE"
- "CONNECTED:WS-STREAMING"
- "CONNECTED:HTTP-STREAMING"
- "CONNECTED:WS-POLLING"
- "CONNECTED:HTTP-POLLING"
Plese refer to the API reference for full details. I confirm you that the streaming mode can be both over WebSockets or HTTP (please refer to these slides from 14).

In .NET client API, you are right, the information is retrieved by the OnSessionStarted of IConnectionListener and you can only discriminate between the polling or streaming cases (please note that at the moment the .NET client library does not support WebSockets).

cwt237

Ok, thanks for the info.

With your knowledge, how would you rate the server to client performance for HTTP-STREAMING vs. WS-STREAMING ?

Can we expect to see a 30% decrease in e.g. number of messages put through the channel or overall latency of individual messages - or would you expect it to be the same? (without applying GZIP for HTTP streaming).

We looked briefly at implementing our own LS WS .NET client, by sniffing the LS/WS protocol using the JavaScript client, but it does not look as simple as we initially thought.

Giuseppe Corti

Actually we expect, that for typical scenario where the comunication is mainly FROM server TO client, the WebSockets do not offer any better performance than HTTP Streaming (neither for throughput nor for latency). The real advantage of WebSockets arises for bi-directional communication, that is, when you send low latency updates FROM the client to the SERVER.

Anyway, the JavaScript Client library and .NET client library use a communication protocol with Lightstreamer server slightly different. The JS library is based on a private protocol (not documented), while the .NET library is based on the Network protocol for Generic Client , but at the moment it is not ready for WebSockets.