The role of a node's location

A nyssr.net can be quite geographically extensive. Thus, operating units of a large company can exist in different countries and continents. A feature of nyssr.net is the connection of data sources that are only locally located, that is outside the cloud. Data sources can be databases, but also e.g. local services, warehouse systems and machines. nyssr.net nodes can be physically located on or next to systems - often behind firewalls.

Why do we use a mesh network?

Messages move exclusively over the open channels between nodes. Therefore, no new connections are usually opened after the startup. Messages are passed from node to node until they reach their destination. In doing so, they take the cheapest route across the network, because each path between two nodes (link) has a cost in terms of the time it takes to pass the message on. The network is constantly surveyed to respond appropriately to the state of the connections.

A typical large nyssr.net often takes the form of a mesh network, where each node is connected to several other nodes. Meshing ensures that if connections fail, other connections can be used to transport messages. Likewise, the performance can be greatly influenced by the clever distribution of the connections. Additional connections can be created on individual sections when the load is high. Shortcuts or direct connections can be created to increase performance by using as few hops as possible. Bottlenecks can be cleverly avoided.

What belongs together

Services that always work together can be kept in close proximity by smart selection of nodes. The goal is to locate services that need each other on the same node or in closer proximity. It makes sense to install applications that are needed on several continents, including services, on nodes in these continents. Central services are favorably to be kept in the cloud. More remote services, which are actually intended for more remote users, conveniently still provide a backup in case local services ever fail.

Nevertheless, there will be services that are only available in one place on the network. Databases are to be mentioned here in the first place, but also often existing local services, such as interfaces to external systems, warehouses, machines. Here it is often convenient to set up local proxy services. For example, no user interface requires complete database entities. Usually only strings are displayed, no matter whether a numeric value or a date is displayed behind it. Services located in the immediate proximity of databases can extract and prepare data from database queries. Only the data that is needed should be shared with other services. Under no circumstances should SQL queries be formulated in applications or user interfaces and the results transported directly over the network.

RemoteSkin should be mentioned here as an example. Approximately 44 KBytes are transported for the complete display of the user interface including the first database queries. An intelligent selection of the data to be transported and the time of transport are responsible for this. The small amount of data, open channels, and compression can easily make up for disadvantages by locating the nodes.

Caches

Caches are another way to decentralize local singletons. Due to the modularization of nyssr.net services, it is easy and fast to design services that deliver data from local caches and only forward the request to the central service in case of a fail.