devel.one is the peer-to-peer network for your next generation project:
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.
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.
What if every object in a network could be addressed directly with messages?
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.
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.
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.
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 ;-)
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.
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.
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.