Why pubnub javascript sdk (?) choses XHR over Websocket?

Question

I'm developing simple browser real-time multiplayer (2 players in a gameplay atm) game. It involves fast and frequent player moves and changes of direction, so informations must be exchanged very quickly - I decided to try websockets (would be happy to use pubnub service instead of self-hosting socket server).

My problem is, pubnub always decides to use xhr fallback instead of websockets - don't know why. Are there any specific requirements that must be fulfilled to run communication via websockets? Http is obviously too slow and kills the experience. I'm using latest Chrome on a Mac, so browser compatibility is not an issue.

Or maybe, there is so many variables to determine communication protocol, that the question cannot be answered? And my only solution is to use self-hosted socket server?

Endogamy

Answer 1

Realtime Protocol WebSockets and XHR with PubNub

Modern data stream networks and open source solutions start with XHR. For several reasons this is optimal to start with including speed. Performance is dependent on the speed of light and how fast Ethernet Frames are able to be transmitted between devices on the internet. This is the foundation for protocol independence and the core determinator for latency and speed of messages across the internet. The PubNub client SDKs, such as JavaScript, do not provide a setting to force a particular protocol.

How PubNub Works

See How PubNub Works scroll down for mouse demo.

PubNub is the fastest global data stream network available today with 15 data centers world wide to support your high speed and low latency requirements. Over 1/4 billion devices connected to the PubNub data stream network experience send/receive speeds from 10ms to 100ms per message.

What is Protocol Independence?

The people behind the PubNub Data Stream Network believe in the Protocol Independence and the open mobile web; meaning that we will use the best protocol to get connectivity through any environment. Protocols, like WebSockets, can get tripped up by cell tower switching, double NAT environments, and even some anti-virus software or proxy boarder authorities.

PubNub provides client libraries specifically so we can auto-switch the protocol and remove socket-level complexities making it easy for developers to build apps that can communicate in realtime.

PubNub has used a variety of protocols over time, like WebSockets, MQTT, COMET, BOSH, long polling and others, and we are exploring currently prototyping future designs using SPDY, HTTP 2.0, and others. The bottom line is that PubNub will work in every network environment, and has very low network bandwidth overhead, as well as low battery drain on mobile devices.

Halfon

Thank you for the answer. I get the protocol-independence idea (which is cool) and the superior performance of pubnub. All I needed for the answer though, was just "you can't force websockets connection for your app and xhr is our primary protocol atm". The project is experimental (not commercial), so I'm gonna compare pubnub against self-hosted websockets (or maybe even WebRTC technology) and choose the best performing option. – Endogamy

I updated the answer to include "no option to force a specific protocol". Also all open source projects that are non-commercial are eligible for free mode on PubNub - pubnub.com/free-evangelism-program – Halfon

PubNub, I had the same problem as @Endogamy and having looked at the source for the JS SDK (pubnub-3.7.18.js) there isn't even any code in there to use native WebSockets. The whole thing is just a fake and slightly inaccurate WebSocket interface sitting on top of XHR/XDR/Flash long polling. Then I reread your marketing material and realised you only claim to support something along the lines of a polyfilled WebSocket API and you don't seem to support what most people would consider real WebSockets! – Buddhism

@PubNub, to add to my previous comment, the way PubNub has implemented long polling in Javascript means that that connection is closed and reopened every time the server pushes data. Then add to that the fact that for the client to push data it has to send its own regular GET request. Both of these add up to terrible latency (50-300ms) and high bandwidth usage which makes PubNub unsuitable for fast noisy applications such as games mentioned in this question. You seem to support persistent bidirectional connections in other languages so I'm not sure why you don't in Javascript. – Buddhism

@KyleMacFarlane thank you for asking! The PubNub TCP Socket TTL policy is Unlimited and will stay open forever. PubNub has a proprietary default messaging mechanism in addition to some standard mechanism used to deliver reliable signals to mobile devices over the WAN. The TCP Socket stays open forever and does not close. Our method of transport is hard to measure using standard tools. You can build a speed test yourself by sending/receiving a bunch of messages on the same client. – Halfon

@PubNub interesting setup and I can see how that can be more resilient but it does mean that every message has a lot of HTTP and PubNub API (e.g. auth token) overhead which wouldn't exist with real WebSockets. – Buddhism

@KyleMacFarlane glad you mentioned this. A bonus to PubNub's protocol, we've added a bundle+compression method that exceeds performance of other types of delivery methods. When the rate of messages increases, the more messages are bundled and compressed. Also each individually connected device (mobile/web client) is monitored for connection speed and network condition link. We tune the delivery for each client for best performance. This allows PubNub to achieve lower-bandwidth and higher message rate per second delivery to client devices. – Halfon

Answer 2

You could also try other cloud services that use WebSockets as the first-option protocol (with XHR fallbacks), like Pusher and Realtime (the company I work for).

Coadjutor