Hypertext Vector Fidonet
I have long wanted to create my own protocol for exchanging messages inside the locales so that a dedicated server is not required or at least a long and careful server setup is not required. I did not find anything sensible in the internet, there are a couple of interesting projects, but they are paid and closed.
In general, the idea of ​​the protocol is this - it allows you to build a distributed decentralized messaging network that provides various services. The network should be built and configured automatically, with minimal user intervention. For technical reasons, autotune is only allowed in one segment (256 nodes), but given the fact that each node can serve up to 2 ^ 32 clients, this is more than enough.
')
Some principles and ideas are borrowed from FTN (Fidonet). Something is invented from scratch or in the image of already existing systems. Much remains to be thought out and implemented, and then reworked and supplemented many times. I do not know how long it will take ... But try it.
Here is the text I posted on my site a year ago. And that's what came out of it ...
Description:
The Distributed Messaging Network Protocol (DNMP) allows you to build distributed information exchange networks with the following features:
- There are two types of participants in the network: clients and nodes. Nodes form between themselves
network and provide various services. Clients connect to nodes.
- The network is decentralized, there is no single central node. Each node is fully autonomous and independent.
- Automatic routing of messages between nodes of one segment based on data on the availability of other nodes.
- Messages contain a list of nodes through which they passed.
- Some types of messages should be stored on the end node and can be requested by the client of this node.
- The protocol is not tied to any hardware or software implementation of the communication channel. Any method of data transmission in packets from 80 bytes to 4 GB can be used.
Scheme of work:
The network consists of nodes and clients. Nodes can accept incoming connections, clients can not. Each node has a unique ID among other nodes. Each client has an ID, unique among other clients of his uplink.
When a point is connected to an uplink, the point on the uplink is recognized.
The unidentified point is registered and assigned an ID. After identification, the exchange of known nodes takes place, and the route tables are updated.
When sending a message, a dot indicates its address and the recipient address in the message. If this is a group message, then the recipient address may be blank. The receiving node checks the recipient's address. If the recipient is among the points known to him, then the message is transmitted to this point. If not, the message is transmitted uplink. If there is no uplink, the message is returned with the note “recipient is unavailable”. If the receiving client is unavailable, the receiving node can store the message for a while and transfer it to the client when it becomes available.
The routing table of each node contains a list of all nodes of the segment and their correspondence to links. In addition, there is a list of border nodes to which messages are sent to recipients outside the segment.
Types of messages:
Private:
Privat (Private) - message sent to the specified address. May be large and contain attached files. If the recipient is not connected, the message is stored for some time on the end node.
Private chat is a message sent to the specified address. Delivered in real time, the size of a single message is limited to 1 KB. After the message is delivered to the addressee, the end node returns a service message about the delivery result.
Group:
Channel (Channel) - The channel has a name starting with a # (grid) and not containing any spaces. All points that have this channel in the list of active channels receive a message to a channel. Messages to the channel are transmitted in real time, the size of a single message is limited to 1 KB.
Forum (Forum) - Forum has a name that does not contain spaces. Message to the forum receive all the points subscribed to it. Nodes store a number of forum posts. Customers may request uplink messages for a selected period of time.
Blog (Blog) - Same as the forum, but only the creator of the blog can create and edit new topics.
Limitations:
To reduce avalanche-like traffic, group messages and echo requests are automatically transmitted only within one segment. When connecting segments, message routing is configured manually or semi-automatically (under the control of the site administrator).
To simplify the topology, the node must have one uplink connected at the same time. In some cases it is acceptable to use a connection to several uplinks with manual or semi-automatic routing configuration. Using multiple uplinks within the same segment is very undesirable.
Nodes must comply with the limit on the number of echo requests per second. Violators must be blocked by neighboring nodes.
An unavailable node can be stored in the list of known nodes for a limited time, after which the information about the node is deleted and its ID becomes free.
Relevance:
Passwords are not used. At the first connection, a key is generated, and the authorization requests-responses are hashed. The key is stored in the passport (profile) of the user.
In addition to the network address, global GUIDs and names are used. You can get the client’s network address by name or GUID, and vice versa. When parsing and sending messages, only network addresses are used. GUID, name, and other customer information are used only as a synonym for the network address.
Accepting a client or node to the network is done manually. In this case, the identifier of the node that received it is put in the passport of the received one. Within the network, participants can reconnect without manual authorization. When reconnecting, a new node requests a client passport from its old node. The client’s network address changes while all other information remains unchanged.
================================================= ======
In more detail, with a description of the format of messages and passports in articles on the website irchat.ru
There is an actual implementation of the protocol in the form of a program in Delphi, but it is still damp. I plan to make it a DLL to connect to any program, and first of all to my mature project RealChat. Development is moving rather slowly, jerky, as time and desire. I am very interested in your opinion, criticism, suggestions and suggestions.
If anyone is interested in working together - welcome. I would like to make a cross-platform version of Java, but I myself do not know the toad, and Delphia IMHO is better suited to develop complex projects alone.
In general, the idea of ​​the protocol is this - it allows you to build a distributed decentralized messaging network that provides various services. The network should be built and configured automatically, with minimal user intervention. For technical reasons, autotune is only allowed in one segment (256 nodes), but given the fact that each node can serve up to 2 ^ 32 clients, this is more than enough.
')
Some principles and ideas are borrowed from FTN (Fidonet). Something is invented from scratch or in the image of already existing systems. Much remains to be thought out and implemented, and then reworked and supplemented many times. I do not know how long it will take ... But try it.
Here is the text I posted on my site a year ago. And that's what came out of it ...
Description:
The Distributed Messaging Network Protocol (DNMP) allows you to build distributed information exchange networks with the following features:
- There are two types of participants in the network: clients and nodes. Nodes form between themselves
network and provide various services. Clients connect to nodes.
- The network is decentralized, there is no single central node. Each node is fully autonomous and independent.
- Automatic routing of messages between nodes of one segment based on data on the availability of other nodes.
- Messages contain a list of nodes through which they passed.
- Some types of messages should be stored on the end node and can be requested by the client of this node.
- The protocol is not tied to any hardware or software implementation of the communication channel. Any method of data transmission in packets from 80 bytes to 4 GB can be used.
Scheme of work:
The network consists of nodes and clients. Nodes can accept incoming connections, clients can not. Each node has a unique ID among other nodes. Each client has an ID, unique among other clients of his uplink.
When a point is connected to an uplink, the point on the uplink is recognized.
The unidentified point is registered and assigned an ID. After identification, the exchange of known nodes takes place, and the route tables are updated.
When sending a message, a dot indicates its address and the recipient address in the message. If this is a group message, then the recipient address may be blank. The receiving node checks the recipient's address. If the recipient is among the points known to him, then the message is transmitted to this point. If not, the message is transmitted uplink. If there is no uplink, the message is returned with the note “recipient is unavailable”. If the receiving client is unavailable, the receiving node can store the message for a while and transfer it to the client when it becomes available.
The routing table of each node contains a list of all nodes of the segment and their correspondence to links. In addition, there is a list of border nodes to which messages are sent to recipients outside the segment.
Types of messages:
Private:
Privat (Private) - message sent to the specified address. May be large and contain attached files. If the recipient is not connected, the message is stored for some time on the end node.
Private chat is a message sent to the specified address. Delivered in real time, the size of a single message is limited to 1 KB. After the message is delivered to the addressee, the end node returns a service message about the delivery result.
Group:
Channel (Channel) - The channel has a name starting with a # (grid) and not containing any spaces. All points that have this channel in the list of active channels receive a message to a channel. Messages to the channel are transmitted in real time, the size of a single message is limited to 1 KB.
Forum (Forum) - Forum has a name that does not contain spaces. Message to the forum receive all the points subscribed to it. Nodes store a number of forum posts. Customers may request uplink messages for a selected period of time.
Blog (Blog) - Same as the forum, but only the creator of the blog can create and edit new topics.
Limitations:
To reduce avalanche-like traffic, group messages and echo requests are automatically transmitted only within one segment. When connecting segments, message routing is configured manually or semi-automatically (under the control of the site administrator).
To simplify the topology, the node must have one uplink connected at the same time. In some cases it is acceptable to use a connection to several uplinks with manual or semi-automatic routing configuration. Using multiple uplinks within the same segment is very undesirable.
Nodes must comply with the limit on the number of echo requests per second. Violators must be blocked by neighboring nodes.
An unavailable node can be stored in the list of known nodes for a limited time, after which the information about the node is deleted and its ID becomes free.
Relevance:
Passwords are not used. At the first connection, a key is generated, and the authorization requests-responses are hashed. The key is stored in the passport (profile) of the user.
In addition to the network address, global GUIDs and names are used. You can get the client’s network address by name or GUID, and vice versa. When parsing and sending messages, only network addresses are used. GUID, name, and other customer information are used only as a synonym for the network address.
Accepting a client or node to the network is done manually. In this case, the identifier of the node that received it is put in the passport of the received one. Within the network, participants can reconnect without manual authorization. When reconnecting, a new node requests a client passport from its old node. The client’s network address changes while all other information remains unchanged.
================================================= ======
In more detail, with a description of the format of messages and passports in articles on the website irchat.ru
There is an actual implementation of the protocol in the form of a program in Delphi, but it is still damp. I plan to make it a DLL to connect to any program, and first of all to my mature project RealChat. Development is moving rather slowly, jerky, as time and desire. I am very interested in your opinion, criticism, suggestions and suggestions.
If anyone is interested in working together - welcome. I would like to make a cross-platform version of Java, but I myself do not know the toad, and Delphia IMHO is better suited to develop complex projects alone.
Source: https://habr.com/ru/post/79455/
All Articles