Glossary

The Actor model is a concept in computer science used for developing concurrent systems. It was introduced by Carl Hewitt in the 1970s and serves as a theoretical framework for understanding how independent units can interact with each other without having to rely on shared memory resources.

Core Principles

At its core, the Actor model consists of three main principles:

• Actors: An Actor is the fundamental unit in this model. You can think of it as an autonomous, independent entity that has its own internal state, behavior, and mailbox. Actors are isolated from each other and do not share state. Each Actor can only access its own internal state.
• Asynchronous Messages: Actors communicate exclusively by sending messages to each other. This communication is asynchronous, meaning an Actor can send a message and immediately proceed with its next task without having to wait for a reply. Every message is placed in the receiving Actor's mailbox.
• Message Processing: An Actor processes messages sequentially in the order they arrive in its mailbox. When an Actor receives a message, it can perform one of three actions:
  • Create new Actors.
  • Send messages to other Actors (including itself).
  • Change its own state.

Advantages and Use Cases

The Actor model offers several advantages that make it attractive for developing modern, distributed systems:

• Scalability: Since Actors are isolated from each other and do not share state, they can be easily distributed across different processor cores or even separate computers. This makes the model ideal for highly scalable systems.
• Fault Isolation: A failure in one Actor generally does not affect the functionality of other Actors. If an Actor crashes, it can simply be restarted without the entire system failing.
• Concurrency without Locks: The asynchronous message passing and state isolation eliminate the need for locks and synchronization mechanisms, which often lead to complexity and errors in traditional, memory-based systems. The model significantly simplifies the development of multithreading applications.

Some well-known frameworks and programming languages that implement or are inspired by the Actor model are Akka (Java/Scala), Erlang, and Elixir. It is frequently found in systems that require high fault tolerance and parallelism, such as telecommunications systems, online gaming platforms, and cloud services.

An application is a service created by a factory. This factory is registered with a special registry and can start instances of its application via a message. Usually, applications in nyssr.net are just an entry point into the distributed service network, the first microservice to be launched, so to speak. Any number of applications and application instances can be run on one node.

The envelope is the part of a message that contains all information needed for routing and handling.
In other words, it defines how a message is transported, processed, and tracked.
Typical components include:

• Recipient address(es) in nyssr.net
• Sender address in nyssr.net
• Indicator whether the message is a reply
• Option specifying whether a reply is expected
• Transaction ID for linking replies
• Flags for compression and/or encryption
• Restriction preventing the message from leaving the current node
• Permission or prohibition for logging the message
• Marker showing whether the message has already been processed by the recipient
• Indicator whether the message is addressed to a nano-service
• Microservice ID if the message targets a specific microservice
• Instruction whether the message may be forwarded
• Status showing whether the message is blocked (e.g., not to be returned immediately)
• Session ID for identifying the session, user, and permissions
• Result code for replies
• Result text for replies
• Message priority (important for routing decisions at hops)
• Unique envelope ID for routing traceability
• Timestamps for sending and receiving, both outbound and return
• Optional routing hints

A message consists of two parts: the envelope and the record.
The envelope contains all meta-information for handling and transport,
while the record carries the message ID and the payload.

Before sending, a message can be constructed in two variants:

• the standard version that streams data into a ByteBuffer,
• or a custom JSON structure with appended binary blocks.

Both variants can be used in parallel.

During transport, the data is repackaged. This process creates a compact header containing all routing information in plain text,
as well as a binary block with the remaining parts of the envelope and record.
Since this block is not required for intermediate hops, it can be compressed and encrypted.

Message addressing is always direct.
Each message contains one or more recipients (as nyssr.net addresses) and a sender address.
No queues or topics are used – instead, the message is delivered precisely to its recipient,
processed there, and typically returned as a response.
If delivery fails, the message is sent back to the sender with an appropriate error code.

Microservices are services that can be accessed from the entire nyssr.net with messages. They have an API in text form (JSON or XML). Messages can be addressed directly to microservices. Microservices are automatically load balanced. They can be installed on any number of nodes.

