"The Internet of Things - a techie's viewpoint" by Jan Newmarch is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Based on a work at https://jan.newmarch.name/IoT/.
Programming involving one or more processes or threads on the same machine or on different machines is different to a single-threaded process on a single CPU. The complexity comes in as soon as one thread or process needs to communicate with another.
When a single machine is used, there is the possibility of shared memory between processes or threads. There has been an immense amount of work done on such programming models and reading about Java multi-threading is a good place to start.
We are more interested in communication between processes typically on different machines where there is no direct linkage between the different processes. (We ignore, for example, Unix processes forked from a common ancestor).
Distributed programming involves processes finding each other, setting up a communications model, agreeing on a common data format, and exchanging information and acting upon it. There are many such models, only some of which are of interest in IoT.
The IP Internet Protocol is the foundation of most networking at Layer 2 currently. The most obvious component is the addressing scheme used for hosts in the network, either IPv4 or IPv6 addresses. For the IoT, IPv6 and in particular 6LoWPAN is likely to be the predominant networking at Layer 2 for resource constrained nodes.
TCP and UDP are the two principal protocols above IP. There are in fact a large number of protocols, although only a few others such as Delay Tolerant Networking (DTN) may also prove to be useful. The differences between TCP and UDP are well-known:
TCP is slower and more energy hungry than UDP. HTTP is built on top of TCP, and successive versions of HTTP have made better use of the TCP model. Nevertheless, TCP and HTTP are difficult for low-power devices, and an equivalent to HTTP - CoAP - has been devised for UDP.
TCP programming is based on Berkeley sockets model. This is implemented in C, and all languages to my knowledge will use this socket model to communicate between clients and servers.
Sockets are indentified by an IP address and by a port number.
Well-known ports include SSH (port 22), HTTP (port 80),
HTTPS (port 443) and so on. On a Linux/Unix system these
are documented in the file /etc/services.
A socket connection establishes a session between client and server. This is reliable (to within network reliability) with guaranteed order of packet delivery.
Establishing a socket requires a 3-way handshake. Packets are acknowledged, leading to extra network trafiic. On anything at or above a Raspberry Pi the overheads are ignorable. At the microcontroller level the overheads may use too much memory or too much power.
TCP programming requires a high-enough level of processor and network capability. It will not be suitable for al IoT devices. Even then, TCP does not include any secueity measures: packets are sent in the clear, and there are no integrity checks.
In UDP programming, individual datagrams are sent across the network. UDP does not build a session, guarantee delivery or guarantee order. In a LAN, the physical layer will often give you all of these, but not across the internet.
This lack of guarantee leads to substantially lower overheads, and means that UDP can run much more readily on constrained devices. At the IP and above layers, UDP is preferred for resource constrained devices.
Additional features such as guaranteed order may need to be added to UDP. Eventually perhaps a new protocol UDP++ may emerge but at present it is too early to know what is required.
Once you have TCP or UDP, there are a multiplicity of programming models can be built. Theses include remote procedure calls (e.g. RPC or SOAP), distributed objects (e.g. Corba), mobile agents (e.g. Aglets) and many others.
Much attention has of course focussed around HTTP as the programming model of the Web. REST (Representational State Transfer) supplies the abstract model for HTTP, and both these and CoAP - REST for constrained devices - are discussed in the following chapters.
REST, HTTP and CoAP appear to the principal models for network communication for IoT.
This chapter has discussed very briefly the programming models appropriat to the IoT. Some of these are fleshed out in successive chapters.
Copyright © Jan Newmarch, jan@newmarch.name
"The Internet of Things - a techie's viewpoint" by Jan Newmarch is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Based on a work at https://jan.newmarch.name/IoT/.
If you like this book, please donate using PayPal