Networking
Networking is a critical function in KOS. Hardware is abstracted using adapters which run over network sockets. The default ui layer in KOS is browser based, which relies on endpoints and real time websocket events. But even more fundamental is KOS multi-node support, allowing a single device to be made up from a collection of KOS nodes that operate as a single distributed device. This means that many core KOS services are inherently distributed in nature.
Networking in KOS consists of four logical layers that work together to provide rich connectivity between applications, browsers and nodes in a KOS device. Even when running a single node KOS device, many of these networking concepts are still in play so it’s important to have an understanding of the KOS network stack.
VPN Mesh Network
At the lowest level of the stack is a vpn mesh network. For multi-node KOS devices, where there is more than one board running KOS as part of a larger distributed device, KOS starts by forming an ipv6 link local network with an overlay VPN mesh network. This network is constructed as part of the node discovery process within KOS and allows all nodes in the device to be connected by vpn so that all messaging between nodes in the device are encrypted. All other networking layers run on top of this encrypted network.
IP Network
The next layer in the networking stack is a typical ip based network. This is used by the node manager application to link all the nodes in the device to the primary node. This is the only part of the stack that relies on ip addresses to establish connections within the device. As part of forming the cluster, every node is notified of every other node in the device which forms the basis of a name resolution system based on node ids.
Node Network
Once the device network is established, all higher level networking operations use node ids as addresses rather than ip addresses. When adapters connect to java, it uses a node id. This allows adapters to be started but blocked until the target node is discovered. If the node goes down, the adapter goes back to a blocking state waiting for the node to be discovered again.
Even browser based operations function on node ids. Within KOS, a browser can be sent a url which targets a node id and KOS will automatically perform name resolution to route the browser to the correct node.
As every node in a device has a unique and well defined node id, this allows application logic to bypass the complexity of name resolution and ip address management and work directly with nodes and node aliases.
Websocket Network
The final layer of the KOS network stack is the websocket mesh network. Every node in a distributed device establishes a websocket connection to the primary which forms a fully routed virtual network for websocket messages. Any client connecting a websocket to any java node in the device automatically becomes a client on this network. For example, every browser establishes a websocket connection which means that browsers can not only interact with java, but can also communicate directly with other browsers using the device.
Combined with the extensive infrastructure built around this network, certain use cases become very easy to solve. Consider a two node device, each with a small side by side screen. Due to space constraints, the user interface needs to appear to span the two screens even though they are connected to different boards. It is now possible to have the web applications running in these two browsers to communicate directly to share state and navigation events in real time without any java back end.
The more common use case however is leveraging the websocket network to mix operations and events. Consider triggering an asynchronous operation from an endpoint, such as a pour operation that will take 20 seconds to complete. During this time the ui should show a progress bar indicating progress of the operation, while also updating immediately if the operation fails. Using standard http requests, there is now way to return the progress data. As KOS makes extensive use of real time events and asynchronous progress data, we leverage the websocket network to perform all endpoint operations as we can simply direct progress data back to the same client.
Another major advantage of the websocket network is support for strictly ordered operations. Consider a button on a screen that starts an operation when pressed and stops the operation when released. If a user taps the button quickly, the start and stop operations may be generated less than a millisecond apart. Using http to hit endpoints may result in the events arriving out of order as the browser can have multiple connections to the server. Once on the server, the requests can be processed in a thread pool which again runs the operations out of order. Since websockets are strictly ordered, KOS provides a message header that allows incoming messages to be processed strictly ordered for key control operations that can have significant impacts when run out of order.
The websocket network uses a standard message format, but supports multiple protocols, including the ability for developers to overlay new protocols on top. KOS provides support for http over websocket as well as message broker support and asynchronous process information which is combined together in various frameworks to provide seamless ui functionality for complex use cases.
