1

次の点を考慮してください。

std::istream& operator>>(std::istream& is, message& p)
{
    typedef boost::archive::binary_iarchive in;  
    boost::iostreams::filtering_istream fis;
    fis.push(is, 0);
    in stream(fis);
    stream >> p;

    return is;
}

はmessage& pシリアライズ可能な構造体でstd::istream& is、tcp ストリームです。

サーバーはクライアントがコンストラクター内でデータを送信するのを待ち、in stream(fis);データが受信されると続行します。オブジェクトはstream、tcp ストリームからオブジェクトにデータをシリアル化しmessageます。

ここで、実際に受信したデータを次のように追加してフィルタリングすると、次のようになります。

std::istream& operator>>(std::istream& is, message& p)
{
    typedef boost::archive::binary_iarchive in;  
    boost::iostreams::filtering_istream fis;
    fis.push(boost::iostreams::zlib_decompressor(), 0);
    fis.push(is, 0);
    in stream(fis);
    stream >> p;

    return is;
}

TCPストリームからデータを読み取り、解凍してオブジェクトにシリアル化する必要がありますmessage。in stream(fis);しかし、代わりに、データが 10 ～ 20 回送信されるか、クライアントが切断された後、ハングアップして戻ります。

私はすでに zlib デコンプレッサの内部バッファを 0 と 1 の両方に設定しようとしました。ここで、0 はアサートに失敗し、1 は何とか 1 回だけ動作します (2 回目の反復でスローします)。また、バッファを 0 に設定filtering_istreamしたので、ハングすることはありません。std::istream& isまた、ファイル ストリームの場合は正しく動作することにも気付きました。

in stream(fis);では、 tcp ストリームを使用しているときに関数がハングするのはなぜですか? バッファを処理するzlibの方法と関係がありますか、それともfiltering_istream特定のものですか? また、この問題を解決するための回避策も聞きたいです。

4

1 に答える 1

1

あなたはすでに自分で質問に答えました;）

std::istream& がファイル ストリームの場合、正しく動作することにも気付きました。

filtering_istreamはEOFを取得するまでポーリングしているため、TCPストリームはクライアントの切断時にのみ終了するため、ストリームの読み取りは終了しません。そのifstream上で、彼のEOFを簡単に取得して処理を終了します。

于 2012-11-12T14:58:12.060 に答える