[MUSIC]. A challenge with mobile devices, is that if we use HTTP as the primary protocol for communicating with the cloud we run into the issue that HTTP is a client driven protocol. So what do I mean by this? Well, in all of our interactions that we've seen, we start with a client like a mobile device, that initiates the communication with the server by sending in a request. And so, the client is always driving the communication. And asking for a particular resources on the server. But one of the challenges we have is the client decides the timing of when it goes and checks for updates from the server related to data. So anything that's going to update data or the state of the, the client. Is going to require the client to make the decision about when it goes and actually talks to the server and tries to retrieve new data. So, if you think about this if you have multiple clients that are interacting with this server. So, let's say we have a second client, that's sending requests to the server. And the second client sends, sends a very important message which we will just do a little, yo u know, exclamation point. Sends a very important message to the server that this client needs to know about. Or some update to the data that this client just pulled in has shown up on the server. There is no way. For the server to easily initiate communication with the client to tell it to go and update that data. If we use the standard request response model for communicating with the cloud over HTTP, we'll always run into situations where we can't have the server push data that it needs to send to the client. At exactly the time that the client should have it. So how can we design around or handle this issue of, the fact that all of the communication is driven by the client. The client decides when to grab the information from the server, and the timing between when it goes and pulls information. One way to handle this issue, is to let the user decide when data is fetched from the server. So a common way that you'll see this done, is you'll see a user interface, particularly with list views, where we have data, and there is a pull down to refresh. So there'll be some status refresh indicator and if you pull down. What's really happening is that when you pull down far enough, the client is going and sending a request to the server and then getting the response back. So this time that you see that little spinner driving around. What's actually happening is the client is waiting for the data to comeback so that it can update its list that it's showing. And this can be an effective way to handle the issue of going and fetching data from the server. You can let the user decide when they want to update the display. And in many cases they will have an appropriate. You know, appropriate knowledge and make good decisions about when to go and update things. So this is certainly one valuable approach. You can do other approaches, where for example every time this view is opened it automatically updates itself. Or every time the app is launched, it automatically goes and synchronizes its data with that that's on the server. And those are all valid approaches that use sort of an event driven model. Where the events are coming from user interactions with the app. And the nice thing about this approach is that the user isn't going to typically go and just refresh over and over. Or at least for not expend, extended periods of time. At some point the user is going to stop refreshing and give up. And you're going to stop sending requests to your server. So the user gets to kind of make the intelligent decisions about when it makes sense to actually go and fetch something from the server and when it doesn't. Another model that you can use to try to keep the client up to date with information from the server, it's called polling. So, the idea behind this is, the client starts up, the server is available. And while the app is running, or while some service in the app is running, the client, at regular intervals, continually requests data from the server. And you'll have some time interval that is decided by the client. Some time interval like T and every T intervals time units of T, like every three seconds the client will go and send a request to the server to try to refresh. The problem with this is that. You run in the situation that if you have a client open, even if there is no actual data on the server for it, the client doesn't know that. It just has to blindly continually end request to the server hoping that it gets something back. So, while you're sending all of these requests to the server. You're wasting resources on your server. Because every time you send a request to the server and there's nothing there, the server still has to allocate resources, process the request. Check if anything is available for the client. And then if nothing is, send back a response. You're using up network resources, memory and cpu on the server. And if you have lots of clients, they're continuously requesting data, you're multiplying the traffic and the effect on your server in terms of the resource usage. So, polling certainly can give you the effect of very up to date results to the client, but it can come at a very significant cost. To the resources that are being used up on your server. Sometimes approaches are used to try to make the client adaptively decide and adjust it's time interval when it's not getting data back. So the idea behind this is, is that. If things are updating rapidly in the server, then each time the client sends a request or every few times that the client sends a request, it should get a response back. And so the adaptive approach is essentially start off with a single time interval that's short. So we'll go and pull it you know, every t seconds. And then if a certain number of requests come back with no updates, the client will automatically switch to a new polling rate like two T. So it will wait twice as long to send the next request. So rather then waiting six seconds, I mean three seconds, it'll now wait six seconds. Similarly, if some number of requests come back empty, then the client will automatically see it's wasting resources in the server, so it'll switch over to a new model like 4T. And continue to increase and typically it's an exponential increase of the time between when, it receives a request a response for a request, until it sends the next request. So the client can begin adaptively tapering off its requests to the server, because it sees that there's not a lot happening that, not a lot of updates that are of interest to that client. And typically, there will be some ceiling to this update link. So at some point, you'll get to maybe an hour between updates, and the client will no longer update any faster than that. Up until the point that it gets some results back, in which case that it can switch back to the more, rapid polling rate. So, once you do get something back, you can back to the lower polling rates and continuously check to see if things are coming in, that you should know about. So, this model really tries to adapt and improve the resource utilization on the server by having a client. Only poll when things are happening that it can detect. Another approach to handling this issue of trying to get updates from the server to the client when you're using HTTP, is to rely on one of the newer HTTP based protocols, like web sockets. So with web sockets, the idea is that, when the client connects to the server, it can ask to upgrade the connection to a web socket. And once a web socket has been created, the idea is that the client goes and sends a request. It updates the connection to a web socket. And rather than being purely client driven, once this web socket is established either party can send data to the other one. So the server at any time can push data down to the client, and the client can push data down to the server. All of this however, depends upon the client being connected to the server. Now the nice thing about web sockets are that, we don't necessarily incur the message overhead that we typically do with each request and response from a server if we're using the HTTP protocol. So, normally if we send an HTTP request, we're going to send all of the header data all of the other information, the resource, the URL, all of this stuff is going to be sent to the server. And then every time the server's going to send back the content type, the body, any headers that it wants to send back. And there's a lot of communication overhead. And if we know very specifically about the protocol that we're expecting the server to speak to us. We can write simpler protocol on top of web sockets that has lower overhead. We can send smaller messages that don't include all of the typical HTTP. Headers and other things that we need. We can just simply send binary messages or some other format back and forth in a server. And so we can potentially have an increase in efficiency. We can also have the ability now to have the server push data whenever it wants to the client. So in a number of aspects, this is a much improved approach to just directly using HTTP. The downside of web sockets with a mobile client is we still run into the issue that clients are mobile in nature and their connections drop. And so, a web socket can be used to push data from the server to the client. But only as long as the client is connected to the server. So if we do use Web Sockets. We have to deal with the fact that we may, let's say for example lose cell signal. And then, we need the client to automatically go and reconnect and then upgrade its connection to a web socket again. So, if we go with a web socket type approach, we have to deal with the air handling of doing the reconnect whenever we notice that a connection has been dropped. So we have to have our own event mechanism and notifications to detect that something has happened, we've dropped this web socket connection. Keep going and trying to reconnect until we get connected again. And that in itself is its own sort set of logic that you have to think about is. How do you decide when to reconnect? Do you wait until you get an even from Android telling you that the internet connection has come back? Do you test the internet connection to see if it's fast enough to support what you want to do? There's a whole host of sort of logic that has to be built in to decide. Or you may just regularly try at different intervals to reconnect. And also what happens between if you have changes in the client and changes in the server and how do you synchronize and other things. So, web sockets is a nice approach. You just have to be cognizant that you have to go deal with your own reconnection logic. The other issue is that web, web sockets can be more heavy weight on a server. So, for, you can imagine if you have a client that's sending HTTP requests, if it doesn't actually need any data, it can let go of the connection to the server. And no resources are being taken up on the server. With a web socket we're going to have a persistent connection, which depending on how the server is implemented, could be substantially more overhead. It may make it so that we can't support as many simultaneous clients. Or it may be that the trade off in the reduction in message overhead, particular for polling, is much better with web sockets, and so we get more out. But, we have to be cognizant of that keeping an open connection can have substantial resource impact as well, if we have millions or hundreds of thousands of clients. It's something to consider with an approach like this.
