問題タブ [packet-loss]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
java - ObjectIOStreams を使用する Java ServerSocket およびソケットはパケットを失う可能性がありますか?
サーバーで ServerSocket を使用しており、ObjectIOStreams を使用してネットワーク接続を介してシリアル化可能なオブジェクトを送信するソケットを使用しています。私は独占の本質的により経済的なバージョンを開発しているため、パケットの送信と送受信の確認が必要です。独自のパケット損失ウォッチャーを実装する必要がありますか、それとも (Server)Sockets で既に処理されていますか?
私は主に、完全な接続エラーではなく、ネットワークブリップ中のパケットの損失について質問しています。たとえば、兄弟は私のルーターとコンピューターの Wi-Fi アダプターの間で鉛板を動かします。
http://code.google.com/p/inequity/source/browse/#svn/trunk/src/network コードは network->ClientController および network->Server の下にあります
tcp - UDP を介した TCP によるパケット損失と学士論文の参考文献
私は現在、コンピューター サイエンスとエンジニアリングの学士論文を書いており、OpenGL を使用して C++ でレーシング ゲームを作成しています。レポートでは、TCP と UDP の使用を比較しており、複数の TCP 接続が UDP 接続でパケット損失を引き起こす可能性があると主張するソースを見つけました。私も良い参考になりました
問題は、それが 13 年前のものであるという事実にありますが、この問題を修正するためにどちらのプロトコルも変更されたという兆候を見つけることができませんでした。また、同様の調査を行っている、より最新の論文や記事を見つけることができませんでした
したがって、私の質問は、関連する可能性のあるプロトコルに変更があったかどうか、および/または論文レポートでこの古い参照を使用することを忘れるべきかどうかです.
udp - ソケットバッファオーバーフローによるパケット損失はネットワーク損失と見なされますか?
ソケットバッファがいっぱいであるためにUDPパケットがホストでドロップされた場合、それをネットワーク損失と見なす必要がありますか?この違いは、アプリケーション層での再送信の実装を検討するか、バッファサイズを増やすかを決定するのに役立ちます。
私はUDPで立ち往生していますが、私のアプリケーションはパケット損失なしで順番にパケットを送信する必要があります...> _ <
packet-loss - バンドウィズ ディスタンスの損失 - 私は雄牛のラインを与えられていますか、それとも研究する必要がありますか?
2 つの健全なネットワークが、大きな帯域幅の損失なしに海を越えて相互に通信することは不可能であると説明しようとしている男性と、奇妙な会話をしたところです。
たとえば、http://www.hetzner.de/en/hosting/unternehmen/rechenzentrum で 100Mb/秒で接続されたマシンがある場合、まったく同じセットアップで米国のマシンと通信しようとします。元の接続速度の何分の一か。これは、負荷をどのように分散させても当てはまります。距離に対する総損失は同じです。米国とドイツの間の「全容量」は、発信元から 1 マイル離れたデータ センターに同じ設定を使用した場合の半分以下になります。
これが本当なら、それはパケットがどのように機能するかについての私の完全な理解が間違っていることを意味します. つまり、パケット損失がない場合、なぜ遅延以外の問題があるのでしょうか? 私は彼の主張を理解しようとしているが途方に暮れている. 彼は知的で、自分の情報に 100% 確信を持っているようです。彼はデータを川のように説明し、私はそれを一連のパケットとして考えていたので、非常に理解しにくかった.
誰かが私に欠けているものを説明してくれますか、それとも権威と自信のある立場にある狂人を扱っているだけですか?
c#-4.0 - C#:close()をすぐに呼び出すときにUdpClientがデータを送信しない
一部のコンピューターでは、UdpClient.Send()の直後にUdpClient.Close()が呼び出された場合、UdpClientがデータを送信しないという奇妙な効果があります。パケット損失を確認するために.NET4.0とWireSharkを使用しています。
コーディングの重要な部分は次のとおりです。
奇妙なのは:
- ほとんどのコンピューターでは、データは問題なく送信されます
- パケットが送信されなくても例外やその他のエラーはありません
- bytesSentは常にdata.Lengthと等しくなります
- パケットを送信しないコンピューターでは、sender.Close()を呼び出す直前にThread.Sleep(250)で問題が解決します。
では、UdpClient.Send()が正しいバイト数を報告した後でも、何がパケットの送信をキャンセルできるでしょうか。これが特定のマシンでのみ発生するのはなぜですか?これは、一部のネットワークドライバ、ウイルス対策ソフトウェアなどの異なる動作である可能性がありますか?
また、LingerOptionsを明示的に設定しようとしましたが、デフォルトでは、基になるソケットを閉じる前にすべての保留中のデータを送信するため、これは不要です。ただし、sender.Client.LingerState = new LingerOption(true、10)を実行する場合(http://msdn.microsoft.com/en-us/library/system.net.sockets.socket.lingerstate.aspxで説明されているように)取得します
何が起こっているのかアイデアはありますか?
よろしく、セブン
.net - VB.NET 非同期ソケット パケットが失われる
一度に複数のクライアントと通信するTCPサーバーを作ったのですが、うまく安定しないようです。クライアントの 1 つがサーバーに 100 個のパケットを送信すると、サーバーはそのうちのいくつかしか受信しません。
PasteBin のクライアント コードは次のとおりです。クライアントがサーバーに接続し、For ループで 100 個のメッセージをサーバーに送信する方法を示しています。
サーバーが接続を処理する方法は次のとおりです。数百行の長さのため、完全なソースを貼り付けることができませんでした。必要な部分が欠落している場合はお知らせください。それらもアップロードします。
flash - Flexでのパケット損失の計算
Flexからパケット損失を計算する方法。何か案が?
前もって感謝します。
flash - パケット損失テスト
フラッシュ テクノロジー (Flash または Flex) からのping テストのようなパケット損失テストを行う方法について考えている人はいます か? 私を助けてください。
linux - パケット損失の強制
テストの目的で、パケット損失が存在する場合にプロトコル実装がどのように動作するかを判断するために、ネットワークデバイスの1つでパケット損失を強制したいと思います。具体的には、0%から100%の間のどこでもパケット損失を調整できるようにしたいと思います。私はiptablesの経験が少しあり、それを使用してそれを達成できるはずですが、私はそれを達成できませんでした。ただし、100%のパケット損失を達成することは問題ではありません;)。これを行う方法についてのアイデアはありますか?
multicast - 参加および脱退時にマルチキャスト データグラムを失う
サーバー ソフトウェアで、1 つのスレッドがマルチキャストに参加すると、別のスレッドが同じ瞬間に別のマルチキャストで着信データグラムを受信できないという問題が発生しています。これが UDP マルチキャストの「信頼性の低い性質」による予想される損失として片付けられるかどうか、またはこれが重大なドライバー/NIC の欠陥であるかどうかはわかりません。パケットキャプチャもその瞬間のギャップを示しています。
この問題は、Intel や HP など、複数の NIC モデルとメーカーで確認されています。これが NIC またはドライバーの問題であると私が感じる理由は、インターフェイスを無差別モードにするパケット スニファーを実行すると、問題がまったく発生しないためです。
IGMP の参加または脱退が NIC の転送テーブルを更新している間に、その時点ですべてのマルチキャスト トラフィックの転送が停止する可能性はありますか? これは受け入れられますか?