名前

networking − ネットワーク機能

形式

#include <sys/socket.h>
#include <net/route.h>
#include <net/if.h>

解説

ここでは、システムが用意しているネットワーク機構について 要約して述べます。 (4) 節でのこれらに関連する記述は、 プロトコルファミリー(ドメイン)、プロトコル、ネットワークインタフェース の 3 つに分かれています。 プロトコルファミリーのエントリは “4F” で記され、 プロトコルのエントリは “4P” です。また、ネットワーク インタフェースに関するハードウェアサポートは、 “4” のエントリになっています。

すべてのネットワークプロトコルは、 特定のプロトコルファミリーと関連しています。 プロトコルファミリーは、特定のネットワーク環境内でプロトコルの 機能を実現するための基本サービスを提供します。 サービスは、パケットの断片化と再組立、ルーティング、アドレッシング、 基本転送機能などを含みます。 プロトコルファミリーは複数のアドレス指定方法をサポートすることも可能ですが、 現在はまだ実現していません。 プロトコルファミリーは、通常、 socket(2) の型ごとに 1 プロトコルを持ち、いくつものプロトコルから構成されますが、 すべての型のソケットをサポートしているわけではありません。 また、1 つのプロトコルファミリーが、 同じソケット機能をサポートする複数のプロトコルを含む場合もあります。

プロトコルは、 socket(2) で詳細を指定された、ソケット機能の 1 つをサポートします。 特定のプロトコルは、適切な型とプロトコルファミリーのソケットを作るか、 またはソケットを作るときにプロトコルを明示的に指定することによって、 アクセスできます。 プロトコルは、通常、1 つの型のアドレス形式のみを受け付けます。 この形式は、プロトコルファミリー/ネットワークアーキテクチャに固有の アドレス構造によって決まります。 基本的なソケット機能の意味は、 プロトコルによって異なります。 すべてのプロトコルは、 個々のソケットの型について基本的なモデルをサポートすることが 期待されていますが、 さらに、標準以外の機能や拡張機能が付け加えられているものもあります。 たとえば、SOCK_STREAM をサポートするプロトコルは、 2 バイト以上の out-of-band データを 1 つの out-of-band メッセージとして 転送することができます。

ネットワークインタフェースは、デバイスインタフェースと似ています。 ネットワークインタフェースは、ネットワークサブシステムの最下位層で、 実際に通信を行うハードウェアをコントロールします。 インタフェースは、1 つ以上のプロトコルファミリーおよび (あるいは)アドレス形式をサポートします。 マニュアルの各ネットワークインタフェースの”形式”の項目では、 config(8) プログラムに対するシステム記述で用いるための関連ドライバの指定例 を示しています。 また、”診断”の項目では、デバイス操作時のエラーに応じて、 コンソール上および(あるいは)システムエラーログ (/usr/adm/messages (syslogd(8) 参照))に出力されるメッセージを記述してます。

プロトコル

システムは、現在、DARPA インターネットプロトコル と Xerox Network Systems(tm) プロトコルをサポートしています。 DARPA インターネットの IP プロトコルレイヤと IMP リンクレイヤ(1822)、 Xerox NS の IDP プロトコルレイヤへの RAW ソケットインタフェースが 用意されています。 各プロトコルファミリーについてのより詳しい情報は、 この章のマニュアルでの該当ページを参照してください。

アドレス指定

各プロトコルファミリーは、1 つのアドレス形式を持っています。 次に示すアドレス形式が、システムで使用できるものです (将来サポートされるかもれしれないものに関して、 追加した形式も定義されています)。

#define AF_UNIX1/∗ ローカルからホストへ(パイプ、ポータル) ∗/
#define AF_INET2/∗ インターネットワーク UDP、TCP ∗/
#define AF_IMPLINK3/∗ arpanet imp  アドレス ∗/
#define AF_PUP4/∗ PUP プロトコル  例：BSP プロトコル ∗/
#define AF_NS5/∗ Xerox NS プロトコル ∗/
#define AF_HYLINK15/∗ NSC ハイパーチャネル ∗/

