0

Solaris上のJavaサーバーに.Net/C＃クライアントを書き込んでいます。

Javaサーバーは、抽出する必要のあるGzip形式でRawバイトデータを書き込んでいますが、適切なバッファーサイズでデータを読み取るのに問題があります。決定論的に不完全または完全ではないメッセージを読みましたが、どのような場合でも2番目のメッセージを読むことができません。DataAvailableプロパティを持つNetworkStreamクラスを使用してバイトを読み取っています。

私の推測では、それはリトル/ビッグエンディアンの問題に関連している可能性があります。データをビッグエンディアンからリトルエンディアンに変更するには、特別な変換を使用する必要がありますか？gzipヘッダーを使用して必要なバイトを読み取る必要がありますか？

以前は非圧縮プロトコルで同じサーバーを使用していましたが、以前はReadLine関数でStreamReaderを使用しても問題はありませんでしたが、そのプロトコルは純粋にテキストベースでした。

編集：残念ながら、リモートサーバーとプロトコルが指定されているため、選択の余地はありません。エンディアンはGZip形式の一部ですか、それともそれに応じてヘッダーを変換するだけで済みますか？非圧縮データは、区切り文字として改行を含む純粋なUTF8エンコード文字列です。

4

1 に答える 1

2

GZIP 形式は複雑ではありません。シンプルでアクセスしやすい仕様ドキュメント、IETF RFC 1952ですべての栄光を手に入れることができます。

GZIP 形式は、バイトのビット順序を指定します。エンディアンのフラグでは調整できません。GZIP ストリームのプロデューサーは、その点で仕様に準拠する責任があり、GZIP ストリームのコンシューマーも同様です。

これをデバッグする場合は、ワイヤの両端のバイトを調べて、入ってくるバイトが出てくるバイトと同じであることを確認します。エンディアンの問題を脇に置くにはこれで十分です。

GZIP バイトストリームの送信に成功しない場合は、テスト データ (16 バイトの 0xFF、その後に 16 バイトの 0xAA など) を送信してみてください。次に、これが相手側から送信されるデータであることを確認します。

申し訳ありませんが 、メッセージを読んだという意味がわかりません-決定論的に不完全または完全ではなく、いずれにしても 2 番目のメッセージを読むことができません。 セカンドメッセージ？2 番目のメッセージは？エンディアンは、受信するデータの量に影響を与えるべきではありません。

データを正常に送信しているという自信がないように感じます。エンディアンの問題と GZIP 形式の問題に取り組む前に、それを確認することをお勧めします。

于 2009-05-12T23:55:37.800 に答える