Towards one-time fee #1

I have been quiet in the last weeks but it doesn’t mean that I wasn’t coding. Today we released firmware 0.0.127 which should roll out in the next 24 hours to your devices. The sole aim of the update is to drive our costs down which might be looked at as or own internal problem, but in the name of transparency I’d like to share some ideas behind it.

These are the hits we need to avoid :-)

Our low cost — your win!

First — the update will bring two known issues, which will be addressed later but we need to get some data before I commit too much to the path I outlined myself. Simply put, if the outcome will not be as we expected, I’d take another path and will not be losing my time crafting the UI.

The two issues are following:

1. The traffic charts will show BIG gaps and, in fact, will not be accurate.
2. After logon, you may see that the Last Seen time is somewhere far in the past. This should fix itself after reloading the page.

As I told, these issues will be addressed later but it is important for our testers to know that it is known limitation for now.

Second — I’d like to share the idea behind targeting the one-time fee and thus behind the lowering the costs. I plan for another post, called Towards one-time fee #2, which will uncover some business related topics, but for now, believe me, the rationale behind is not that much about increasing our own future profits, but more like even about the possibility to maintain the infrastructure for “free” for our customers.

How it works internally

So let’s look behind the scenes and look what’s going on when one has a cloud console (the Altiwi dashboard) and the Device (actual access point). Right now, the devices are contacting the console each 10 seconds and basically do following actions:

1. Inform the console that they are alive. The console then notes the last_contact time to the database.
2. Looks for remote command, if any (like reboot, update, do a tcp dump, etc…).
3. Looks if there is a newer configuration available. If so, download it and apply.
4. Uploads the traffic stats.
5. Uploads the Client list along with the content of the DHCP table.
6. Uploads the device metrics, like uptime, load, IP addresses etc.

There are two requirements going basically in the oposite direction. It would be nice to have always the most recent and also most granular data available. Would not be even nicer to hammer the server each five seconds? On the other hand, such an approach will cost money. Substantial money. To put it in perspective: Each requests is billed and costs almost nothing on AWS. Tens of thousand requests a month (do the math, it is a magnitude of one device on such rate) costs real money. The price paid for the API requests, actual runnning the code and hammering the database would wipe out our margin earned on one device in some 3 months. For how long could we keep customers happy?

So the idea behind is following: Whenever possible, stay quiet. Do not send anything to the console. And do it only when the user logs into the console and selects the network. In such case, keep him informed on what’s going on almost in a real time (“real time” in our case means the 10 second granularity) for a limited period. So after 1 hour inactivity we will go into the silent mode again.

It is quite possible, because as you can imagine, the device does not need to see the console to perform its job. Remember: Function number one: Provide wifi access to clients :-) In fact all the standalone devices around th world do not have any connection to any consoles and work fine, so let it be so with Altiwi.

There is no point of storing the data when nobody looks at it, right?

Of course, there is a glitch. How can a device get know that from now on it should start to bombard the console with the stats? How it could know that there is a new configuration ready for it? Well maybe we can contact the console just each one hour? No, thanks, that would not be too much interactive experience for the customer. If I would not like it, I cannot expect my customers would like it. So we thought out a different approach.

The device is always connected (more on that “always” means later). But the only what it cares for is the info, if there is a wake-up command, which is issued only when the user connects to the console. In such case it starts to frenetically upload the stats data to give the user real interactive experience. Once the user logs out, the activity times out and the device goes back to a “sleep” mode. Note, the “sleep” mode means that it is not hammering the console, it has nothing with sleeping or turning the device off.

The “always connected”, as of now, means that we still do a web requests to the console each 10 seconds. But we simple do not update any info, we do not ask for a new config (as there cannot be a new config, when there is no human who’d modify it, right?). As of firmware 0.0.126 and above, this is pretty much how it works. We need to observe the stats from our servers to evaluate, how it turned out. I personally expect that there will be need for a bit different approach to the “always connected” concept which would employ web socket connection but for now it is what we have. Let’s see.

Above scenario brings some drawbacks. Mainly the two issues mentioned in the beginning of the post.

I will start with the easier to cope with — the second one. When you log in to the console, the wake command is issued and the device will start to upload the data, including the time of last contact. As we shown, the “allways connected” interval is ten seconds, so there is a good chance that whenever you log into the console, the last seen data would be as of your last visit. In ten seconds it will show the proper time (e.g. the known “less than 5 seconds”). After reloading or clicking anything else. We will reload it via asynchronous call later, but don’t care much for now. This issue will be solved by implementing following algorithm: a) the console will take note of last constact in case it is more than 1 hour, so the last contact time will never exceed 1 hour for live devices. The database write will occur not each 10 seconds but only once an hour, which, I believe, we can accomodate. b) The Last Seen reading will change into following: Disconnected for last seen longer than 1 hour, probably with the exact time it has been really last seen. Connected for the interval between 1 hour to 5 minutes, and last but not least the exact time you know, like less than 10 seconds.

The first one — the traffic charts are more difficult to solve. Right now it is easy to work with as we simply send the stats of all interfaces each time we connect to the console and are leaving the heavy lifting on the server. The server knows that the data are from current hour and updates the database accordingly. The change will involve stacking the stats for last 24 hours on the device and uploading the data at once on wake command to present the user the stats for last 24 hours. Will need some work, but nothing impossible. It has at least one apparent drawback — in case the device losts its power, the stats will be lost. Yes, true. So what? :-) It is the price for the one-time fee. By the way, if you are using any similar wifi access point, you’d lost your stats (if even any do exist) anyway. So it is not a big deal.

Conclusion

So keep in mind that the difficulties you might encounter are just temporary. I will definitelly keep the thing running a few days as it is, if there would not arise any catastrophic issues, of course, and in the mean time I will implement above proposed ideas. Asking why this have not been there from day one? Didn’t you know that you would eventually need such an approach? Why did not you make it from the start? Sure, I was aware of it, but first, the devices has to work, those issues are the invisible (okay, now quite visible) ones that has to be handled before production.

And again — huge thanks to all our beta testers over the globe, your testing, your feedback and in some cases even no feedback (we observe the logs obsessivelly) helps us to make Altiwi better! Next part would be a bit about the business questions as there is a couple of questions from you piled up, so stay tuned!