0

This question has been asked before, but that answer is no longer correct. I'd like to determine transport type at runtime - if I have a ws connection, I'll route my REST requests over the websocket, and if I'm on polling, I'll do the old-fashioned http requests.

I can test io().socket.io.engine.transport.constructor.name in the client, which works (I get either WS or XHR as those are the constructor names), but that feels awfully brittle. It'd be rad if there were a standard way to do this.

Community
  • 1
  • 1
pfooti
  • 2,605
  • 2
  • 24
  • 37
  • 2
    socket.io.engine.transport.name is a bit shorter. You can also test if transport.ws is not null : if(socket.io.engine.transport.ws) wsfunc(...) else xhrfunc(...). I don't fully understand why you need this information in the client, as far as socket.io handles websocket and xhr connections in the same way. – Xodrow Oct 22 '15 at 20:07
  • Hmm, `if (transport.ws)` seems a lot better than relying on the class name being used for the transport (the latter being maybe subject to change in a later version). As to the use case, normally I'd load `/api/items/1`, `/api/others/1` and so forth over a https connection in another part of the webapp. Wiring these requests into the websocket means no TLS handshake overhead on each request (bascially a janky SPDY optimization). If the WS isn't present, it's more efficient to use normal http requests for api endpoint stuff and leave socket.io stuff for server-push realtime stuff. – pfooti Oct 23 '15 at 00:29

0 Answers0