A namespace provides a working environment for a plug-in, application, or microservice. It provides threads, registers targets, and has a local nano service registry. It encapsulates this environment from other namespaces so that, for example, hundreds of instances of the same application can operate simultaneously in the same node.

The abstraction of a small service that consists only of a single message, and whose implementation remains private. Nano services are registered in nano service registries, which are components of namespaces. You can address messages directly to nano services. Nano services are also used to distribute notifications.

Short name for namespace ID, which means the ID of a namespace.

A node is a program that runs somewhere on the network, connects to other nodes via TCP channels, and executes user software as plugins. All the nodes are identical, except for the plugins they run. Thus, a node is merely the platform for distributed user services and applications.

is a "nicer net".

Short name for queue ID, which means the ID of a message queue.

The Record is the part of a message that holds the payload and the Message ID.
The Message ID serves as a unique identifier, allowing the recipient to filter the message and enabling the sender to match responses to the original message.

The payload itself is stored in a map-like structure called Slots.
Each slot consists of an ID, a type, and the data itself. A record can contain any number of slots.

Type-Safe Data Handling with Record Definitions

To populate and read data from a record in a type-safe manner,
we use Record Definitions.
Although these are optional, we use them by default as they significantly simplify the process.

A Record Definition is a JSON or XML file that describes what data is expected within a record.
We use these descriptions to generate helper classes that provide secure, type-safe access to the record's data.
Since these helper classes are language-neutral, they can be used not only with Java but also with other programming languages in the future.

It is always possible to append additional data to a record—for example, to better handle a response—without having to modify the original definition.

In the decentralized nyssr.net, messages are the core of communication.
Our messaging approach differs significantly from conventional solutions because it relies on dynamic, latency-based routing rather than static routes.

In nyssr.net, messages are forwarded from node to node until they reach their destination.
To find the fastest route, it is not enough for nodes to know the overall network structure –
they must also take into account the latency of each segment.
The system automatically detects when nodes join or leave,
measures link latencies at short intervals, and distributes this information to all nodes.
Using a customized Dijkstra's algorithm, each node dynamically calculates the next optimal "hop."
Should network conditions change during transport, this is immediately taken into account,
allowing for a dynamic route adjustment.

RemoteSkin is a technique where a user interface on the client side consists of only one renderer. The counterpart on the server side runs distributed on one or more nyssr.net nodes. So the business code is executed server-side. During an update, usually only the server side is deployed. Currently, only a web and a Java Swing client is available.

RemoteSkin uses an interesting approach for the UI: dialogs or widget groups are implemented as microservices. These services can be freely distributed across the node network, creating a distributed micro-UI for the web and Swing.

There are several types of services in nyssr.net. If a service is simply called "service", it means an interface that has been registered in the service registry. This type of service can only be used within a node. There are also nano services and microservices.

is an abbreviation for Service ID. This refers to the ID of a nano service.

Just a beautiful name. Some claim sillysky.net is related to Skynet in the Terminator series. But we're just building a silly Skynet, putting in only modest intelligence and not letting the net gain consciousness. You are in charge of the AI.

A slot is a data element transported inside a record.
Each slot has an ID, a type, and the actual data value.

There is a set of predefined types that represent different data formats.

This list is expandable.
A record can contain any number of slots, making it possible to build very complex data structures.

A target is a Java object that can receive messages. To do this, it must implement the ITarget interface.

However, it is more efficient to derive an object from the CTarget class. This offers many conveniences:

• a message handler class where incoming messages are mapped to lambdas or local methods
• Methods for sending messages (sendRequest, sendNotification)
• Ping support
• Management of the own target address, deregisterTarget method
• there are callback methods (notifyTargetRegistered, notifyTargetDeregistered)
• a name for the target can be given (debug support)
• messages can be logged automatically (debug support)
• Support of self-destruction (in the absence of activity triggers)

Targets receive messages exclusively in the same thread. Therefore, it is easy to avoid concurrency errors. Likewise, resources can be safely shared with other targets if they are registered in the same namespace (and thread).

Short name for target ID, which means the ID of a registered target.

A timer in nyssr.net is just a message that is generated once or repeatedly after some time. A timer message can transport data.