Socket.IO keeps polling even when websocket is available

Socket.IO keeps polling even when websocket is available
0

#1

Socket.IO does not seem to be able to use the optimal protocol to send and receive messages.

In my Chrome Browser where websocket is available, socket io still keeps polling the server.

To turn off polling and rely only on websockets, I had to use -

socket = io.connect({transports: ['websocket']});

This stopped usage of polling and only used websocket.

But why do I have to resort to that.

Shouldn’t Socket.IO only use websocket when it is available?

And use polling in worst case scenario.

I found a similar issue on github.

Even though the issue has been closed I am still facing the same problem.

Anybody facing the same issue?


#2

That issue hasn’t been closed. It looks like rauchg is waiting (with the patience of a saint) for someone to show that they’re experiencing anything other than failbacking when the browser tries to upgrade to wss. Is your connection successfully upgrading to wss and still polling w/XHR?


#3

Turns out Socket.IO was polling only initially after a few poll requests, it stopped polling after a while and started using ws.


#4

I know this is post is over a year old but I am having the same issue. In my case I am using the Java classes and what appears to happen is the following:

  1. the client via the xhr polling transport sends a long polling request
  2. the server responds with the sid
  3. the client then attempts to upgrade to a websocket
  4. before the server responds the client sends another poll
  5. the server rejects the poll (seems that it is not expecting it) and throws a 400 error and disconnects client

This process is then repeated with the auto reconnect function. Eventually the Polling class receives the event that causes it to pause and the connection is upgraded and polling stops.

Another side effect of this timing mismatch is that from time to time there is a “warning: connection leak” error thrown say “ensure you close the response body”. thrown by okhttp3.OkHttpClient.

What appears to be happening is that the poller is not being notified in time that it needs to pause polling. This all happens internally, all I do is connect. At first I thought there was an issue or mismatch between the node.js and java implementations and i would never get a connection. Then whilst debugging I suddenly had a connection.

Anyway, this to me seems to be something that needs to be fixed or is there a way to stop the polling from my code?

CDP


#5

Doesn’t this solve the problem?


#6

No, not really, I could deal with lets say 2 extra polls, but sometimes it goes on for minutes. Not really a solution. It is a bug that I believe needs to be fixed.