0

アプリケーションで Apache Thrift を使用して、複数のマシン間でデータを交換しています。

outspace からデータを受け取り、トランスポート、プロトコルを作成し、受け取ったデータをオブジェクトにデシリアライズします。これが私のコードです：

using (var memoryStream = new MemoryStream(data))
        {
            using (var transport = new TStreamTransport(memoryStream, memoryStream))
            {
                transport.Open();
                using (var protocolo = new TBinaryProtocol(transport))
                {
                    var result = new TCciUserLoginV1.cciUserLoginV1_result();

                    while (result.Success== null)
                    {
                        try
                        {
                            result.Read(protocolo);
                        }
                        catch { }
                    }

                    if (result.Success != null)
                    {
                        res = new RequestResult(result.Success);
                    }
                    else
                    {
                        res = new RequestResult(ResultCodes.LOCAL_ERROR");
                    }
                }
            }
        }

他のタイプの逆シリアル化は例外をスローするため、バイナリシリアル化されたTCciUserLoginV1.cciUserLoginV1_resultを受け取ります。ただし、 result.Successプロパティの通常の逆シリアル化は、while サイクルの 10 回目の反復後にのみ発生します。whileを使用した理由は何ですか。誰が何が起こっているのか教えてもらえますか?

前もって感謝します。

4

1 に答える 1

1

受信データ バッファにガベージが含まれているように見えます。図を参照してください。データは上に表示され、同じセットアップを使用した正しいサンプル メッセージが下に表示されます。

データの最初のバイトは、型コード バイトの後に 16 ビットのフィールド ID が続く必要がありますが、サンプルでは両方の数値が完全に正気ではありません。48 は有効な型コードではなく、-32248 は適切なフィールド ID ではないようです。 .

写真を詳しく見て、同じ IDL 定義を使用した正しいサンプルと比較すると、メッセージが先頭ではなく、オフセット 0x59 の中間のどこかから始まっていることが明らかになります。したがって、逆シリアル化のために Thrift に送信されたデータは、有効なデータ ブロックではありません。

何か重大な問題があることを示すもう 1 つの指標は、2 つのデータ サンプルのサイズの違い (2093 バイトと 93 バイト) である可能性があります。

分析

しかし、そのサービスの開発者は、私のコードがすべて正しいことを保証し、それを Java に変換した後、すべてがサイクルなしで正常に動作します。

それは、問題があなたが受け取るものとDecrypt()ルーチンから出てくるものの間にあることを示している可能性があります. ワイルドな推測ですが、それは次に確認することです。反対側で暗号化されたものと出てくるものを比較します。または、データ BLOB を、復号化後に動作中の Java テスト コードが表示するものと比較します。どこかに違いがあるはずです。

于 2014-10-22T21:01:04.337 に答える