Asynchrones Message Passing

Program Your Peer-to-Peer Network!

devel.one is the peer-to-peer network for your next generation project:

  • Install devel.one NODES on all project computers at all locations.
  • Install devel.one NODES on virtual cloud machines between locations.
  • Let the NODES connect to a Mesh Network.
  • Create plug-ins with user interfaces for the employees.
  • Create plug-ins with microservices for controlling databases, machines, sensors.
  • Distribute the plug-ins to the NODES.
  • Use the real-time message passing protocol to let everyone communicate with each other. Each NODE can communicate with any other NODE via the links, bidirectional, encrypted, and in real time.
  • Use redundant NODES, links and microservices for a fail-safe network.
  • Scale the functions in your network without restriction.

No server, no message broker, no middleware. Leave everything behind your firewalls.

No star-shaped cabling, but an organic, redundant mesh network.

Distributed systems can be so simple.

devel.one is a peer-to-peer network for the development of distributed applications in JAVA™. The communication options can be easily integrated into existing JAVA™ applications.

Take a look around. And try something really new.


Non-optimized network

Peer-to-peer for non-optimized networks:

P2P's strengths are particularly evident in real life networks. These can be customer networks, machine maintenance networks or spontaneous networks. Such networks are difficult to map even with middleware.

For devel.one, the structure of the network and the distribution of services in the network are irrelevant. Services can be accommodated in the cloud as well as in branches behind firewalls. Clients can network with each other. Workgroups can be connected spontaneously. Everything is accessible as long as there is a way from NODE to NODE.

The Idea:

What if every object in a network could be addressed directly with messages?

  • It should have an address to address it unambiguously in a large network.
  • The message should reach the object in no time. And only this object.
  • And always come back with an answer so that a real handshake takes place.
  • And all this in real time. Thousands of messages per second. There and back.
  • And if the object is moved to another computer in the network?
  • It has to be found. I don't want to worry about that.
  • But if I don't know the object at all, but only its purpose?
  • Network services are available for this purpose. I'm not interested in who does the work where in the network.
  • The network should organize itself.
  • The messages should go the shortest way, or the one with the lowest cost.
  • We have to go through firewalls.
  • Traffic must be encrypted without me having to set up a VPN.
  • Compression would be good. And point-to-point encryption when there is a black sheep under the computers.
  • But the net has to organize itself. I take care of the services and the UI.
  • Hm, then I could outsource some stuff to the cloud. No servers, no middleware, endless space and power.
  • Here we go....
Asynchrones Message Passing
There and Back

Everything is a message, isn't it?

devel.one is a library for asynchronous software development in which the programmer does not have to deal with threads or TCP/IP.

It uses a HighSpeed RealTime messaging between objects - not queues. Objects can be located in other threads, in other programs, or on other hosts.

Objects are addressed directly via their devel.one address. And the message comes back with an answer - automatically. With error code. No flooding with messages sent to subscriber lists, but lightning-fast 1:1 requests.

Full-Featured. Of course, the old patterns are supported. Services, Observer, Listener, Notification... no one remains uninformed. Everything is trackable.

Easy-Peasy

Working with devel.one is child's play. Simply derive a class from CTarget, add one or more message handlers, and then register the target in the system. The target is assigned an address. That's all.

Messages have a sender and a recipient address, like a letter. So: write a message, add an address to the envelope and send it. The sender is entered automatically. The system ensures delivery, even if the recipient is on another NODE. And if you set the check mark that you want to have an answer, then you get it automatically. In case of an error even without explicit request. So you don't get caught in the dark.

Easy-Peasy
Scaling

Scaling?

Consistent messaging leads to extremely scalable systems. Message receivers can be distributed to any number of NODES across the mesh network, and within the NODES to namespaces (threads) and cores. The distribution can also be changed at any time without reprogramming. Since the runtime of the messages is very short, even across continents (binary messages, no XML parsing, open TCP connections), there is no delay in the applications.

devel.one is optimally prepared for use on cloud computers. NODES works just as well on Linux computers as it does on Windows™ computers. Of course, the memory and CPU requirements of a NODE depend on the workload. For the NODE itself, for example, the smallest virtual machine that Google offers on the cloud platform is enough, for a few cents a day. Cloud computers are also ideal for integrating clients and branch networks into the peer-to-peer network.

Mesh Networking

devel.one NODES on different computers connect automatically when you tell them via the configuration which NODES to connect to (IP + port).

This results in a fine-meshed network of redundant interconnected NODES: a mesh network with open TCP connections. NODES automatically exchange information about their properties and connections. To do this, they use their peer-to-peer protocols.

Messages travel along the links between the NODES (no new connections are opened.) The individual NODES can determine the fastest route for each message. For this purpose, the individual connections between the NODES are monitored. If a link breaks down, the NODES re-route the message to the fastest remaining connection (Djikstra & Co.).

The NODES automatically attempt to reconnect disconnected links. The network thus repairs itself - as far as it can ;-)

Mesh Network
Control and Safety

Control and Safety

Each message can be acknowledged with an answer if desired. This is done automatically. In the event of an error (e. g. recipient not found, exception during processing by the recipient, etc.), the response is returned without request.

The answers contain error codes and texts. Even if a reply has not been processed, the sender can see it by the error code in the reply.

Between sender and receiver NODES the messages are optionally compressed and encrypted. For this purpose, an RSA procedure with key exchange and subsequent symmetric encryption is used. Encryption takes place from point to point, i. e. between transmitter and receiver, so that other computers in the mesh network cannot read along.

The individual NODES can be secured by configuration with RSA keys, so that only allowed NODES can establish a connection.

The rights are assigned by TCP port. A gate service monitors the message inbox. Only messages that are explicitly allowed can pass the gate. In combination with the RSA key assigned to the port, this enables finely graduated rights management.

Messages that are not allowed are rejected and logged with error code.

Services

So that not all messages need to be hardwired 1:1, there is the use of services. Targets publish services under a unique ID. User targets that want to use the service simply address the message to this service ID. Who is actually addressed for the completion of the service is then irrelevant.

devel.one Service descriptions in XML also serve as APIs for customers or suppliers. All message classes belonging to the API can then be automatically generated as code with a tool (RecordGenerator) in the language programmed by the customer (currently available only for JAVA™...). This is only a relief, because API messages can also be programmed manually.

Services can be monitored (registration, deregistration and use). They also serve to spread notifications. Example: Stick Observer to service "Sunrise" and wait until the service is triggered....

NetzwerkServices are used to find services in the network. Since there are no servers in a peer-to-peer network, they use

P2P protocols for advertising. Servers may fail. Redundant P2P registries tend not to fail.

Services
Performance

Performance

In this case, real time means: Back and forth as fast as possible. That means in the same thread 2 million messages back and forth. In just a second. Without user data even 10 million. Between the threads there are still 100,000 messages per second. And between different NODES even less, depending on latency.

The numbers cannot be compared with numbers from other systems (e. g. message brokers). Because there, messages are only pumped in one direction. We also measure the time until the message has come back, and then we send the next message.

We don't waste bandwidth. The messages are binary, i. e. no serialized objects, and no XML. In addition, messages can be compressed on slow connections if the resulting savings are greater than the time required for packing and unpacking. And since established TCP connections are used, there is no longer any need to set up a connection.

Between the devel.one NODES messages are prioritized. An important message (e. g. an answer) will be sent faster than a not so important one (e. g. a LOG message, a download).

The result is a delay-free execution of the programs, even across continents. No comparison with the web.