0

現在のプロジェクトを書き直して、より多くの機能と安定性を追加しようとしていますが、設計の助けが必要です。これがその要旨です（Linuxの場合）：

  • TCP_SERVER が接続を受信 (認証パケット)
  • TCP_SERVER は、新しいクライアントを処理するために新しい (スレッド/フォーク) を開始します
  • TCP_SERVER はクライアントから多くのパケットを受信します > 循環バッファに追加されます
  • そのクライアントがそれらのパケットを処理し、オブジェクトのリストを作成するために、別のスレッドが作成されます。
  • オブジェクトのリストの一部を別のクライアントに送信するには、別のスレッドを作成する必要があります

すべての処理をスレッドに分割する理由は、サーバーが多くのパケットを取得し、処理が追いつかないためです (時間に敏感なため、迅速である必要があります) (内部の場合に tcp がパケットをドロップするかどうかはわかりません)。バッファーが大きくなりすぎた場合)、別のスレッドを別のクライアントに送信して、処理を可能な限り高速に保ちます。

そのため、新しい接続ごとに 3 つのスレッドを作成する必要があります。1つはパケットを受信し、1つはそれらを処理し、1つは処理されたデータを別のクライアントに送信します（技術的には、異なるデバイス上の同じ人物/ IPです）

そして、これをどのように構造化するか、何を使用するか (フォーク/スレッド)、どのライブラリを使用するかなど、これを設計するのに助けが必要です。

4

2 に答える 2

0

You plan to create one-or-more threads for every connection your server handles. Threads are not free, they come with a memory and CPU overhead, and when you have many active threads you also begin to have resource contention.

What usage pattern do you anticipate? Do you expect that when you have 8 connections, all 8 network threads will be consuming 100% of a cpu core pushing/pulling packets? Or do you expect them to have a relatively low turn-around?

As you add more threads, you will begin to have to spend more time competing for resources in things like mutexes etc.

A better pattern is to have one or more thread for network io - most os'es have mechanisms for saying "tell me when one or more of these network connections has io" which is an efficiency saving over having lots of individual threads all doing the same thing for just one connection.

Then for actual processing, spin up a pool of worker threads to do actual work, allowing you to minimize the competition for resources. You can monitor work load to determine if you need to spin up more to meet delivery requirements.

You might also want to look into something to implement the network IO infrastructure for you; I've had really good performance results with libevent but then I've only had to deal with very high performance/reliability networking systems.

于 2013-11-04T04:05:40.723 に答える
0

これを自分でやろうとすると、苦痛の世界になります。実際のアプリケーションに集中し、既存のソケット処理フレームワークを活用してください。たとえば、あなたは次のように言いました。

新しい接続ごとに、3 つのスレッドを作成する必要があります

その声明は次のように述べています。2. スレッドの作成や同期操作のベンチマークを行ったことがない。3. このアプローチでうまくいかないことの数は、かなり圧倒的です。

このほとんどを実行する既存のライブラリを使用することを真剣に検討してください。これに足場を正しく配置するには、文字通り何年もかかる可能性があり、すべてのランダムな配管ではなく、コードに集中する方がよいでしょう。

Boost C++ ライブラリには、優れた Async C++ ソケット処理インフラストラクチャがあるようです。これを既存の C++ スレッド プールのいくつかと組み合わせると、非常にパフォーマンスの高いソリューションをかなり迅速に作成できる可能性があります。

また、これに対する C++ の使用についても質問します。Java と C# は両方とも非常にスケーラブルなソケット サーバーをうまく機能させ、一部の高レベル言語ツール (Spring、Guarva など) は非常に価値があります。TLS や別のメカニズムを介してこれを保護したい場合は、C++ よりも Java や C# の方がはるかに簡単です。

1. 真の非同期 I/O により、パフォーマンスとスケーラビリティが大幅に向上します。これを行うために本当に一生懸命努力してください。ブースト asio ライブラリはかなり良さそうです。2. 新しいソケット処理プラットフォームを構築するのではなく、機能と安定性に集中します。3. スレッドはコストがかかるため、作成しないでください。スレッドプールはあなたの友達です。

于 2013-11-04T03:54:13.083 に答える