For home devices to communicate with services running in the cloud, we have available to us a plethora of networking protocols and techniques some of which are fairly new and others that have stood the test of time. For the purposes of Padium, we’ve narrowed down our categories of protocols into three general areas that we would exploit depending on the scenario.
Request-Response type protocols lends itself for the simplest scenarios and likely the most used. Basically anytime a client needs to request a some data synchronously or needs to initiate an action, you would typically want to use this type of paradigm. Historically this type of methodology has gone through lots of different evolution such as CORBA and SOAP. Today the new hotness is using REST over the HTTP protocol. Without discussing the well known merits of REST vs other methods our decisions to use REST/HTTP rest (no pun intended) mainly on that fact that they’re easy to deploy and tons of frameworks and systems exist to be able to support this type of infrastructure. Linc, our digital cooking assistant, makes heavy use of custom REST APIs over HTTP to perform a lot of its functionality. Specifically for accessing our huge library of digital recipe walkthroughs, storing client preferences, and keeping track of our customer’s help, REST allows us to quickly and securely deploy services that enhance the overall Linc experience. HTTP2 is what is used by us internally due to its low overhead, better performance from older versions and newer features that we can easily leverage.
Another very popular messaging pattern that tends to compete with request-response are pub-sub systems. In some cases these two patterns overlap, but in a lot of important situations they can solve very different use cases. In situations where we have multiple clients needing to communicate the same data, such as a chat application or some sort of real-time messaging board, pub-sub protocols tend to work great and has a huge advantage over typical request-response systems. Typically these systems deploy a message broker, who’s job is to be the central point where clients can send and receive messages from. The advantage of the broker model is that clients can operate without needing to know any connection details or having any dependencies of other clients that will send and receive data from you. For lower powered devices, the MQTT protocol has become a new popular standard for providing a pub-sub protocol due to it being specifically designed to provide low overhead and generally a small footprint. With Linc, we use this type of system for any situation where we would allow Linc users to communicate with each other either via the Linc device itself our the companion smart phone application.
Live Streaming Protocols
For both request-response and pub-sub messaging patterns, we have the benefit of being able to operate well in potentially “hostile” environments that client networks might be in, such as over weak mobile links, high latency home networks, or long distances from our cloud environments. Unfortunately streaming protocols are generally not as robust in those situations, but they are still very necessary in order to support sending and receiving lots of live video and audio data between clients and servers. For Linc and other upcoming Padium projects, we’ve come to the conclusion that for live media streaming, the best implementations tend to be custom protocols built on top of TCP as it tends to give you the most flexibility and also because available open source frameworks tend not to be as robust in this area. We still use protocols like RTP for the actual media data payloads but it is encapsulated in our custom protocol called ‘Padtalk’, which I will give more details about in later posts.