6

なぜsockaddr_storageが128バイトだったのか疑問に思っていました。IPv6の場合は少なくとも28バイトである必要があることは理解していますが、sockaddr_in6よりも100バイト大きくするには、これは少し過剰に思えます。これは、ストレージ構造体を将来にわたって保証するためだけのものですか、それとも今すぐ必要になる理由がありますか?

4

2 に答える 2

6

あなたはrfc2553の§3.10とこのSO投稿であなたの質問への答えを見つけるでしょう。

その理由は、少なくともip6と他のプロトコルのデータを保持し、効率を上げるために64ビットで調整する必要があるという組み合わせです。

RFCの関連部分から:

アプリケーション作成者を支援できるソケットAPIへの簡単な追加の1つ
は、「structsockaddr_storage」です。このデータ構造により
、複数のアドレスファミリおよび
プラットフォーム間で移植可能なコードの記述が簡素化されます。このデータ構造は、次の目標を持って設計されています。

  - It has a large enough implementation specific maximum size to
    store the desired set of protocol specific socket address data
    structures. Specifically, it is at least large enough to
    accommodate sockaddr_in and sockaddr_in6 and possibly other
    protocol specific socket addresses too.
  - It is aligned at an appropriate boundary so protocol specific
    socket address data structure pointers can be cast to it and
    access their fields without alignment problems. (e.g. pointers
    to sockaddr_in6 and/or sockaddr_in can be cast to it and access
    fields without alignment problems).
  - It has the initial field(s) isomorphic to the fields of the
    "struct sockaddr" data structure on that implementation which
    can be used as a discriminants for deriving the protocol in use.
    These initial field(s) would on most implementations either be a
    single field of type "sa_family_t" (isomorphic to sa_family
    field, 16 bits) or two fields of type uint8_t and sa_family_t
    respectively, (isomorphic to sa_len and sa_family_t, 8 bits
    each).
于 2013-02-25T20:27:24.780 に答える
3

struct sockaddr_unこの構造にも適合できるようにしたいシステムがあるかもしれません。後者のパス長は、システムに依存して約100〜110文字です。そして128は美しく偶数です。

于 2013-02-25T20:26:22.207 に答える