io
ARES System Manual: io Daemon

input purge: Empties stale pipes.
input debug: Reports status of the io daemon.
input restart: Restarts the io daemon.

The io daemon manages a text forwarding system known as 'pipes.' Pipes are modelled on the same concept in POSIX (Unix, Linux, etc.) systems.

Whenever an application in ring 3 (user memory) needs to receive chat messages, send chat messages, or forward text to another ring 3 program, it does so by creating a rule with the io daemon, called a pipe.

Users rarely need to interact with the io daemon directly, but it can be useful to understand how it functions for debugging purposes. The command input debug will list the current pipes.

Typical output of input debug might look as follows:

· 00000000-0000-0000-0000-000000000010 · 0 · 2 ·  ·
· 00000000-0000-0000-0000-000000000020 · 0 · 2 ·  ·
· 00000000-0000-0000-0000-000000000100 · 0 · 2 ·  ·
· 43524553-5841-4e41-4455-434c49454e54 · 7 · 1 · ax · 00000000-0000-0000-0000-000000000000
· 00000000-0000-0000-0000-000000000001 · 14 · 1 · _input · d69ca06e-aa22-49e4-86e1-42677e26f3f5
· 5b196468-a47b-ad5d-87f4-e463ecc8e006 · 0 · 3 · filter bimbo · 00000000-0000-0000-0000-000000000a02
· 7e3a8ca1-e8b1-1f3d-30df-a22c46ddb409 · 0 · 3 · filter mumble 11 · 5b196468-a47b-ad5d-87f4-e463ecc8e006
· 00000000-0000-0000-0000-000000000a01 · 0 · 3 · filter replace honey · 7e3a8ca1-e8b1-1f3d-30df-a22c46ddb409
· 00000000-0000-0000-0000-000000000a02 · 0 · 4 · _input output · d69ca06e-aa22-49e4-86e1-42677e26f3f5

The first column indicates the pipe's unique identifier. These are sometimes randomly-generated, but many system functions use predetermined keys such as 00000000-0000-0000-0000-000000000001, which is the unit's chat input redirect.

The third column indicates the pipe's type:

- Type 1 indicates an input pipe, which listens for chat on a predetermined channel number and sends results to the specified command in the fourth column.
- Type 2 indicates an output pipe, which forwards chat to a UUID on a specific channel. If no UUID is listed in the fourth column, the result is sent to the whole region. The first three pipes in the example are used for whisper/say/shout output.
- Type 3 indicates a non-volatile invoke pipe. Messages passed to these pipes will trigger command executions akin to running system commands normally, but with the input stream set to the pipe UUID.
- Type 4 indicates a non-volatile notify pipe. These are similar to invoke pipes but are used for specific function calls; in the example above, NOTIFY _input output informs the input program that vox is done parsing an outgoing chat message.
- Type 5 indicates a file pipe. These are used by fs to provide data to user applications upon request. File pipes are volatile.
- Type 6 is a volatile invoke pipe. These are created to pass data when chaining commands, e.g. with the xset program.
- Type 7 is a volatile notify pipe. These are typically used by programs making calls with the requests API, such as receiving data from the web.
- Type 8 is a non-volatile transport pipe. These simply forward messages to the next pipe in the chain. vox pipelines use a transport pipe when the chain is enabled but no filters are active.
- Type 9 is a volatile transport pipe. These are not currently used by any program.

The distinction between volatile and non-volatile pipes is that volatile pipes are assumed to serve a temporary purpose and will be destroyed when ARES is rezzed (i.e., the next time it is re-attached or the unit logs in.)

Programs will naturally attempt to close their input pipes when they are done processing invoke messages. This is only successful if the pipes are volatile.

The equivalent of the io daemon in Companion was an experimental module called transceiver.