Networking

This page covers the networking strategy, and act as a planning document outlining the features and provisions for the networking support planned as the focus target for the near-future 0.6.x series of releases.

Feature Plan

High-Level

There are multiple layers that will receive networking support, all as an opt-in and provided by (primarily) external tools. These layers are:

Input Devices
Clients
Appl-low
Appl-high
AGP

A big design difference to other display systems is that Arcan separates between a local API (arcan-shmif) that relies on the C ABI of the local OS as an overlay on shared memory - to implement near all of its communication.

Accepting some loss in functionality (file-descriptor passing based large buffer transfers), all communication can, post initial setup, work without any system calls allowing for more precise per-client sandboxing.

In SHMIF there are some specific considerations that were made to favour networking:

Audio - Buffer transfer model also include audio data per allocated container, allowing mixing / device routing to be performed later.
Synchronization tied to allocation - The API and communication is asynchronous except for allocations (including resizing) which act as synchronization barriers.
Segment-types - Each segment (losely comparable to a 'Window') carries an abstract type ('game', 'media', 'tui', ...) to allow domain specific compression- and compression- related parameters (bias for latency, buffering, ...).
Per-Allocation Density - A segment carries its own, dynamically changeable density- and fonts for mixed-DPI output purposes. Migrating a local client or even window to a networking translation service can thus adapt/alter its DPI to match that of the remote display server.
Migration - As part of [Crash Resilience]((https://arcan-fe.com/2017/12/24/crash-resilient-wayland-compositing/) each client is continuously tested/expected to be able to renegotiate its allocations on a 'RESET' or 'MIGRATE' event - allowing it to jump between different display servers, e.g. a main and a local network proxy.
Connection Points - The ARCAN_CONNPATH (comparable to X DISPLAY=:number) allows for a near infinite number of local shmif servers to be running in tandem, yet are 'consume-reopen' on use to allow fine-grained rate control.
Dynamic Decorations - To avoid mixing content types in the same allocation, decorations, e.g. border, shadow, titlebar, scrollbar are server-side default (including abstract labels for mouse cursors) and thus do not need to be transfered. Titlebars can be requested to be client provided, but a client always need to handle the case where such a request is denied.

These, combined with the libarcan-shmif-server library should be more than sufficent to cover all desired networking features.

Input Devices

A 'remote' input device provides similar facilities to what virtual KVMs like Synergy would. The arcan platform layer that provides the running 'Appl' (WM) events to the _input handler is normally the only one that is allowed to enqueue events of the EVENT_IO type and it is masked out for all external clients.

By opening a connection point where this mask is removed using target_flags, the connection- specific event handler will start accepting input events that act just like any other input device, but are routed to the connection specific event handler and can be multiplexed unto the normal input handler

local vid, aid = target_alloc("test",
    function(source, status)
    	if status.kind == "input" then
		      _G[APPLNAME .. "_input"](status)
			end
	  end

or forwarded to a specific client as normal via target_input,

For the client side, the ioinject example shows how the input sample synthesis would work. A similar pattern also applies to user-data IPC (clipboard), see the Aclip tool.

Replace the client with a networking version and we are all set in that area.

Per-Client

No direct change to the client side is really needed, as the connection point and migration mechanisms from connection setup and crash recovery works to redirect a client to a network translation service. Similarly, the contents of a buffer are typed to defer the compression selection parameters to this service.

The change needed to noticeably improve bandwidth are two-fold. One is to extend the buffer packing formats to cover invocations to the format selected for AGP.

The second, which comes with additional benefits, relates to TUI with the built-in terminal emulator as the prime test example. It covers getting a stronger, more network friendly, middle ground for multimedia- UIs which preserve segmentation and has a text-biased packing format.

Appl-low level ("ALT")

The Lua API (and the documentation) is slowly being rewritten to have a more autogenerated-serialization friendly definition. Combined with the facility for system-wide support scripts, a support script will be added that provides proxy- overrides for all built-in function calls with packing that is derived from the documentation.

This allows the Appl to be decoupled from the Lua VM inside the Arcan process and moved to a separate local process. The primary use for this is to replicate the external WM model from Xorg without the synchronization problems that otherwise entail.

The secondary use for this is to allow arcan-native appls to run remotely in a thin-client like manner, as a fallback if simply tranferring the scripts themselves would be undesired for security reasons. Since animations etc. is clocked separately from the display, the network clock can be provide a near seamless transition (assuming latency of the lower ~25Hz clock. The 'arcan_lwa' build is then used as a local renderer for these commands, allowing sandboxed interpretation of the 'draw commands'.

Appl-high level 'VNC-like'

This feature is already in place (and has been since about ~2012-2013) via the 'encode' frameserver. Combined with the define_recordtarget, the appl can define multiple arbitrary subsets of clients with separate composition rules and filters. These subsets gets rendered off-screen and forwarded to the 'encode' frameserver which implements VNC- style compression and serving.

AGP

All rendering done in arcan and arcan_lwa binaries go via an abstracted low level drawing system called 'agp', with backends in GL21 and GLES3. AGP covers about 50 drawing functions and is a minimal subset of the features that something like a full GL stack would provide. It carries much less state and synchronization than GL, yet provides enough functions for the data visualization and rendering done in durden/safespaces/senseye and so on.

A special arcan build that can act as a local renderer, and a mode switch for the normal arcan binary would allow remote low-level remote networked rendering similarly to what GLX would provide, sufficient enough for most 2D UI and 3D data visualization purposes - only complex games and the likes would need more opaque 'compressed buffer streaming', which the other networking modes already cover.

Feature Plan

Milestone 1 - basic features

Milestone 2 - closer to useful (0.6.x)

Milestone 3 - big stretch (0.6.x)

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Networking

High-Level

Input Devices

Per-Client

Appl-low level ("ALT")

Appl-high level 'VNC-like'

AGP

Feature Plan

Clone this wiki locally