2017-09-02 36 views
-1

私は、UDPを介して外部機器と通信するアプリケーションを開発しました。ほとんどの場合、完全に機能するようですが、ある特定のラップトップでアプリケーションを使用しているときにパケット損失を経験した顧客が1人あります。彼の他のラップトップは大丈夫です。半二重UDP?

彼はバッファサイズのような明白なものをチェックしましたが、明らかに間違ったものはありません。

その後、ラップトップにEtherSnoopをインストールして、何が起こっているのかを調べると、ラップトップが外部機器にメッセージを送信するたびに、受信メッセージの受信を短時間停止するように見えます。これは、ラップトップのイーサネットリンクが半二重動作しかできないかのようです。

関連するノートPCは、RealTekネットワークチップを使用しているHPです。彼の優れたラップトップは、Intelのネットワークチップを使用したLenovoです。

この現象が発生する可能性のある設定はありますか?このアプリケーションでは、パケットロスは受け入れられません.HPについて「何か」が何であるかを知る必要があります。

+0

質問を編集することができます。半二重が問題であることの確認をお探しですか?これを検出してパケット損失を緩和する方法を探していますか? – wmorrell

+0

注:(動作中の)半二重NICであっても、パケットは破棄されません。チャネルが解放されるまでキューに入れられます。キューがいっぱいでない限り、ofc。 – spectras

+0

私はちょうどその問題を修正しました。 –

答えて

-1

クライアントシステムが不安定に実行される/パケット損失が発生した場合、ほとんどできません。デュプレックスの不一致や衝突ドメインが大きすぎない限り、半二重リンクをCSMA/CDごとに使用しても、UDPは確実に(下記参照)配信されます。

あなたは、ネットワーク接続のトラブルシューティングを除外/デュプレックスのミスマッチを修正し、ケーブルをチェックし、NIC &スイッチのconfigsをチェックし、NICドライバを更新、ハードウェアを置き換えることができます - USBドングル?...

デュプレックスのミスマッチができスイッチポートまたはNICのいずれかによって引き起こされる可能性があります。設定が間違っていない限り、それは非常にまれです。全二重側ではFCSエラーが発生し、半二重側では極端な衝突数が表示されます。全体的に、あなたが真剣にそれを使用しようとすると、接続は非常に遅く動作します。ギガビットリンクはFDXのみを使用するため、デュプレックスのミスマッチはほとんどあり得ません。

PS:EJPが正しく指摘したように、エンジニアリングの場合のようにUDPは「信頼できる」とは言えませんが、100%信頼できる - 上記の99%のように「信頼できる」という庭園を使用しています。

+1

UDPについて信頼できるものは何もありません。それは火の神気のないプロトコルです。 – EJP

+0

UDPは配信のために基礎となるプロトコルに100%依存します。イーサネットネットワークを介して実行されていれば、ネットワークに問題がないかぎり、それを通過する必要があります。 – Zac67

-1

この問題は、関係するラップトップのバッファオーバーランが原因であることが判明しました。なぜこの特定のラップトップが他のものと異なっているかについては、依然として謎です。私は以来、この特定のラップトップ上のバッファの問題を説明するために私のアプリを変更して、今はすべてうまくいくようだ。