search

doghappy / socket.io-client-csharp

socket.io-client implemention for .NET
MIT License
729 stars 125 forks source link

Transport and AutoUpgrade questions #264

Open reneguillot opened 2 years ago

reneguillot commented 2 years ago

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):

Many thanks for your feedback.

Rene Tran-Guillot

doghappy commented 2 years ago

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 commented 2 years ago

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.