Technical Overview

This page gives you a technical overview of nyssr.net.

The Net: nyssr.net is a network of Java nodes that are interconnected via TCP channels. Messages are transmitted through these channels.
The Node: A node consists of a small 1.3 MB kernel, which loads additional functionality through plugins. A single node has the capability to load hundreds of plugins.
Plugins: Plugins are usually small JAR files that provide services for the network. In most cases, plugins are limited to a few services per plugin, as any number of plugins can be loaded.
Services: Services can be local services that are registered as an interface in a local service registry. Others are microservices and nanoservices that can be used by the entire network.
Local services: Local services are interfaces that are registered in a service registry. Services have dependencies that must be resolved in a dynamic, asynchronous environment before they can be used. This is not done by injection, as code is loaded dynamically. Therefore, there is the concept of service starters, which define their dependencies and are started when these can be fulfilled.
Microservices: These services have a message API and can therefore be used by the entire network. They are registered on a microservice registry with a microservice ID.
Nanoservices: Nanoservices are similar to small microservices. Their API consists of just one message. They are bound to a namespace and also perform other functions (observer pattern, forwarding of messages, notifications).
Namespaces: There are any number of namespaces in a node, which include one or more threads, a target registry and a nanoservice registry. This allows you to host instances of applications. The most important namespace is the SYSTEM namespace.
Target Registry: Each namespace has its own target registry. Targets are Java classes that can receive messages. When they are registered, they receive a unique network-wide address.
Target Address: The target address consists of 4 components: The target ID, the namespace ID, the node ID and the segment ID. It is unique across the network and is used for addressing messages. The resolution is performed automatically by the system. The simplest way to send a message is to enter a recipient target address in the envelope of a message.
Targets: Targets are registered message recipients. They are always assigned to a thread in a namespace. They therefore always receive the messages addressed to them in the same thread. This is very helpful in a highly asynchronous system.
Messages: Messages consist of an envelope and a record. The envelope contains all the technical data that is important for the delivery and processing of the message. In simple terms, the record is a map with the components of the payload.
Message flow: Messages are delivered asynchronously. If a message is intended for another node, it is forwarded from node to node via a routing mechanism through the TCP channels to which the nodes are connected, from node to node. Messages are streamed and not parsed. This means that no JSON or XML is used. This gives you an advantage in terms of speed and resource consumption.
Routing: The TCP channels are constantly monitored and measured. This ensures that messages are always routed to their destination via the shortest route. A side effect is the rapid detection of connection failures, about which every node is informed immediately. Nodes therefore always know the entire network - a prerequisite for efficient routing.
Compression: Setting a simple flag in the message envelope causes messages to be compressed automatically.
Encryption: Setting a simple flag in the message envelope causes messages to be AES-encrypted. This is not to be confused with the basic TLS encryption of TCP channels. Before the message can be encrypted, the node must exchange an RSA key with the target node.
Prioritization: Messages can receive a manual priority via the envelope. The priority is taken into account for each hop between two nodes. Replies automatically receive a higher priority.
Answers: Messages are automatically sent back to the sender after receipt. They receive an error code and an error text. This behavior can be prevented for pure notifications by a flag. Messages that could not be delivered are sent back to the sender with the corresponding code. The error code also indicates whether the message has been processed.
Postponement: Messages that cannot be processed immediately can be put on hold. Once the message has been processed, it can be sent back manually.
Forwarding: Messages can be forwarded to other recipients. The recipient address is simply exchanged. The sender can also schedule forwarding by specifying several recipient addresses.
Messages to Nanoservices: Messages can be sent to nanoservices by using recipient addresses where the target address is missing. The nanoservice is then identified via the message ID in the specified namespace. Observers can be registered at nanoservices, each of which receives a copy of the message. As target addresses are usually unknown, a service can be reached easily in this way.
Messages to Microservices: The sender simply enters the microservice ID in the message envelope. The system then sends the message to the nearest microservice registry. The registry then dissolves the service. If several services are registered with the same ID, the registry selects a candidate (load balancing). The target address is entered and the message is forwarded. When the message returns to the sender, the sender can use the sender address to communicate directly with the microservice.
Applications: Applications are microservices that register with a special application registry with an ID and metadata. They are factories that only start their instances with a message from the registry. Application factories can also be installed redundantly on different nodes.
Sessions: Before a user can start an application, they need a session token. This is usually obtained by signing in to the session manager. The token can then be forwarded to other services via messages. These can check the token for validity and thus obtain the user ID and the list of user rights. Many services only become active when the corresponding rights are available.
Session verification: There are two different types of session tokens. The large token contains all data and is signed by the session manager using RSA. Nodes can verify the token. They receive the corresponding public key via configuration or as an early message after starting the node. There is also a short token for each long token. This requires a message to the session manager for verification. If successful, the response contains the corresponding data.
Users, roles, rights: The Session Manager has a database with users, their roles and the rights assigned to the roles. There are two applications for managing this data. One is web-based (“RemoteSkin for Web”), the other is based on Swing (“RemoteSkin for Swing”).
RemoteSkin for Web: This technology enables the design of web applications based on node systems. An overview of the technology can be found here.
RemoteSkin for Swing: This technology enables the design of server based Swing applications.