NYSSR.NET / RESOURCES

Connect locations without centralizing everything

See how a self-hosted nyssr.net node network connects services across offices, private networks, and cloud locations while keeping work close to local data.

When applications have to work across offices, private networks, or cloud locations, centralizing every service can create unnecessary dependencies. nyssr.net lets you keep services close to the systems and data they support.

A nyssr.net can span offices, countries, and continents. Nodes can run next to local databases, warehouse systems, machines, and other services — including systems behind firewalls.

This makes it possible to connect local data sources without moving everything into the cloud.

A mesh that adapts to its routes

Messages travel over open TCP channels between nodes. After startup, the network normally does not open a new connection for every message. Messages move from node to node along a suitable route.

Each link has a cost based on forwarding time. The network observes connection state and adapts when routes change.

A mesh provides several advantages:

  • Alternative routes remain available when a connection fails
  • Direct links can reduce the number of hops
  • Additional links can handle local traffic peaks
  • Bottlenecks can be avoided by changing the topology

Key idea: Location is part of the architecture: place services and routes where they make the system faster and more resilient.

Services that work together frequently can be installed on the same node or nearby nodes. Services needed in several regions can be distributed to those regions, while central services can remain in the cloud.

Local proxy services are useful for data sources that exist in only one location. A database-near service can prepare exactly the data another service needs instead of exposing database entities or SQL queries across the network.

RemoteSkin is one example. A complete UI display, including its first database queries, can be transported with roughly 44 KBytes. Selective data preparation, open channels, and compression reduce the impact of geographic distance.

Caches reduce central dependencies

A local cache can decentralize a singleton service. It answers locally and contacts the central service only when its data is missing or invalid.

Because nyssr.net services are modular, these cache services can be added, replaced, or distributed without changing the clients that use them.

Operational choices

  • Cloud: central services and shared coordination
  • Branches: local systems behind firewalls
  • Near the data: preparation and proxy services
  • Near the users: frequently used services
  • Across the mesh: redundancy and alternate routes

Placement: Put computation close to the data and distribute only the result other services need.

Routing: Keep frequently used paths short while retaining alternate routes.