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 that can be started and stopped by a user at runtime.

Function and Purpose

Applications serve multiple purposes: as a Frontend (with an optional user interface such as Web or Swing), as Batch Processes for background tasks, or as so-called Application Starters that offer other applications for the user to select.

Technical Architecture

Technically, the application is a special service instantiated by an Application Factory. In nyssr.net, applications merely function as the entry point into the distributed service network—essentially the first microservice to be launched.

Scaling and Hosting

Any number of applications and instances can be run on a single Node. In line with the principles of a distributed service network, the host node is irrelevant; applications can be started from any node.

Startup Process

The startup is initiated by a message sent to the Application Registry. Using Load Balancing, the Registry selects an Application Factory on an available node and forwards the message to it. After the application instance is started, the caller receives the instance's address in a response message, allowing the caller to communicate with or terminate the instance.

Structure and Modularity

nyssr.net applications are typically bundled in their own PlugIn. They are generally kept small and modular: Often, even the main dialog is implemented as a separate Micro-UI Service (within its own PlugIn). All subsequent dialogs and widget groups are also separate, scalable services that can be reused by other applications.

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

Location Transparency is a fundamental concept in nyssr.net.

It means that the way you interact with a service—namely, by sending a message to it—remains identical, regardless of whether that service is located on the same Node, on a neighboring Node, or on a distant Node.

We distinguish between different service types:

Microservices

You reach Microservices by specifying the MicroService ID in the message envelope. The system initially sends the message to one of the Microservice Registries. The Registry performs a lookup, potentially finding multiple instances of the service on different Nodes, selecting one service, and forwarding the message to it. With the reply to this message, you receive the service's direct address and can subsequently interact directly with the service without detours.

Nanoservices

Nanoservices work somewhat differently: Nanoservices are bound to a Node's Namespace; their ID is the Message ID. You must know the service's Namespace (consisting of the Namespace ID and Node ID). Typically, global Nanoservices are registered in a Node's SYSTEM Namespace. Therefore, you can communicate with a Nanoservice on any Node if you know the Node ID. You only learn the address of the Target (=Actor) offering this service with the reply.

These mechanisms allow you to run a complete system on a single Node. You scale by adding Nodes and starting services on them. You don't have to change your code or require configuration for your application.

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.

Architecture and Communication

Microservices are autonomous services within the nyssr.net ecosystem. They communicate exclusively via asynchronous messages and operate as Targets, following the Actor model.

Service Types and Instantiation

Services fundamentally fall into two types:

• Simple Services/Singletons: These services communicate directly and exist persistently (e.g., a central Registry for configurations).
• Factories: These services instantiate the actual business services upon receiving a request (e.g., a specific frontend dialog for a browser session) and transmit the address of the new instance back to the requester.

Addressing and Load Balancing

Since services typically lack a fixed address, both simple services and Factories register with a central Microservice Registry using a unique Microservice ID (Integer, UUID, or String).

When a requester wishes to initiate communication with a simple service, the message is addressed to this Microservice ID. The system forwards the message to the Registry. Because identical services can be registered under this ID across numerous nodes, the Registry performs automatic load balancing: it selects an available service and forwards the message to it.

The response from the selected service includes its specific address in the envelope. This allows the requester to continue subsequent communication directly with that service. In the case of a Factory, the response contains the address of the newly created service instance.

Addressing and Load Balancing

The Microservice API is text-based, typically using JSON or XML. This design choice ensures high language independence, as no specific code interfaces are exposed. Instead, a tool is used to generate type-safe classes from the API description, guaranteeing the correct construction and parsing of messages.

Scalability

The load balancing mechanism provided by the Registry is the core feature that permits the installation of Microservices on any number of nodes, thus enabling efficient horizontal scaling.

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.