1

私は初心者で、いくつかのネットワークプログラミングに手を尽くしています。マルチキャスト経由でデータを読み込んでおり (以下のコードを参照)、最大伝送単位 (MTU) または読み取ることができる伝送単位を見つけたいと考えています。誰でもソースまたはこれを行う方法に私を導くことができますか. ありがとうございました。

  try {
        InetAddress add = InetAddress.getByName("127.0.0.1");

        MulticastSocket socket = new MulticastSocket(1234);
        socket.joinGroup(add);

        byte[] bb = new byte[2500];

        while (true) {

            DatagramPacket data = new DatagramPacket(bb, bb.length);
            datagramSocket.receive(data);
            processDataReceived(bb);
        }

        datagramSocket.leaveGroup(socket);
    }
    catch (IOException e) {
        e.printStackTrace();
    }
4

3 に答える 3

1

MTU とは

最大伝送ユニットは、パケットが移動するパス全体で確実にフラグメント化されないパケットの最大サイズです。flakes が言及しているように、この断片化は通常、UDP を介しても透過的に行われることに注意してください。そのため、パス MTU を大幅に超えたとしても、パケットはおそらく安全に再構成されて到着します。

そのため、MTU は主に、中間ノードの送信のオーバーヘッドを下げるためのツールであり、再構成のために最も遅い部分のためにパケットを保持することで発生するレイテンシーを下げる可能性があります。

一般に、MTU を見つける方法

RFC 4821は、このプロセスの非常に優れた概要です。

要するに、「do-not-fragment」フラグといくつかのジャンク パディング データを含む ICMP ping を送信します。ICMP の「パケットが大きすぎます」というメッセージをリッスンします。ping 応答を受信した場合は、より大きな ping パケットで再送信します。「パケットが大きすぎます」というメッセージが表示された場合は、ping を小さくして再送信してください。このようにして、実際の MTU に向かってバイナリ検索を行うことができます。

残念ながら、これはマルチキャストなので...

RFC 4821 のセクション 5.4には、

マルチキャスト宛先アドレスの場合、パケットのコピーは、多くの異なるパスを通過して、多くの異なるノードに到達する可能性があります。マルチキャスト宛先への「パス」のローカル表現は、実際には潜在的に大きなパスのセットを表す必要があります。

最低限、実装は、ノードから発信されたすべてのマルチキャスト パケットに使用される単一の MTU 値を維持してもよい (MAY)。この MTU は、マルチキャスト ツリーを構成するすべてのパスのパス MTU よりも小さいと予想されるほど十分に小さい必要があります。構成されたマルチキャスト MTU よりも小さいパス MTU がユニキャスト手段を介して学習される場合、マルチキャスト MTU はこの値に削減される場合があります。このアプローチでは、多くのパスに必要なパケットよりも小さなパケットが使用される可能性があります。

マルチキャストを使用するアプリケーションが完全な配信レポートを取得する場合 (この要件はスケーリング プロパティが不十分であるためありそうもない)、グループ全体で学習した最小のパス MTU がそのグループの有効な MTU になるように、PLPMTUD をマルチキャスト プロトコルに実装してもよい (MAY)。

そのため、マルチキャスト ユーザーの MTU を見つけることはおそらくあまり現実的ではありません。

残念ながら、これはJavaなので...

Java は ICMP をサポートしていません。まったく。また、UDP を介してこれを行うことは実際には不可能です。透過的な再構成のため、断片化がいつ発生したかはわかりません。

したがって、2つのオプションがあります

  • パケットの断片化についてあまり心配する必要はありませんが、受信側のバッファー サイズの契約を宣言してください。たとえば、RUDP では、各側が接続の開始時に受信バッファ サイズを宣言し、送信者は送信されたパケットでそのサイズを超えてはなりません ( MUST NOT )。
  • MTU について可能な限り最も悲観的でひどい見積もりを行います。すべての IPv4 ハードウェアは、フラグメント化なしで (RFC 791 に従って) 68 バイトのパケットを送信する必要があります。または、再構成を伴う (RFC 1122 に従って) 576 バイトのパケットを送信する必要があります。すべての IPv6 ハードウェアは 1280 バイトのパケットをフラグメント化せずに送信する必要があり (RFC 2460 に従って)、IPv6 でパケットをフラグメント化できるのは送信元ノードだけです(!)。

TL、DR; 私はおそらく、IPv4 / IPv6 にそれぞれ 576 / 1280 を期待しています。

(注: IPv4 UDP パケットの場合はマイナス 68 バイト、または IPv6 UDP パケットの場合は 48 バイト)

于 2019-02-04T14:45:04.613 に答える
0

あなたの意図はわかりませんが、この回答では、bbのサイズを取得して、パケットが切り捨てられないようにする必要があると想定します。

MulticastSocket クラスは DatagramSocket を継承しています。また、DatagramSocket には、最大ソケット受信バッファーをバイト単位で返すgetReceiveBufferSize()メソッドがあります。

于 2016-10-13T19:38:26.193 に答える
0

受信できる最大データグラムは、65507 (IPv4) またはソケットの受信バッファー サイズのいずれか小さい方によって制限されます。

MTU は送信できる最大値であり、送信側でのいくつかのプロパティに加えて、上記の 65507 の全体的な制限です。受け取りとは関係ありません。実際には、IP フラグメンテーションのため、576 または 534 またはそのような数値と同じくらい低くなります。

于 2016-10-13T20:24:26.017 に答える