[MUSIC] One of the most common approaches that ends up getting used to solve this problem of getting information or updates from the server to the client is what's known as Push notifications. Or depending on which particular platform you're on. If you're on Android, it's the Google Cloud Messaging. And the idea behind this is that every Android client, automatically sets up a persistent connection to Google servers, it's GCM servers, which are the Google Cloud Messaging servers. And this connection is done over XMPP, which is an XML based messaging protocol, that was originally used for chat messages. And the idea is, is that at any time because this GCM server has access to the Android client over XMPP, it can push information to it. So typically what happens is, is if you want to have a server that you're building that needs to push information to a client. What happens is, is when the Android client goes and establishes the connection, the initial, XMPP connection, what it gets back is a registration ID. And this is a unique handle or identifier, an address of this Android client on this GCM server and then what the Android client does is it sends its registration ID to the server, your sever doing something like a traditional HTP Push, I mean Post, or Put, or whatever it needs to do, depending on your API to your server. So now your server knows the unique ID of this Android client on, on this particular Google cloud messaging system. So what the server can do is when it wants to send a message to the client, even though it doesn't directly have a connection to the client, it can send a POST message over HTTP that has a specific format. The POST message tells the GCM server, the registration ID of the client or clients that the server wants the message delivered to. And then the actual body or the content of the message that should be delivered. And so this gets sent to the GCM server, and then because it has a persistent connection to the one or multiple clients that the server wants you to push to, it can then over one of these XMPP connections, send the message that the server provided to each of the clients that it specified with a registration ID. So, the idea behind this is the Android client is setting up a persistent connection to Google's infrastructure and each time and a client connects to this infrastructure, it's getting a registration ID. And libraries that are on the Android cloud automatically handle the issues of reconnecting when the connection has been lost because you were in an airplane or you went through a dead zone and you didn't have cellular coverage. The Android libraries automatically continually reconnect to the GCM server. And if you have a rooted device, this only happens and works if you have all of the Google Play services and apps installed on the device. But it goes and connects, it gets this unique registration ID. And then anybody that wants to send a message to this client can basically obtain that client's registration ID, so in this case your app gets that registration ID, sends it to your server, and then when your server wants to send a message to the client, rather than sending it directly to the client, it sends an HTTP message to the GCM infrastructure, the Google infrastructure. And the Google infrastructure based on the registration ID or IDs that you provide, figures out how to use its XMPP connections to automatically deliver the message. Even if you're using a Push type service, there's still some architectural considerations to think through when you're building your app. The first one is the style of notifications that you're going to use to update your app. So there's a couple different approaches, one is that you can have the client and the server and GCM and whenever the server wants to send an update to the client, let's say you have a server that's going to notify the client of people that are subscribing to that client's videos. So whenever the server wants to tell the client that a new subscriber has shown up, it would send the post message with the registration ID of the client to GCM with the identifier, let's say, the message is who subscribed, so it, it, it directly encodes in the message, the particular subscriber. And from that point, when the client receives the message, it can instantly update its internal state and be done. Now, this is certainly a viable approach as to just directly send all of the state information that you want to communicate to the client in the actual message bodies that you're pushing out over Google Cloud Messaging. And the nice property about this is that you get the message to the client as quickly as possible. You get it that state update as quickly as possible. Now, one of the downsides of this approach is that the messages that you send through Google servers are limited to four kilobytes, so this only works if you can send a state notification that is less than four kilobytes in size. For example if you wanted to sync actual video data, on the client, you're not going to be able to do this over Google Cloud Messaging. Google is not going to push out a multi gigabyte video, over cloud messaging to client. So this only works and is really designed for sort of small bits of information that you're sending. But, there's still a way to get large data pushed to the client. And the way that you do that is, you use essentially a push to sync model. So before when we were talking about polling, the problem was polling was that the client never knew what was going on in the server, it didn't know when it should go and poll the server to pick up information. But, with a push to sync model the idea is, is that if something interesting happens on the server that the client needs to know about it can push it to Google cloud messaging. The client can receive the message and then it can go and pull the server to get the state that it needs to know about. And so with something like this you could actually go and send messages that are greater than four kilobytes. What's happening is the server's sending an event that's pushed to the client, that then triggers a pull from the server. So, it's performing essentially the same function as if you were pushing out a large amount of data to the client. The client is being told to go and pick up new state information, and you can send it as much state as you want, it's just that it revolves, re, requires an extra round trip to your sever. Rather than directly receiving the message from Google's cloud servers. There's another reason that you might want to consider using a push to sync model, and that is if the data or the state that you're pushing out to the client is sensitive, and you are concerned about Google having access to it. So in our video example, it probably doesn't make sense. We've, we probably don't care about the messages that are being sent. But if, for example, you're building a health care based app, you might not want to send a patient data through a push notification, so if you post patient data to Google clouds cloud messaging. That may not be acceptable in your country and with your particular laws, and then have it delivered to the client. In that case what you really want to do is send a notification that tells the client to go and pull your server to get the data. And with this model you can control the security, so you get to control the data and the security that you use to deliver that data to the client. Now Google I'm sure has a very, very high security on their servers, but it's still important that you be able to control in many cases, the actual dissemination of your data and the security over that data. So the push to sync model is good when you neither need to push out large amounts of data or you need to be in strict control of that data's dissemination and the security over the dissemination of that data. If you just want a quick message to the client to update its state that doesn't require high security, then the push to, with a message body is the right way to go.
