0

Indy10で奇妙な問題が発生しており、TCPを使用して次々に送信する2つの大きな文字列（それぞれ数百文字）が、奇妙に絡み合って表示されています。これは非常にまれにしか発生しません。

各文字列はLFで終了する完全なXMLメッセージであり、通常、READプロセスはXMLメッセージ全体を読み取り、LFを検出すると戻ります。

実際にメッセージを送信するための呼び出しは、IOHandlerのwritelnメソッドへの呼び出しの周りのクリティカルセクションによって保護されているため、2つのスレッドが同時に送信することはできません。（クリティカルセクションが適切に実装/機能していることは確かです）。この問題はめったに発生しません。症状は奇妙です...文字列Aに続いて文字列Bを送信すると、もう一方の端で受信したもの（まれに障害が発生する場合）は、文字列Aの後続セクション自体です（つまり、、最後にLFがあります）、その後に文字列Aの先頭セクションが続き、次に文字列B全体の後に1つのLFが続きます。部分的な読み取りの後、「タイムアウト」プロパティがtrueではないことを確認しました。コンテンツを返すすべての読み取りの後にそのプロパティをログに記録します。また、LFを追加して送信する前に、文字列内のすべての英数字以外の文字をスペースに明示的に置き換えるため、文字列にLF文字が埋め込まれていないこともわかっています。

送信側と受信側の両方のクリティカルセクション内にログメカニズムがあるため、「ワイヤ」でこの動作を確認できます。

私たちは完全に困惑しており、この問題を引き起こす可能性のある低レベルのIndyの問題があるかどうか（常に最も可能性は低いですが）、たとえば、バッファが間違った順序で送信されている可能性があるかどうか疑問に思っています。問題ですが、私たちはストローを把握しています。

誰か明るいアイデアはありますか？

4

4 に答える 4

4

Wiresharkを試して、データがどのように転送されるかを調べることができます。このようにして、問題がサーバーにあるのかクライアントにあるのかを知ることができます。また、TCPを使用して、「保証された」有効なデータを正しい順序で取得することを忘れないでください。

于 2010-03-14T07:29:29.187 に答える
3

TCPまたはUDPを使用していますか？UDPを使用している場合、ネットワークを介したルーティングにより、UDPパケットが送信された順序とは異なる順序で受信される可能性があります（予想されます）。この場合、受信者がパケットを適切に注文できるように、各UDPパケットに何らかのパケットIDを追加する必要があります。

于 2010-03-14T07:25:32.437 に答える
2

受信側で同時に同じソケットから複数のスレッドを読み取っていますか？Connected（）ステータスを照会するだけでも、読み取りが発生します。注意しないと、複数のスレッドがインバウンドデータを読み取り、ランダムな順序でIOHandler.InputBufferに格納する可能性があります。

于 2010-08-02T21:12:14.357 に答える
2

IOHandlerのNagle設定を確認しましたか？UseNagleをfalseに設定することで修正した同様の問題がありました。私たちの場合、Nagleの合体により、大量のデータをバーストで送受信するのが遅いため、状況とはまったく同じではありません。

于 2010-08-03T05:02:04.473 に答える