一般に、プロトコルの考え方はこれです。これにより、さまざまなサービスを提供する分散型の分散メッセージングネットワークを構築できます。 ユーザーの介入を最小限に抑えて、ネットワークを自動的に構築および構成する必要があります。 技術的な理由から、自動チューニングは1つのセグメント（256ノード）でのみ有効ですが、各ノードが最大2 ^ 32クライアントを処理できるという事実を考慮すると、これで十分です。
いくつかの原則とアイデアはFTN（fidonet）から借用しています。 ゼロから、または既存のシステムのイメージと類似性から、何かが発明されました。 思いついて実装するものがたくさんあり、それから何度もやり直して補足することがあります。 どれくらいかかるかわかりませんが…試してみる価値はあります。
これは、1年前にサイトに投稿したテキストです。 そして、それが何から来たのか...
説明：
分散メッセージングネットワークプロトコル（DNMP）を使用すると、次の機能を備えた分散情報交換ネットワークを構築できます。
-ネットワークには、クライアントとノードの2種類の参加者がいます。 自身の間でノードが形成
ネットワークとさまざまなサービスを提供します。 クライアントはノードに接続します。
-ネットワークは分散化されており、単一の中央ノードはありません。 各ホストは完全に独立しており、独立しています。
-他のノードの可用性に関するデータに基づいた、1つのセグメントのノード間のメッセージの自動ルーティング。
-メッセージには、通過したノードのリストが含まれます。
-一部のタイプのメッセージは最終ノードに保存する必要があり、このノードのクライアントによって要求される場合があります。
-プロトコルは、通信チャネルのハードウェアまたはソフトウェアの実装に関連付けられていません。 80バイトから4 GBのパケットでデータを転送する任意の方法を使用できます。
仕事のスキーム：
ネットワークは、ノードとクライアントで構成されます。 ノードは着信接続を受け入れることができますが、クライアントは受け入れることができません。 各ノードには、他のノードの中で一意のIDがあります。 各クライアントには、アップリンクの他のクライアントの中で一意のIDがあります。
ポイントがアップリンクに接続されると、アップリンクでポイントが認識されます。
未確認のポイントが登録され、IDが割り当てられます。 識別後、既知のノードの交換が行われ、ルートテーブルが更新されます。
メッセージを送信する場合、ドットはメッセージのアドレスと受信者のアドレスを示します。 これがグループメッセージである場合、受信者アドレスは空である可能性があります。 メッセージを受信するホストは、受信者のアドレスを確認します。 受信者が彼に知られているポイントにいる場合、メッセージはこのポイントに送信されます。 そうでない場合、メッセージはアップリンクされます。 アップリンクがない場合は、「受信者が利用できません」というメモとともにメッセージが返されます。 受信クライアントが利用できない場合、受信ノードはメッセージをしばらく保存し、利用可能になったときにクライアントに送信できます。
各ノードのルーティングテーブルには、セグメント内のすべてのノードとリンクへの対応のリストが含まれています。 さらに、セグメント外の受信者にメッセージが送信される境界ノードのリストがあります。
メッセージの種類：
プライベート：
プライベート（プライベート）-指定されたアドレスに送信されるメッセージ。 サイズが大きく、添付ファイルを含めることができます。 受信者が接続されていない場合、メッセージは宛先ノードにしばらく保存されます。
プライベートチャット（プライベートチャット）-指定されたアドレスに送信されるメッセージ。 リアルタイムで配信される単一メッセージのサイズは1 KBに制限されています。 メッセージが宛先に配信された後、エンドノードは配信結果に関するサービスメッセージを返します。
グループ：
チャンネル-チャンネルの名前は＃（ポンド記号）で始まり、スペースは含まれません。 チャネル上のメッセージは、アクティブなチャネルのリストにこのチャネルがあるすべてのポイントによって受信されます。 チャネルごとのメッセージはリアルタイムで送信され、1つのメッセージのサイズは1 KBに制限されます。
フォーラム-フォーラムの名前にはスペースが含まれていません。 フォーラムのメッセージは、それを購読しているすべてのポイントによって受信されます。 ノードには多くのフォーラム投稿が保存されます。 クライアントは、選択した期間、アップリンクメッセージを要求できます。
ブログ-フォーラムと同じですが、ブログの作成者のみが新しいトピックを作成および編集できます。
制限事項：
雪崩のトラフィックを減らすために、グループメッセージとpingは1つのセグメント内でのみ自動的に送信されます。 セグメントを接続するとき、メッセージルーティングは手動でまたは半自動で（サイト管理者の制御下で）設定されます。
トポロジを簡素化するには、1つのアップリンクを同時にノードに接続する必要があります。 場合によっては、手動または半自動のルーティング設定で複数のアップリンクへの接続を使用することが許可されます。 同じセグメント内で複数のアップリンクを使用することは非常に望ましくありません。
ノードは、1秒あたりのエコー要求の数の制限に従う必要があります。 侵入者は隣接ノードによってブロックされる必要があります。
アクセスできないノードは、既知のノードのリストに限られた時間だけ保存できます。その後、ノードに関する情報が削除され、そのIDが解放されます。
機能：
パスワードは使用されません。 最初の接続で、キーが生成され、承認要求と応答がハッシュされます。 キーはユーザーのパスポート（プロファイル）に保存されます。
ネットワークアドレスに加えて、グローバルGUIDと名前が使用されます。 名前またはGUIDにより、クライアントのネットワークアドレスを取得できます。 メッセージの解析および送信時には、ネットワークアドレスのみが使用されます。 GUID、名前、およびその他のクライアント情報は、ネットワークアドレスの同義語としてのみ使用されます。
ネットワークへのクライアントまたはノードの受け入れは、手動で行われます。 同時に、それを受け取ったノードの識別子は、受け入れられた人のパスポートに入れられます。 ネットワーク内では、参加者は手動の許可なしに再接続できます。 再接続するとき、新しいノードは古いノードからクライアントのパスポートを要求します。 クライアントのネットワークアドレスは変更されており、他のすべての情報は変更されていません。
================================================== ======
詳細については、irchat.ruの記事のメッセージ形式とパスポートの説明を参照してください。
Delphiにはプログラムの形式でプロトコルの現在の実装がありますが、それはまだ生です。 私はそれをあらゆるプログラムに接続するためのDLLにしようと考えており、まずは成熟したプロジェクトRealChatに接続します。 開発は、時間と欲望として非常にゆっくりと、ぎくしゃくして動きます。 あなたの意見、批判、提案、希望に非常に興味があります。
誰かが一緒に仕事をすることに興味があるなら-ようこそ。 Javaでクロスプラットフォームバージョンを作成したいのですが、私自身はヒキガエルについてあまり知りません。DelphiIMHOは複雑なプロジェクトを単独で開発するのに適しています。