Transport and AutoUpgrade questions

[reneguillot]

Hello,

The README states the following:

SocketIOClient v3.x supports http polling, but if websocket is available, the library will choose to use websocket. If you want to use http polling and do not want the library to upgrade the transport, please set Options.AutoUpgrade = false

Several questions on this statement with the latest release (v3.0.5):

• The AutoUpgrade option doesn't seem to be available for use. Am I missing something?
• Can it be confirmed that the latest library will automatically prefer websocket over HTTP polling, if options were set to HTTP polling but websocket turns out to be available?
• Will diagnostics logging actually show which transport is actually used by the SocketIOClient?

Many thanks for your feedback.

Rene Tran-Guillot

[doghappy]

Sorry, this part of the documentation is out of date.

AutoUpgrade was removed a few versions ago because I haven't found a good way to detect if ws is available.

In the latest version, it uses the Websocket protocol by default. If the server does not support websocket, we need to manually change the Transport to Polling

[reneguillot]

Thanks for the quick response. From my own experiences connecting SocketIOClient to a socket.io server explicitly with polling (not sure whether v3 or v4 server, but EIO option is the default value of 4), the following diagnostics are logged (all within a timeframe of ~500ms in this case):

[Receive] 0{"sid":"wNADYNTTeueriT1lAAXW","upgrades":["websocket"],"pingInterval":25000,"pingTimeout":5000} [Receive] ok [Send] 40 [Receive] 40{"sid":"d3oVwHhUCrj_RBfXAAZR"} [Receive] 41

The upgrades array in the first message (Opened/0) basically suggests "websocket" is available for this particular socket.io server. The SocketIOClient continues receiving a raw value 'ok', sends Connected/40, next receives Connected/40 and finally receives a Disconnect/41. The SocketIOClient library doesn't connect again. Neither in polling, nor in websocket.

As I'm relatively new to socket.io, I don't know if the stream of events above is as expected from a socket.io server offering websocket, but the client attempts polling first. But if it is, couldn't the SocketIOClient proactively reconnect with websocket transport, based on the mentioned upgrades suggestions in the first Opened/0 received message? I suppose parsing that upgrades array would be a good way to detect websocket availability. It's the same enhancement as requested in Issue 223...

When connecting to the same server explicitly with websocket transport protocol (and I know know it is supported by the server), the diagnostic messages resemble something like below;

[Receive] 0{"sid":"wNADYNTTeueriT1lAAXW","upgrades":[],"pingInterval":25000,"pingTimeout":5000} [Receive] 40{"sid":"d3oVwHhUCrj_RBfXAAZR"} [Receive Ping] 2 [Receive Ping] 2 [Receive Ping] 2 ...

Note: each Ping is 25 seconds apart, as expected because of the pingInterval value in the first Opened/0 message.

Hoping the above is useful for you to assess whether an automatic protocol upgrade can be implemented after all.

And how about the other way around: not upgrading polling -> websocket, but downgrading websocket -> polling, in case websocket transport is failing for some reason: Is that also implemented in the SocketIOClient?

Thanks again for your valuable feedback.