問題タブ [boost-asio]

GUI が接続して大量のメッセージを受信するアプリケーションを使用していますが、問題は時々メッセージを順不同で受信することです。

接続は別のワーカー スレッド (別の) で実行され、他の人が文字列メッセージをパラメーターとして呼び出すためのコールバックとして関数 (を実行する)io_serviceを公開します。(つまり)、sendasync__writeio_service::wrapcallback = io_service_.wrap(boost::bind(&SomeGUIClass::send,this,_1));

そのため、GUI クライアントに何かを送信するために、他の呼び出し-のキューcallback(stringMessage)で send 関数呼び出しを正しくディスパッチする必要があります。io_service

メッセージは を呼び出す前は正しい順序になっていますが、 write 呼び出しの直前に、callback内で順序が乱れることがあります。callback

私の推論: wrap は、ラップされたdispatchfn を呼び出そうとする a に変換されます。callback(スレッド セーフの保証を満たすことができる場合)内で実行し、それができない場合は後で実行するようにスケジュールします。したがって、ディスパッチが同じ .xml 内で処理できたため、以前のメッセージが後で書き込むようにスケジュールされ、最新のメッセージが処理されることがありますcallback。この推論が正しいかどうかを教えてください。アイデアをいただければ幸いです。ありがとう！

boost::asio を使用する C++ で記述されたアプリケーションがあります。ソケットでリクエストをリッスンし、リクエストごとに CPU バウンドの作業 (ディスクやネットワーク I/O なしなど) を実行し、レスポンスで応答します。

このアプリケーションはマルチコア システムで実行されるため、リクエストを並行して処理するために、コアごとに (少なくとも) 1 つのスレッドを用意する予定です。

ここで最善のアプローチは何ですか？考慮事項:

• 固定サイズのスレッド プールが必要です (例: CPU ごとに 1 スレッド)
• スレッド数よりも多くのリクエストが到着した場合は、それらをキューに入れる必要があります (おそらく、o/s ソケット レイヤーで?)

現在、サーバーはシングル スレッドです。

• クライアントのリクエストを待ちます
• リクエストを受信すると、作業を実行し、レスポンスを書き戻し、次のリクエストの待機を開始します

アップデート：

より具体的には、サーバーがビジー状態の場合に着信要求がキューに入れられるようにするには、どのメカニズムを使用すればよいですか? N 個のスレッド (コアごとに 1 個) 間で着信要求を分散するには、どのメカニズムを使用すればよいですか?

mysql c-api と boost::asio の間で Windows ヘッダーと競合しているようです。

最初に mysql を含めると、次のようになります。

boost/asio/detail/socket_types.hpp(27) : 致命的なエラー C1189: #error : WinSock.h は既に含まれています

boost::asio を最初に含めると、次のようになります。

include\config-win.h(24) : 警告 C4005: '_WIN32_WINNT' : マクロの再定義

これを回避する方法はありますか? また、なぜ mysql は Windows バージョンを強制しようとし、ブーストは winsock 自体を含めることを強制しようとしているのでしょうか?

ブースト asio リファレンスを読み、チュートリアルを読み、いくつかの例を見ました。それでも、ソケットを破棄する方法がわかりません。

1. close() を呼び出す必要がありますか、それともソケットのデストラクタによって行われますか?
2. shutdown() を呼び出すタイミング
3. shutdown() の効果は何ですか? 「送信または受信を無効にする」ことは承知していますが、これはどのように行われますか? ソケットを無効にした後、ソケットを使用して送受信するとどうなりますか?
4. close() から予想されるエラー

何らかの理由でこれによりアクセス違反が発生しますが、これに関する詳細なドキュメント/ヘルプがないため、どこで間違っているのかわかりません。私がブーストサイトで見たものを通り抜けるので、これは正しいはずであり、クライアントからの各asio::write呼び出しの内容を新しい行に出力します。クライアントは正常に動作しているようです。その時点でサーバーはクラッシュしますが、まだ何も送信していません。

アクセス違反は、275行目のbasic_stream_socket.hppで発生します。原因は、オブジェクト（boost :: asio :: stream_socket_service）が初期化されていない（このポインターの値が0xfeeefeeeである）ためと思われますが、理由はわかりません。そうではありません。

プログラムの出力：

サーバーの起動
Server::startAccept（）
Server :: handleAccept（）
接続が受け入れられました
Connection :: startRead（）
Server :: startAccept（）
Connection :: handleRead（）読み取り
エラー：いずれかのスレッドが終了したため、I/O操作が中止されましたまたはアプリケーションリクエスト
Connection::startRead（）

コード

boost::asio::ip::tcp::socketのread_some/write_someメンバー関数の呼び出しとboost::asio::read/boost::asio::writeフリー関数の呼び出しの違いは何ですか?

すなわち：

どちらか一方を使用する利点はありますか?

両方がライブラリに含まれているのはなぜですか?

boost ::asioを使用してC++でミニHTTPサーバーを開発しましたが、現在、複数のクライアントで負荷テストを行っていますが、CPUの飽和状態に近づくことができませんでした。私はAmazonEC2インスタンスでテストしており、1つのCPUの約50％、別のCPUの20％を使用しており、残りの2つはアイドル状態です（htopによる）。

詳細：

• サーバーはコアごとに1つのスレッドを起動します
• リクエストは受信され、解析され、処理され、レスポンスは書き出されます
• 要求は、メモリから読み取られるデータに対するものです（このテストでは読み取り専用）
• それぞれがJavaアプリケーションを実行し、25スレッドを実行し、リクエストを送信する2台のマシンを使用してサーバーを「ロード」しています
• 約230リクエスト/秒のスループットが見られます（これはアプリケーションリクエストであり、多くのHTTPリクエストで構成されています）

それで、この結果を改善するために私は何を見るべきですか？CPUがほとんどアイドル状態になっていることを考えると、その追加容量を活用して、たとえば800リクエスト/秒などのより高いスループットを実現したいと思います。

私が持っていたアイデア：

• リクエストは非常に小さく、多くの場合数ミリ秒で実行されます。クライアントを変更して、より大きなリクエストを送信/作成することができます（おそらくバッチ処理を使用して）
• Selectデザインパターンを使用するようにHTTPサーバーを変更できますが、これはここで適切ですか？
• ボトルネックが何であるかを理解するために、いくつかのプロファイリングを行うことができます

何らかの理由でマストとスレーブの両方が失敗しましたが、それらがどのように機能するかについての良い例を見つけることができたので、どこで間違ったのかわかりません.

マスターは ConnectNamedPipe の後に WaitForSingleObject を終了することはなく、スレーブは最初の boost::asio::read 呼び出しで例外をスローします。「プロセスがパイプのもう一方の端を開くのを待っています」。マスターの ConnectNamedPipe と一緒に待ちますか?

マスター.cpp

スレーブ.cpp

明らかに、私は何か完全に間違っていましたが、ネット上で自分のコードを比較するものを見つけることができませんでした。