Networking is a critical function in KOS. Hardware is abstracted using adapters that run over network sockets. The default ui layer in KOS is browser-based, which relies on endpoints and real-time websocket events. Even more fundamental is KOS multi-node support, which allows a single device to comprise 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 essential to understand 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 is 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, they use a node ID. This allows adapters to be started but blocked until the target node is discovered. If the node goes down, the adapter returns 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 that 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, meaning that browsers can interact with Java and communicate directly with other browsers using the device.
Combined with the extensive infrastructure built around this network, specific 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 and share state and navigation events in real-time without any Java back end.
However, the common use case 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 the progress of the operation while also updating immediately if the operation fails. There is no way to return the progress data using standard HTTP requests. As KOS extensively uses real-time events and asynchronous progress data, we leverage the websocket network to perform all endpoint operations, as we can direct progress data back to the same client.
Another significant 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 runs out of order for the operations. 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 they 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, message broker support, and asynchronous process information combined in various frameworks to provide seamless ui functionality for complex use cases.