1

Win32名前付きパイプを介してZeroMQワイヤ形式を実装しています。この形式では、メッセージの前にそのサイズを追加する必要があります。私のインターフェースは、ユーザーがすでにデータの正確なサイズのバッファーを割り当てているように見えますsend(std::vector<unsigned char>)。そして、に基づいてサイズヘッダーを作成しvector.size()ます。

現在、パイプへのスタンドアロン書き込みでサイズヘッダーを送信しています。しかし、その後の実際のメッセージコンテンツの書き込みが失敗した場合、データストリームは悪い状態のままになり、受信者はより多くのデータを期待しますが、送信者はそのメッセージが失敗したと見なします。

サイズヘッダーとコンテンツを1つのパイプ書き込みに結合して、ヘッダーがそれ自体を通過しないようにしたいのですが。vectorただし、コンテンツはかなり大きい可能性があるため、のコンテンツのコピーは避けたいと思います。2つのバッファを1つのWin32パイプ書き込みに結合する方法はありますか？

unsigned char *getPipeBuffer(size_t size)そうでない場合は、ヘッダーに余分なスペースを割り当てるようなものをいつでも追加できます。ただし、インターフェイスはそのままにしておくと便利です。

4

3 に答える 3

4

でパイプを使用することを検討しましたPIPE_READMODE_MESSAGEか? このようにして、メッセージのサイズを無料で取得し、メッセージ自体に含める必要はありません。

書き込みの場合、書き込み操作はメッセージ全体が書き込まれたときにのみ終了します。

読み取りの場合、読み取り操作は 1 つのメッセージを読み取ります。または、メッセージがパイプ バッファーに収まらない場合は、その一部を読み取り、さらに待機中のデータがあり、残りのメッセージを受信するにはもう一度呼び出す必要があることを報告します。

メッセージのサイズを渡す必要はありません。なぜなら、受信者は 1 つのメッセージの読み取りをいつ終了したかを常に知っているからです。

パイプ クライアントの場合、 への呼び出しでパイプ読み取りモードを変更する必要があることに注意してくださいSetNamedPipeHandleState。

詳細はこちら。

于 2012-12-18T16:32:52.530 に答える
1

私の最初の対応はWriteFileGatherを使用することでしたが、これには関数に渡すバッファーの配置に関する厳密な要件があり、強制するのが難しい場合があります。ドキュメントを確認した後、これはパイプではまったく機能しない可能性があるようです。なぜそうならないのかわかりませんが。

サイズ用とデータ用の 2 つの異なる書き込みを行うことは問題ないと思います。2 番目の書き込みが失敗し、ストリームが一貫性のない状態のままになった場合にどうなるかを尋ねます。この場合、相手側はより多くのデータを期待しています。しかし、単一の書き込み要求でさえ、パイプをこのような状態のままにすることがあります。

于 2012-12-18T16:07:07.957 に答える
1

参照として使用しているページの冒頭に、「警告: このテキストは非推奨であり、古いバージョンの ØMQ を参照しています。歴史的な関心のためにここに残されています。これを使用して ØMQ を学習しないでください。」と書かれていることに注意してください。

これは 0MQ ワイヤ形式ではありません。0MQ ワイヤ形式が必要な場合は、RFC サイトhttp://rfc.zeromq.org/spec:15にあります。

于 2012-12-23T18:33:48.983 に答える