For November’s PubNub FAQs, Stephen and I discuss the most common questions support received for last month. On this month’s inaugural episode, we go in-depth on:
For those of you who would prefer text to video, we understand, so here’s summaries of each discussion below:
In this case, a developer is working on building a telco solution to ring telephones, and was receiving CORS errors popping up in different browsers at random times for no reason.
On PubNub’s network, the way we send and receive data on long-lived TCP socket connections, but with a browser, they expect to have special headers, otherwise known as CORS headers to allow certain resources over that connection. If a CORS header is excluded from the payload on a response, an error is thrown in the browser.
These occur when a TCP socket is severed through the browser. Essentially what’s occurring is that the browser notices that it’s missing a CORS header, so no data is coming down the pipe. What really should be happening is the browser should give a TCP socket error saying ‘severed’ or ‘aborted’, but it’s been implemented to deliver a CORS error.
What you really want to look out for is data loss, and if you are, please contact support!
A developer is building a financial market data feed, and was experience bad gateways (otherwise known as 503 errors) when trying to publish data.
A lot of the time, you may be hitting a proxy in the middle that may be doing something outside the policy of the same TCP that PubNub has. We have an unlimited TCP policy for forever long-lived connections, whether it’s a publish message or a data feed through a subscribe call. The gateway can close the socket.
The best thing to do is enable SSL across the board and this alleviate all 503 errors from a proxy. They can’t modify headers, or throw extra responses down the pipe, and they can’t decide to close the socket when they want.
That’s what’s happening here. The proxy is being very courteous, sending all the proper HTTP headers essentially saying “Sorry, this is over. We’re closing it down. Try again.”
A developer is building an API management platform and is looking to recover messages that were missed while the client was disconnected. This is very common in a mobile situation where networks are constantly being switched and users are going through unreliable environments like tunnels or heavy foliage.
We have two mechanisms that you can use to do just this:
So when would you use one or the other? It depends on your objectives. What data are you looking to recover and how old is it?
With PubNub, we provide two layers of caching. One layer is an in-memory cache, a short term connection recovery automatic mechanism, for spiky connection loss (think tunnel, elevator, riding subway). This automatically recovers messages up to the last 100 which is our queue size limit.
The other is our forever storage feature (a separate API call), that allows you to recover any number of messages.
Got some questions of your own? We’re here for you! Reach out to firstname.lastname@example.org, visit PubNub Support or our Community Forum, or tweet us @PubNub.
We also have PubNub Office Hours at our San Francisco HQ, every Wednesday from 2-5pm, where you can get your real-time questions answered in real time. Give us a heads up at email@example.com and let us know you’re coming.
There are common underlying technologies for a dating app, and in this post, we’ll talk about the major technologies and designs...