Messages

Messages in nyssr.net are asynchronous and object-to-object. A target waits for incoming messages, processes them, and can send further messages without blocking the rest of the network.

This simple mechanism supports observers, notifications, services, broadcasts, requests, and responses.

Request and response

A message travels from a sender to a receiver. Both addresses are carried in the envelope. When the sender wants an answer, it sets the wantAnswer flag. The receiver can then return a response after processing the request.

Delivery errors are returned even when no response was requested. This explicit handshake is a central difference from queue-oriented techniques such as JMS.

Across the node network

Messages can travel across the complete nyssr.net, regardless of how many nodes are between sender and receiver. The addresses must be valid; routing is handled by the network.

A mesh can offer several paths to the destination. nyssr.net continuously measures the connections and selects a suitable route:

• Open channels remain available after startup
• The route can use multiple nodes
• Link interruptions are detected quickly
• Messages can be rerouted when the network changes

Key idea: Applications communicate with targets, not with network locations. Routing and connection management remain part of the node network.

Why asynchronous messages matter

The sender does not need to wait while another service performs work. The receiver can answer later, notify other targets, or start a separate workflow. This allows many small services to cooperate without a central coordinator.

The same message model is used locally within a node and remotely across the network. That keeps application code consistent as a system grows.

Next steps

Read about Targets to understand message recipients, then continue with CEnvelope for the structure that carries a message.