1

そのため、ネットワークからパケットを読み取り、メッセージを正しく再構成できる QA 部門用のツールを作成することを任されました (彼らは私たちのログを信用していません...長い話です)。

通信をリッスンしようとしているアプリケーションは、.NET の TcpListener クラスと TcpClient クラスを使用して通信しています。パケットの傍受は問題ではありません (私はSharpPcapを使用しています)。ただし、パケットをアプリケーション レベルのメッセージに正しく再構成することは、少し難しいことがわかっています。

一部のパケットには、1 つのメッセージの終わりと次のメッセージの始まりがあり、.NET の NetworkStream オブジェクトがアプリケーション レベルのメッセージのどこで終わり、もう 1 つのメッセージが始まるかをどのように判断できるかわかりません。

アプリケーション レベル メッセージの最後を含むパケットはすべて、TCP ヘッダーの「PSH」(プッシュ) フラグがオンになっていることがわかりました。しかし、メッセージの最後がそのパケット内のどこにあるかを .NET が正確に認識する方法がわかりません。

1 つのパケットのデータは次のようになります。

/></Message><Message><Header fromSystem=http://blah

</Message>ストリームは、メッセージの最後までのみをアプリケーションに送信し、残りのメッセージが完了するまで残りを保存することをどのように認識しますか?

フラグメンテーション用に設定された IP レベルのフラグはなく、.NET ソケットはアプリケーション レベルのプロトコルを認識しません。だから私はこれが信じられないほど厄介だと思います。任意の洞察をいただければ幸いです。

4

1 に答える 1

4

ストリームは、アプリケーション プロトコルの一部である必要があります。

NetworkStreamデータをオブジェクトに変換するものは何も組み込まれていません。それができると思う理由は何ですか？NetworkStream を使用するコードはどのようなものですか? おそらく、なんらかの形式の XML デシリアライゼーションを行っていて、コードの読み取りが終了タグに到達すると自動的に停止しますか?

基本的：

  • プロトコルにメッセージ区切り文字または長さプレフィックスがない場合は、おそらく次のようにする必要があります
  • NetworkStreamそれ自体が巧妙なことをしている可能性は非常に低いですが、あなたが観察していることを教えていただければ、何が起こっているのかを突き止めることができるかもしれません.
于 2010-02-01T23:26:05.687 に答える