1

私はUDPを介してビデオストリーミングのアプリケーションを持っており、それは完全に成功しています。ソケットをTCPに変更しました。少数のパケットが転送された後、RSTが送信され、動作を停止します。 (MTUが1400である一方で、大きな長のパケットも送信者から受信者へ転送された奇妙である - このパケットは何か?)私は受信機と送信者のログをチェックしRST TCPソケットを介したビデオストリーミングでは?

enter image description here

。受信者によって受信された最後のパケットには、大きくて奇妙なシーケンス番号(ダンプパケット)があります。エラーが発生してアプリケーションが停止します。送信者はそのようなパケットを送信していません。このパケットはどこから来たのですか?それはそれを作るトランスポート層ですか?私は、各パケットが送信後に送信者に睡眠時間(0.1秒)を加え

enter image description here

。このプログラムは、Wiresharkや奇妙なシーケンス番号で奇妙な長さのパケットがなくても動作しますが、これはビデオにとって妥当な解決策ではありません。 あなたの提案は何ですか?何が問題なの?どのようにこのネットワークを分析できますか?どうすればそれを解決できますか?

+0

ソケットタイプをTCPからUDPに変更する根本的な理由は何ですか? UDPからTCPへの – szulak

+0

私はその違いを研究し、その後私はTCPに基づいて新しいプロトコルを実装しようとしています。 –

+0

通常、ループバックインターフェイス(アドレス127.0.0.1のもの)のMTUは、Linuxでは64Kです(MACでは16K - Windowsについてはわかりません)。アプリケーションのバッファサイズは、各TCPパケットで送信されるデータの量を直接決定するわけではありません。 OSは、(MTU、受信者のウインドウなどのように)送信を決定した時点で利用できるように、TCPペイロードに多くのデータを自由に置くことができます。 'TCP_NODELAY'オプション(' tcp(7) 'のmanページを見てください)を調べたいかもしれません。 –

答えて

0

これは奇妙な長さではありません。これはおそらくtcpオフロードです。 ethtool -kインターフェイス を参照してください。オフロードをオフにして、もう一度お試しください。おそらく最初は無関係です。これはおそらくアプリケーションの問題です。

関連する問題