3

最近、IRC プロトコル (RFC 1459、2810-2813) について調べていて、独自のサーバーを実装することを考えていました。

私は必ずしも IRC プロトコルに忠実に従うことを検討しているわけではありません (結局のところ、これは楽しみのために行っているのです)。

プロトコルや IRC 仕様について、気に入らない点がいくつかあります。1 つ目は、ニックネームが所有されていないことです。NickServ のようなサービスは存在しますが、公式のプロトコルには含まれていません。一方、 NickServのようなものを適切に実装すると、配布の目的が損なわれます (つまり、NickServ が実行されている場所が 1 つと、そのためのデータ ストアが 1 つあります)。

サーバーごとにニックネームを管理する方法があることを期待していました。これに関する問題は、登録されたニックネームを持つ 2 つのサーバーがあり、それらがリンクする場合、衝突が発生する可能性があることです。

1 つの中央データ ストアを使用せずに、これを回避する方法はありますか? つまり、サーバーを疎に接続したままにし (それぞれが独立したエンティティとして存在するが、相互に接続することもできる)、ニックネーム間の一意性を維持することは可能ですか?

この質問が漠然としていることは承知していますが、これ以上の言い方は思いつきません。私は実際のはい/いいえの答えよりも提案を探しています。したがって、サーバーの独立性を維持しながら、ネットワーク内でニックネームの一意性を実現する方法について何かアイデアがある場合は、ぜひ聞いてみたいと思います。IRC プロトコルに厳密に従う必要はないことに注意してください。目的に合わせて変更しても問題ありません。:)

4

5 に答える 5

3

IRC サーバーを厳密に実装することを気にせず、IRC に似ているが正確にはIRCではない分散メッセージ システムを実装する場合は、簡単な解決策があります。

簡単な解決策は、電子メールのように「nick@host」の形式でニックネームを使用することです。したがって、単に「mipadi」である代わりに、私のニックネームは「mipadi@free-memorys-server.net」にすることができます。したがって、私はあなたのサーバーだけに登録しますが、あなたのサーバーが他のサーバーとリンクして別の大きな古いチャットネットワークを形成すると、すべてのユーザー名を簡単に結合できます. otherserver.net に "mipadi" があるかもしれませんが、ニックネームは "mipadi@free-memorys-server.net" と "mipadi@otherserver.net" になり、すべてがクールです。

もちろん、これは IRC から大きく逸脱しています。:)

于 2009-01-13T17:47:41.710 に答える
0

サーバー インスタンスが相互に信頼している場合は、中央インスタンスがなくてもニック所有権を実装できます。

  • ユーザーがニックネームを登録すると、現在接続しているサーバーに登録されます
  • サーバーが認識していない登録を受信すると、その情報をまだ認識していない他のすべてのサーバーに転送します (ネットワークへのスパムを回避するためにスマートなアルゴリズムが必要になる場合があります)。
  • サーバーが別のサーバーに再接続すると、登録されたニックネームのリストと、どのサーバーがどのニックネームを処理するかを同期しようとします。
  • その同期中に競合が発生した場合は、古い登録が使用され、新しい登録が無効としてマークされます

サーバーを信頼できない場合、サーバーはすべてのユーザー名を簡単に要求し、それぞれの最も古い登録を要求することさえできるため、より困難になります。

于 2009-01-13T17:51:21.123 に答える
0

何か新しいことを考え出そうとしているので、思い浮かぶアイデアは、サーバーの外部と通信するときにニックネームの一部としてサーバー固有のものを単純に含めることです。したがって、別のサーバー上のユーザーにメッセージを送信したい場合は、user@server のようなものを使用できます。

それらを完全に分離する必要がない場合は、何らかの種類の複数マスターの複製されたアカウントのデータベースを作成することを検討することをお勧めします。各サーバーがアカウント データベースの完全なコピーを保存し、各サーバーが可能な限り他のサーバーに複製される新しいアカウントを作成できます。ただし、場合によっては衝突に対処する必要があります。

于 2009-01-13T17:51:47.817 に答える
0

彼らはお互いを認識している必要があります。そうでない場合、ニックネームの共有を防ぐことはできません。そうである場合は、バックエンドで更新を転送するだけです。同時登録を防ぐには、ブロックし、他のすべてのサーバーから許可を要求し、応答するトランザクション システムが必要です。

停止中の同時登録を防ぐには、登録にタイムスタンプを付け、最後の (または真に同時の場合はランダムに) 登録されたニックネームのコピーを除くすべてを削除するしかありません。

これらのサーバーが最初からマージされていないことを考えると、あまりきれいではありません。

于 2009-01-13T17:47:05.737 に答える
0

NickServ のようなサービスは存在しますが、公式のプロトコルには含まれていません。

サービスはプロトコルとは関係がないため、公式プロトコルの一部ではありません。権限を持つボットです。各サーバーで実行できない理由はありませんが、保守が難しくなります。

その道をたどるなら、私はおそらく、一般的に使用されている「マルチマスター」データベース複製技術を提案するでしょう。書き込みを受信すると（あなたの場合、新しいユーザーが作成または更新されるなど）、他のすべてのノードにデータが送信されます。ただし、注意が必要です。他のノードが更新を取得するときに 1 つのノードがオフラインの場合、再接続時に再同期する必要があります。

別のテクニックは、上記と逆になります。データは、必要な場合にのみノード間で交換されます。たとえば、ユーザーがデータのないノードにログインしようとすると、他のノードにクエリを実行し、移動命令を発行してすべてのデータをその 1 つのノードに取得します。これは、複製バージョンよりも問題が少ない可能性がありますが、誰かがパックから切断されたノードにサインアップして重複したニックネームを取得すると、ネットスプリットで深刻な問題が発生する可能性があります。

ネットスプリットの問題を無効にする 1 つの手法は、チャット ノードとそのボットをネットスプリット対応にすることです。それらが分割されている場合、おそらく書き込みアクションは許可されるべきではありません...しかし、ロットを分割している場合、これはネットワークに影響を与える可能性があります.

また、これがどれほど安全かどうかも尋ねなければなりません。IRC ネットワーク ノードはパフォーマンスのために分散されていますが、「安全」ではありません。このため、サービス ボットは通常、中央で実行され、実行を完全に制御できます。ボットを配布し、リモート ノードがハッキングされた場合、ユーザー データベース全体にアクセスできる可能性があります (モデルによって異なります)。

于 2009-01-13T18:00:43.103 に答える