ルーティング

ネットワーク機構では、パケットのルーティングを部分的にサポートしています。 “ルーティングテーブル” は単純なデータ構造体の集合で、 パケットの転送時にネットワークインタフェースを選択するのに使われます。 このテーブルは、特定のネットワークやホストへの経路に対応した エントリから成っています。 ルーティングデーモンのようなユーザプロセスが、 2 つのソケット固有の ioctl(2) コマンド、SIOCADDRT、SIOCDELRT によって、 このデータベースを更新していきます。 このコマンドはそれぞれ、各ルーティングテーブルのエントリを 1 つずつ 追加したり削除したりするものです。 ルーティングテーブルは、スーパユーザによってのみ扱われます。

ルーティングテーブルのエントリは、 <net/route.h> で定義してあるように、次の形式になっています。

structrtentry {
u_longrt_hash;
structsockaddr rt_dst;
structsockaddr rt_gateway;
shortrt_flags;
shortrt_refcnt;
u_longrt_use;
structifnet ∗rt_ifp;
};

rt_flags の定義

#define  RTF_UP0x1/∗ 使用可能経路 ∗/
#define  RTF_GATEWAY0x2/∗ 相手はゲートウェイ ∗/
#define  RTF_HOST0x4/∗ ホストエントリ(さもなくばネットワーク) ∗/
#define  RTF_DYNAMIC0x10/∗ 動的に作成された (リダイレクトによる) ∗/

ルーティングテーブルのエントリは、3 種類に分かれています。 それは、特定のホスト用のもの、 特定のネットワーク上のすべてのホスト用のもの、 それ以外の相手先(ワイルドカード経路)用のものです。 システムがブートされ、アドレスがネットワークインタフェースに 割り当てられると、各プロトコルファミリーは、 通信が可能になった各インタフェース用のルーティングテーブルエントリ を設定します。 通常、プロトコルは、相手側のホストやネットワークへ “direct” 接続するように、通過するネットワークインタフェースの 経路を指定します。 経路が direct であれば、そのプロトコルファミリーの トランスポートレイヤが、パケットをそのパケットに指定されたホストへ 送るようリクエストします。 これ以外の場合、インタフェースは、ルーティングエントリに 登録されているゲートウェイへパケットを送るようリクエストされます (パケットは、Gateway からさらにどこかに送られます)。

ユーザプロセスが設定するルーティングテーブルエントリには、 ハッシュ、リファレンスカウント、 使用中フラグやインタフェースフィールドを指定してはいけません。 これらは、(カーネルの)ルーティングルーチンによって書き込まれます。 使用中の経路 (rt_refcnt が 0 でない)を削除しようとすると、ルーティングエントリは down とマークされ、 ルーティングテーブルから削除されます。 しかし、その経路が使用してリソースは、 すべての参照から解放されるまでは、そのまま残されます。 ルーティングのプログラムは、 存在するエントリの複製が要求されると EEXIST を、 存在しないエントリの削除を要求されると ESRCH を、また新経路を 設定するのに充分なリソースがないと ENOBUFS を返します。 ユーザプロセスは、 /dev/kmem デバイスを通してルーティングテーブルを読みます。 rt_use フィールドには、その経路を通して送られたパケットの数が含まれてます。

パケットをルーティングする時、カーネルは最初に相手側ホストへ の経路を探します。 これに失敗すると、相手側ネットワークへの経路を探します。 最後に、デフォルト(“ワイルドカード”)のゲートウェイへの経路が選ばれます。 複数の経路がテーブルに載っていれば、 最初に見つかった経路が使用されます。 エントリが見つからなければ、相手側への到達が不可能であることが知らされます。

ワイルドカードのルーティングエントリは、相手側アドレスが 0 で指定されます。 ワイルドカード経路は、システムが相手側ホスト および相手側ネットワークへの経路を見つけることができない時に 使用されます。 ワイルドカードの経路と中継点で経路を再び探すこと (routing redirects)の組み合わせによって、 経路付けのメカニズムが簡素になっています。

