わかりましたこれはかなり広いですが、少し絞り込みましょう。私はクライアント/サーバー プログラミングを少し行いましたが、一度に数台以上のクライアントを処理する必要があるものは何もありません。したがって、これらのサーバーに対する最も主流のアプローチは何なのかという設計上の疑問がありました。そして、人々がチュートリアル、本、または電子ブックのいずれかを参照できれば. ははは。本当に絞れませんでした。私が探しているのは、サーバー側プログラムのセットアップ方法の単純だが文字通りの例だと思います。私の見方: クライアントはコマンドを送信します: サーバーはコマンドを受信してキューに入れます。サーバーには、このキューを常にポーリングする単一の専用スレッドまたはスレッド プールがあり、適切な応答をクライアントに返します。ノンブロッキング I/O は頻繁に使用されますか? チュートリアル、時間、練習だけが本当に必要だと思います。
*編集: ご回答ありがとうございます。ここに私がやろうとしていることのもう少しがあります。これは主に学習が目的なので、フレームワークやライブラリの使用はできる限り避けたいと考えています。たとえば、このやや作り上げられたアイデアを考えてみましょう。何らかの機能を実行し、出力をサーバーに常にストリーミングするクライアントプログラムがあり (これらのクライアントは多数存在する可能性があります)、サーバーは統計を作成し、ほとんどのデータを保存します。また、サーバーにログインできる管理クライアントがあり、いずれかのクライアントがサーバーにデータをストリーミングしている場合、接続されている各管理クライアントにそのデータをストリーミングするとします。これは、サーバー プログラム ロジックをどのように想定するかです。サーバーには、着信接続を管理するための 3 つのスレッド (リッスンしているポートごとに 1 つ) があり、各接続を管理するスレッドを生成します。
クライアントからサーバーにデータが届くと、サーバーは関連するものを解析し、そのデータをキューに入れます。たとえば、adminDataQueue です。次に、このキューを監視するスレッドがあり、200ms (またはその他) ごとにキューをチェックして、データがあるかどうかを確認し、ある場合は、AdminDataConnections を循環してそれぞれに送信します。
AdminConnection の場合、これはコマンドまたはデータの直接要求に使用されます。したがって、統計を要求できます。サーバー側は統計のコマンドを受信し、受信統計を示すコマンドを送信し、その直後に統計オブジェクトまたはデータを送信します。
AdminDataConnection に関しては、おそらくいくつかの単純なコマンドが絡み合った、クライアントからの単なる出力です。
すべてのクライアント データが各管理クライアントに集められるという論理的な問題の帯域幅の問題は別として。この設計では、スケーリングの問題 (クライアントとサーバー間の帯域幅、および管理クライアントとサーバー間の帯域幅を無視すること) により、どのような問題が発生するでしょうか。