単一のサーバーと複数のクライアントを持つネットワーク アーキテクチャを作成しようとしています。クライアントはいつでも接続および切断できるため、クライアントの存在またはシャットダウンをサーバーにアナウンスする必要があります。サーバーは、特定のクライアントにデータを送信できなければなりません。
これに使用する最適なスケーラビリティ プロトコル/アーキテクチャは何ですか?
現在、クライアントが「ログイン」および「ログアウト」できるようにREQ/を使用し、サーバーがすべてのクライアントにデータを送信できるようにソケットを使用しています。送信されるメッセージには、メッセージを処理する特定のクライアントの ID が含まれています。REPSURVEY
これでいいですか、それとももっといいものがありますか？
パブリッシャーのサブスクライバーが必要なようです。0MQ と nanomsg の両方を使用すると、接続/切断を管理するために特に何もする必要はありません。ライブラリがそれを行います。
ただし、より高度なメッセージ管理 (別のクライアントが接続を選択した場合に備えて発信メッセージをキャッシュするなど) が必要な場合は、自分で管理する必要があります。クライアントからの 1 回のプッシュ プルを使用して、クライアントの存在を通知し (クライアントは、自分が誰であるかを示すメッセージを送信します)、その後、サーバーから各クライアントにさらにプッシュ プルを実行して、キャッシュからメッセージを送信します。あなたが持っている。面倒ですが、生のソケットでプログラミングするよりもずっと簡単です。
req rep を使用すると、問題が発生する可能性があります。一方の端がクラッシュしたり、予期せず切断されたりすると、もう一方が失速して回復不能な状態になる可能性があります。
アーキテクチャに影響を与える多くの側面があります。
両方の Martin SUSTRIK のクールな子供たち - ZeroMQ& nanomsg- は、スケーラブルなフォーマル コミュニケーション パターンの優れた基盤 + レゴ タイプのビルディング ブロックを提供することに大きく貢献しましたが、彼らはほんの始まりにすぎず、それREQ/REPまたはSURVEYBehavioral Primitives (素晴らしいイノベーションですが、それでもまだビルディング ブロック ) は、ほとんどすべてのアーキテクトとエバンジェリストを混乱させるアーキテクチャです。
元の質問は重要ですが、「より広い翼幅」を持つ一部の人々は、あなたの質問がMCVEコード例主導ではなく「広すぎる」または「意見」指向であると感じているため、管理上閉鎖する最初の提案をすでに取得しています( . ..はい、StackOverflowの生活は時々速くて残酷です）。
そのため、これ以上の詳細は入手できませんが、私の推奨は ( の最近のバージョンを確認することです。これは、 -sidePUB/SUBでフィルター処理を行うことができます( ではなく、初期の ZeroMQ バージョンの設計ではなく、すでに xmited / 何億ものバイトがラウンドに配信されている言及された.PUBSUBSUBSURVEY
コンテキストがなければ、真剣に判断するのはナンセンスです。設計および実装しようとしているものを改善することはできません。
私はそうしようとしていた貧弱なサービスをするでしょう。
私が今あなたにできることは、このテーマの全体像を見るようにあなたに指示することです >>>より多くの引数、簡単なシグナリング プレーン/メッセージング プレーンの図、およびPieter HINTJENS の必読の本への直接リンクを示します.