インタフェース

システム中の各ネットワークインタフェースは、 メッセージを送受信できるパスと対応しています。 ネットワークインタフェースは、通常、 ハードウェアデバイスと結び付けられています。 しかし、ループバックインタフェース (lo(4)) のようなインタフェースは例外です。

次の ioctl コールは、ネットワークインタフェースを操作するために使用されます。 ioctl は、指定されるドメインでソケット(代表的には SOCK_DGRAM 型)に対して使用します。 特に指定されない場合、この要求はパラメータとして ifrequest 構造体を使います。

structifreq {
charifr_name[16];/∗ インタフェース名(例：ec0) ∗/
union {
structsockadder ifru_addr;
structsockadder ifru_dstaddr;
structsockadder ifru_broadaddr;
shortifru_flags;
intifru_metric;
} ifr_ifru;
#defineifr_addrifr_ifru.ifru_addr/∗ アドレス ∗/
#defineifr_dstaddrifr_ifru.ifru_dstaddr/∗ 2 点間リンクの相手局 ∗/
#defineifr_broadaddrifr_ifru.ifru_broadaddr/∗ ブローロードキャストアドレス ∗/
#define ifr_flagsifr_ifru.ifru_flags/∗ フラグ ∗/
#defineifr_metricifr_ifru.ifru_metric/∗ ルーティングメトリック ∗/
 };

SIOCSIFADDR
プロトコルファミリーのインタフェースアドレスを設定します。 アドレス割り当てに従って、 インタフェースの “初期化” ルーチンが呼び出されます。

SIOCGIFADDR
プロトコルファミリーのインタフェースアドレスを取り出します。

SIOCSIFDSTADDR
プロトコルファミリーとインタフェースの 2 点間アドレスを設定します。

SIOCGIFDSTADDR
プロトコルファミリーとインタフェースについての 2 点間アドレスを取り出します。

SIOCGIFBRDADDR
プロトコルファミリーとインタフェースのブロードキャストアドレスを設定します。

SIOCGIFBRDADDR
プロトコルファミリーとインタフェースについてのブロードキャストアドレス を取り出します。

SIOCSIFFLAGS
インタフェースフラグのフィールドを設定します。 そのインタフェースが down とマークされると、 現在そのインタフェースを通じてパケットをルーティングしている すべてのプロセスに知らされます。 この時、リセットされるインタフェースもありますが、 その結果、パケットは受け取れなくなります。 また、再度 up とマークされると、インタフェースは、再び初期化されます。

SIOCGIFFLAGS
インタフェースフラグを取り出します。

SIOCSIFMETRIC
インタフェース経路指定メトリックを設定します。メトリック は、ユーザレベルのルータプログラムによって使用されます。

SIOCGIFMETRIC
インタフェースメトリックを取り出します。

SIOCGIFCONF
インタフェース構成リストを取り出します。この要求は、結果として ifconf (以下参照)構造体を受け取ります。 ifc_len フィールドには、 ifc_buf で指し示されるバッファのサイズが初期設定されていなければなりません。 リターン時には、 ifc_len フィールドはバイト単位での構成リストの長さを持っています。

/∗
 ∗ SIOCGIFCONF リクエストで使用される構造体。
 ∗ マシンのインタフェース構成を得るために使われる。
 ∗ (アクセス可能なすべてのネットワークを知る必要がある
 ∗ プログラムに有用です)。
 ∗/
structifconf {
intifc_len;/∗ 関連するバッファのサイズ ∗/
union  {
caddr_t ifcu_buf;
struct  ifrec ∗ifcu_req;
} ifc_ifcu;
#define ifc_buf ifc_ifcu.ifcu_buf /∗ バッファアドレス ∗/
#define ifc_req ifc_ifcu.ifcu_req /∗ 返される構造体の配列 ∗/
};

関連事項

socket(2), ioctl(2), intro(4), config(8), routed(8C)

NEWS-OSRelease 3.3