Provided by: manpages-ja_0.5.0.0.20131015+dfsg-2_all 
名前
socket - Linux のソケットインターフェース
書式
#include <sys/socket.h>
sockfd = socket(int socket_family, int socket_type, int protocol);
説明
このマニュアルページは Linux ネットワークのソケット層に対する ユーザインターフェースを記述
するものである。 BSD 互換ソケットは、ユーザプロセスとカーネル内部の ネットワークプロトコル
スタック群との間に、 統一的なインターフェースを提供するものである。 プロトコルモジュールは
プロトコルファミリー (protocol familiy) (例： AF_INET, AF_IPX, AF_PACKET) と ソケットタイ
プ (socket types) (例： SOCK_STREAM, SOCK_DGRAM) に分類できる。 これらに関するより詳しい
情報は socket(2) を参照のこと。
ソケット層の関数群
これらの関数はユーザプロセスがパケットを送受信したり、その他のソケット操作を 行ったりする
ために用いられる。詳細はそれぞれのマニュアルページを 見てほしい。
socket(2) はソケットを生成する。 connect(2) はソケットをリモートのソケットアドレスに接続
する。 bind(2) はソケットをローカルのソケットアドレスにバインドする。 listen(2) はソケッ
トに新しい接続が来たら受信するように伝え、 accept(2) は外部からやってきた接続に対して新し
いソケットを得るために用いられる。 socketpair(2) は互いに接続された二つの名前無しソケット
(anonymous socket) を返す (AF_UNIX のような、いくつかのローカルなファミリーでしか実装され
ていない)。
send(2), sendto(2), sendmsg(2) はソケットを通してデータを送信し、 recv(2) recvfrom(2),
recvmsg(2) はソケットからデータを受信する。 poll(2) と select(2) はデータの到着を待った
り、データ送信の準備ができるまで待ったりする。 さらに、 write(2), writev(2), sendfile(2),
read(2), readv(2) のような標準的な I/O 操作もデータの読み書きに用いることができる。
getsockbyname(2) はローカルのソケットアドレスを返し、 getpeername(2) はリモートのソケット
アドレスを返す。 getsockopt(2) と setsockopt(2) はソケット層のオプションやプロトコルオプ
ションの取得・設定に用いられる。 他のいくつかのオプションの取得・設定には ioctl(2) を使う
ことができる。
close(2) はソケットをクローズする。 shutdown(2) は全二重なソケット接続を部分的にクローズ
する。
シーク動作や、 0 以外の位置に対する pread(2) や pwrite(2) はソケットではサポートされてい
ない。
非ブロッキングな I/O をソケットで行うことは可能で、 fcntl(2) を使ってソケットのファイル
ディスクリプタに O_NONBLOCK フラグをセットすれば良い。 こうするとブロックされる操作は、
(通常) EAGAIN エラーで戻ることになる (後で処理が再試行されることが期待されている)。
connect(2) では EINPROGRESS エラーが返される。 この場合、ユーザはさまざまなイベントを
poll(2) や select(2) を使って待つことができる。
┌────────────────────────────────────────────────────────────────────────┐
│ I/O イベント │
├───────────┬─────────────┬──────────────────────────────────────────────┤
│イベント │ poll フラグ │ 内容 │
├───────────┼─────────────┼──────────────────────────────────────────────┤
│Read │ POLLIN │ 新しいデータが到着した。 │
├───────────┼─────────────┼──────────────────────────────────────────────┤
│Read │ POLLIN │ (接続志向のソケットで) 接続の設定が終了し │
│ │ │ た。 │
├───────────┼─────────────┼──────────────────────────────────────────────┤
│Read │ POLLHUP │ 接続先で切断要求が生成された。 │
├───────────┼─────────────┼──────────────────────────────────────────────┤
│Read │ POLLHUP │ 接続が壊れた (接続志向のプロトコルのみ)。 こ │
│ │ │ の場合、ソケットに書き込みが行われると │
│ │ │ SIGPIPE も送信される。 │
├───────────┼─────────────┼──────────────────────────────────────────────┤
│Write │ POLLOUT │ ソケットには新しいデータを書き込むのに十分な │
│ │ │ バッファがある。 │
├───────────┼─────────────┼──────────────────────────────────────────────┤
│Read/Write │ POLLIN| │ 外部向けの connect(2) が終了した。 │
│ │ POLLOUT │ │
├───────────┼─────────────┼──────────────────────────────────────────────┤
│Read/Write │ POLLERR │ 非同期的 (asynchronous) なエラーが起こった。 │
├───────────┼─────────────┼──────────────────────────────────────────────┤
│Read/Write │ POLLHUP │ 接続先が片方向を切断した。 │
├───────────┼─────────────┼──────────────────────────────────────────────┤
│Exception │ POLLPRI │ 緊急データ (urgent data) が到着した。この場 │
│ │ │ 合は SIGURG が送信される。 │
└───────────┴─────────────┴──────────────────────────────────────────────┘
poll(2) や select(2) を使う代わりに、カーネルからアプリケーションに イベントを通知させる
のに SIGIO シグナルを使う方法もある。 この方法を使うには、 fcntl(2) を用いてソケットの
ファイルディスクリプタに O_ASYNC フラグをセットし、 SIGIO に対する有効なシグナルハンドラを
sigaction(2) によって設定しておく必要がある。 後述の シグナル に関する議論も参考にするこ
と。
ソケットアドレス構造体
各ソケットドメインにはそれぞれ独自のソケットアドレス形式があり、ドメイン固有のアドレス構造
体を持っている。 これらの構造体の先頭には、アドレス構造体の種類を示す整数の "family"
フィールド (型は sa_family_t) がある。 このフィールドにより、 すべてのソケットドメインで汎
用的に使用されるシステムコール (例えば、 connect(2), bind(2), accept(2), getsockname(2),
getpeername(2) など) が、特定のソケットアドレスのドメインを判定することができる。
任意の種類のソケットアドレスをソケット API のインターフェースに渡せるように、 struct
sockaddr 型が定義されている。 この型の目的は、 純粋に、 ドメイン固有のソケットアドレスを
「汎用的な」型にキャストできるようにする点にある。 これにより、 ソケット API 呼び出しにお
いて、 コンパイラが型の不一致の警告を出すのを避けることができる。
これに加えて、ソケット API ではデータ型 struct sockaddr_storage が提供されている。 サポー
トしているすべてのドメイン固有のソケットアドレス構造体を収容するのに、この型を使うことがで
きる。 この型は十分な大きさがあり、(メモリ境界への) アラインも適切に行われている (特に、
IPv6 ソケットアドレスを収容するのにも十分な大きさである)。 この構造体には次のフィールドが
あり、 このフィールドを使って、 この構造体に実際に格納されているソケットアドレスの型を特定
することができる。
sa_family_t ss_family;
sockaddr_storage 構造体は、 ソケットアドレスを汎用的な方法で扱う必要があるプログラム (例え
ば、 IPv4 と IPv6 の両方のソケットアドレスを扱う必要があるプログラム) で有用である。
ソケットオプション
これらのソケットオプションは、 setsockopt(2) を用いれば設定でき、 getsockopt(2) を用いれ
ば取得できる。 但し、どのソケットの場合も ソケットレベルには SOL_SOCKET を指定すること。
注釈がない限り、 optval は int へのポインタである。
SO_ACCEPTCONN
このソケットが listen(2) によって接続待ち受け状態に設定されているかどうかを示す値
を返す。 値 0 は listen 状態のソケットでないことを、 値 1 は listen 状態のソケット
であることを示す。このソケットオプションは読み込み専用である。
SO_BINDTODEVICE
このソケットを、引き数で渡したインターフェース名で指定される (“eth0” のような) 特定
のデバイスにバインドする。 名前が空文字列だったり、オプションの長さ (optlen) が 0
の場合には、 ソケットのバインドが削除される。 渡すオプションは、インターフェース名
が 入ったヌル文字で終端された可変長の文字列である。 文字列の最大のサイズは IFNAMSIX
である。 ソケットがインターフェースにバインドされると、 その特定のインターフェース
から受信されたパケットだけを処理する。 このオプションはいくつかのソケットタイプ、
特に AF_INET に対してのみ動作する点に注意すること。 パケットソケットではサポートさ
れていない (通常の bind(2) を使うこと)。
Linux 3.8 より前のバージョンでは、このソケットオプションは getsockname(2) で設定す
ることはできたが、取得することができなかった。 Linux 3.8 以降では、読み出すことがで
きる。 optlen 引き数には、 デバイス名を格納するのに十分なバッファサイズを渡すべきで
あり、 IFNAMSIZ バイトにすることを推奨する。 実際のデバイス名の長さは optlen 引き数
に格納されて返される。
SO_BROADCAST
ブロードキャストフラグを設定・取得する。有効になっていると、データグラ ムソケットは
ブロードキャストアドレスにパケットを送信できるようになる。 ストリーム指向のソケット
には何の効果もない。
SO_BSDCOMPAT
BSD のバグに対して互換性を取るための機能を有効にする。 この機能は Linux 2.0 と 2.2
の UDP プロトコルモジュールで使用されている。 有効になっていると、 UDP ソケットで受
信された ICMP エラーは ユーザプログラムに渡されない。 これ以降のバージョンのカーネ
ルでは、このオプションのサポートは 段階的に廃止されてきた。 Linux 2.4 ではこのオプ
ションは黙って無視され、 Linux 2.6 ではプログラムがこのオプションを使用すると
(printk() を使って) カーネルの警告メッセージが出力される。 Linux 2.0 では、このオ
プションを指定すると、 raw ソケットにおいても BSD のバグ (ランダムヘッダ変更、 ブ
ロードキャストフラグのスキップ) に対する互換機能が有効になっていた。 しかし、こちら
は Linux 2.2 で削除された。
SO_DEBUG
ソケットのデバッグ機能を有効にする。 CAP_NET_ADMIN 権限を持つプロセスか、実効ユーザ
ID が 0 のプロセスでしか 利用できない。
SO_DOMAIN (Linux 2.6.32 以降)
ソケットドメインを整数で取得する。 AF_INET6 のような値が返される。 詳細は socket(2)
を参照。このソケットオプションは読み込み専用である。
SO_ERROR
保留になっていたソケットエラーを取得してクリアする。 このソケットオプションは読み込
み専用である。整数値をとる。
SO_DONTROUTE
ゲートウェイを経由せず、直接接続されているホストにのみ送信する。 send(2) 操作で
MSG_DONTROUTE フラグをセットした場合も同じ効果が得られる。 ブール整数のフラグを取
る。
SO_KEEPALIVE
接続志向のソケットに対する keep-alive メッセージの送信を有効にする。 ブール値の整数
フラグをとる。
SO_LINGER
SO_LINGER オプションを取得・設定する。引き数には linger 構造体を取る。
struct linger {
int l_onoff; /* linger active */
int l_linger; /* how many seconds to linger for */
};
有効になっていると、 close(2) や shutdown(2) は、そのソケットにキューイングされた
メッセージがすべて送信完了するか、 linger (居残り) タイムアウトになるまで返らな
い。無効になっていると、 これらのコールはただちに戻り、クローズ動作はバックグラウン
ドで行われる。 ソケットのクローズを exit(2) の一部として行った場合には、残っている
ソケットの クローズ動作は必ずバックグラウンドに送られる。
SO_MARK (Linux 2.6.25 以降)
このソケットから送信される各パケットにマークをセットする (netfilter の MARK ター
ゲットと似ているが、ソケット単位である点が異なる)。 マークの変更は、 netfilter なし
でのマークに基づいてのルーティングや、 パケットフィルタリングに使うことができる。
このオプションを変更するには CAP_NET_ADMIN ケーパビリティが必要である。
SO_OOBINLINE
このオプションを有効にすると、帯域外データ (out-of-band data) は 受信データストリー
ム中に置かれる。有効にしなければ、 帯域外データは受信時に MSG_OOB フラグがセットさ
れている場合に限って渡される。
SO_PASSCRED
SCM_CREDENTIALS 制御メッセージの受信を有効/無効にする。詳細は unix(7) を参照のこ
と。
SO_PEEK_OFF (Linux 3.4 以降)
MSG_PEEK フラグと一緒に使用された場合 recv(2) システムコールの "peek offset" にこの
オプションの値が設定される。現在のところ、このオプションは unix(7) ソケットでのみサ
ポートされている。
このオプションが負の値に設定された場合、従来の動作となる。 つまり MSG_PEEK フラグが
指定された recv(2) は、キューの先頭のデータに対して peek 処理を行う (データを読み出
すが、キューからデータの削除を行わない)。 新規のソケットではこのオプションの値は必
ず -1 に設定される。
このオプションに 0 以上の値が設定されると、 そのソケットのキュー上のオプション値で
指定されたバイトオフセットにあるデータが次の peek 処理で返される。 同時に、 "peek
offset" がキューから peek 処理されたバイト数だけ加算される。したがって、次の peek
処理ではキューのその次にあるデータが返される。
recv(2) (や同様のシステムコール) の MSG_PEEK フラグなしの呼び出しでキューの先頭の
データが削除された場合、 "peek offset" は削除されたバイト数だけ減算される。 言い換
えると、 MSG_PEEK フラグなしでデータを受信すると、 "peek offset" が指すキュー内の相
対的な位置が狂わないように調整され、この後の peek では、 データ削除が行われなかった
場合に返されたのと同じ値が返されるということである。
データグラムソケットでは、 "peek offset" がパケットの途中を指している場合には、 返
されるデータには MSG_TRUNC フラグが付与される。
以下の例は SO_PEEK_OFF の利用例を示している。ストリームソケットのキューに以下の入力
データが入っているものとする。
aabbccddeeff
以下の順序で recv(2) の呼び出しを行うと、コメントに書かれた結果となる。
int ov = 4; // Set peek offset to 4
setsockopt(fd, SOL_SOCKET, SO_PEEK_OFF, &ov, sizeof(ov));
recv(fd, buf, 2, MSG_PEEK); // Peeks "cc"; offset set to 6
recv(fd, buf, 2, MSG_PEEK); // Peeks "dd"; offset set to 8
recv(fd, buf, 2, 0); // Reads "aa"; offset set to 6
recv(fd, buf, 2, MSG_PEEK); // Peeks "ee"; offset set to 8
SO_PEERCRED
このソケットに接続してきた外部プロセスの信任状 (credential) を返す。このソケットオ
プションが利用できるのは、接続された AF_UNIX ストリームソケット間、および
socketpair(2) を使って作成された AF_UNIX のストリームソケットとデータグラムソケット
のペアだけである。 unix(7) を参照のこと。 connect(2) や socketpair(2) が呼ばれた時
に有効であった信任状が返される。引き数は ucred 構造体である。このソケットオプション
は読み込み専用である。
SO_PRIORITY
プロトコルで定義された優先度を、このソケットから 送信される全てのパケットにセットす
る。 Linux はネットワークキュー内部の 整列にこの値を用いる。高い優先度を持っている
パケットは先に処理される。 ただしそのデバイスのキュー処理のやり方に依存する。 ip(7)
では、外向けパケットの IP type-of-service (TOS) フィールドにもこの値が設定される。
0 から 6 以外の優先度をセットするには CAP_NET_ADMIN ケーパビリティが必要である。
SO_PROTOCOL (Linux 2.6.32 以降)
ソケットのプロトコルを整数で取得する。 IPPROTO_SCTP のような値が返される。 詳細は
socket(2) を参照。このソケットオプションは読み込み専用である。
SO_RCVBUF
ソケットの受信バッファの最大サイズを設定・取得する (バイト単位)。 setsockopt(2) を
使って値が設定されたときに (管理オーバヘッド用の領域を確保するために) カーネルはこ
の値を 2倍し、 getsockopt(2) はこの 2倍された値を返す。 デフォルトの値は
/proc/sys/net/core/rmem_default ファイルで設定され、許容される最大の値は
/proc/sys/net/core/rmem_max ファイルで設定される。 このオプションの最小値は (2倍し
た値で) 256 である。
SO_RCVBUFFORCE (Linux 2.6.14 以降)
このソケットオプションを使うと、特権プロセス (CAP_NET_ADMIN を持つプロセス) は
SO_RCVBUF と同じことを実行できる。 ただし、上限 rmem_max を上書きすることができる。
SO_RCVLOWAT と SO_SNDLOWAT
バッファ中に溜めることのできるデータの最小値を指定する。 このサイズを越えると、ソ
ケット層はそのデータをプロトコルに渡し (SO_SNDLOWAT)、 受信時にはユーザに渡す
(SO_RCVLOWAT)。 これら二つの値は 1 に初期化される。 SO_SNDLOWAT は Linux では変更で
きない (setsockopt(2) は ENOPROTOOPT エラーで失敗する)。 SO_RCVLOWAT は Linux 2.4
以降でのみ変更可能である。 現状、Linux ではシステムコール select(2) と poll(2) は
SO_RCVLOWAT の設定を考慮に入れずに動作し、 データが1バイト利用可能になっただけで
も、 ソケットは読み出し可能とのマークをつける。 一方、それに続けて行うソケットから
の read は SO_RCVLOWAT バイトのデータが利用可能になるまで停止してしまう。
SO_RCVTIMEO と SO_SNDTIMEO
送信・受信のタイムアウトを指定する。これを越えるとエラーを報告する。 引き数は
struct timeval である。 入出力関数がタイムアウト時間の間ブロックされ、かつデータの
送信または 受信が行われていた場合は、転送されたデータ量が関数の返り値となる。 何も
データが転送されずにタイムアウトに達した場合は、 -1 を返し、 errno に EAGAIN か
EWOULDBLOCK か EINPROGRESS (connect(2) の場合) が設定され、 あたかもソケットに非ブ
ロッキングが指定されたように見える。 タイムアウト値に (デフォルト値である) 0 に設定
すると、 操作は決してタイムアウトしなくなる。 タイムアウトが影響を及ぼすのは、 ソ
ケット I/O を実行するシステムコールだけ (例えば read(2), recvmsg(2), send(2),
sendmsg(2)) である。 select(2), poll(2), epoll_wait(2) などにはタイムアウトは影響
を及ぼさない。
SO_REUSEADDR
bind(2) コールに与えられたアドレスが正しいかを判断するルールで、 ローカルアドレス
の再利用を可能にする。 つまり AF_INET ソケットなら、そのアドレスにバインドされたア
クティブな listen 状態のソケットが存在しない限り、バインドが行える。 listen 状態の
ソケットがアドレス INADDR_ANY で特定のポートにバインドされている場合には、 このポー
トに対しては、どんなローカルアドレスでもバインドできない。 引き数はブール整数のフラ
グである。
SO_SNDBUF
ソケットの送信バッファの最大サイズを設定・取得する (バイト単位)。 setsockopt(2) を
使って値が設定されたときに (管理オーバヘッド用の領域を確保するために) カーネルはこ
の値を 2倍し、 getsockopt(2) はこの 2倍された値を返す。 デフォルトの値は
/proc/sys/net/core/wmem_default ファイルで設定され、許容される最大の値は
/proc/sys/net/core/wmem_max ファイルで設定される。 このオプションの最小値は (2倍し
た値で) 2048 である。
SO_SNDBUFFORCE (Linux 2.6.14 以降)
このソケットオプションを使うと、特権プロセス (CAP_NET_ADMIN を持つプロセス) は
SO_SNDBUF と同じことを実行できる。 ただし、上限 wmem_max を上書きすることができる。
SO_TIMESTAMP
SO_TIMESTAMP 制御メッセージの受信を有効/無効にする。 タイムスタンプ制御メッセージは
レベル SOL_SOCKET で送信され、 cmsg_data フィールドはこのシステムコールでユーザに渡
した 最後のパケットの受信時刻を示す struct timeval である。 制御メッセージの詳細に
ついては cmsg(3) を参照。
SO_TYPE
ソケットのタイプを整数で取得する (例: SOCK_STREAM)。 このソケットオプションは読み出
し専用である。
シグナル
(ローカルもしくはリモート側で) 切断された 接続指向 (connection-oriented) のソケットに対し
て 書き込みを行うと、その書き込みを行ったプロセスに SIGPIPE が送られ、 EPIPE が返される。
write 呼び出しに MSG_NOSIGNAL フラグを指定していた場合はシグナルは送られない。
FIOSETOWN fcntl(2) や SIOCSPGRP ioctl(2) をプロセスまたはプロセスグループに指定しておく
と、 I/O イベントが起きたときに SIGIO が送られる。 poll(2) や select(2) をシグナルハンド
ラ内で用いれば、どのソケットでイベントが起こったかを 知ることができる。 (Linux 2.2 におけ
る) 別の方法としては、 F_SETSIG fcntl(2) を用いてリアルタイムシグナルを設定するやり方もあ
る。 リアルタイムシグナルのハンドラは、 siginfo_t の si_fd フィールドにファイルディスクリ
プタが入った状態で呼び出される。 詳細は fcntl(2) を参照のこと。
状況によっては (例えば複数のプロセスが一つのソケットにアクセスしているなど)、 SIGIO の原因
となった状態は、プロセスがそのシグナルへの対応を行ったときには 消えてしまっているかもしれ
ない。 この場合は、プロセスは再び待つようにすべきである。 Linux は同じシグナルを後で再送す
るからである。
/proc インタフェース
core のソケットのネットワーキングパラメータには、 /proc/sys/net/core/ ディレクトリ内のファ
イルを通してアクセスできる。
rmem_default
ソケットの受信バッファサイズのデフォルト値 (バイト単位)。
rmem_max
SO_RCVBUF ソケットオプションを用いてユーザが設定できる ソケットの受信バッファサイズ
の最大値 (バイト単位)。
wmem_default
ソケットの送信バッファサイズのデフォルト値 (バイト単位)。
wmem_max
SO_SNDBUF ソケットオプションを用いてユーザが設定できる ソケットの送信バッファサイズ
の最大値 (バイト単位)。
message_cost と message_burst
トークン・バケット・フィルターを設定する。 これは外部のネットワークイベントによって
引き起こされた 負荷限界の警告メッセージに用いられる。
netdev_max_backlog
グローバルな入力キューにおける最大のパケット数。
optmem_max
ソケットあたりの、補助データ (ancillary data) とユーザ制御データ (iovecs のようなも
の) との和の最大長。
ioctl
以下に示す操作には ioctl(2) を用いてアクセスできる。
error = ioctl(ip_socket, ioctl_type, &value_result);
SIOCGSTAMP
最後にユーザに渡されたパケットの受信タイムスタンプを struct timeval に入れて返す。
これは round trip 時間を正確に測りたいときに便利である。 struct timeval の説明は
setitimer(2) を見てほしい。 この ioctl は、ソケットオプション SO_TIMESTAMP がソ
ケットにセットされていない場合にのみ使用すべきである。 さもなければ、この ioctl は
SO_TIMESTAMP がセットされていなかった間に受信した最後のパケットの時刻を返すか、 そ
のようなパケットを受信していない場合には失敗する (つまり、 ioctl(2) は -1 を返し、
errno に ENOENT をセットする)。
SIOCSPGRP
非同期 I/O 操作の終了時や緊急データの受信時に SIGIO や SIGURG シグナル群を送るプロ
セスやプロセスグループを設定する。 引き数は pid_t へのポインタである。 引き数が正だ
と、そのプロセスにシグナルが送られる。負だと、 引き数の絶対値を ID に持つプロセスグ
ループにシグナルが送られる。 シグナル受信先には、自分自身のプロセス / 自分の所属す
るプロセスグループ しか指定できない。但し、 CAP_KILL ケーパビリティを持っている場
合、及び実効ユーザ ID が 0 のプロセスの場合は この限りではない。
FIOASYNC
O_ASYNC フラグを変更し、ソケットの非同期 (asynchronous) I/O モードを 有効/無効にす
る。非同期 I/O モードでは、 新しい I/O イベントが起きたときに、 SIGIO シグナルや
F_SETSIG で設定されたシグナル・セットが発行される。
引き数はブール整数のフラグである。 (この操作は fcntl(2) を使って O_ASYNC フラグを
セットするのと同じ意味である。)
SIOCGPGRP
SIGIO や SIGURG を受信したカレントプロセス・プロセスグループを取得する。 ない場合は
0 が返る。
有効な fcntl(2) 操作:
FIOGETOWN
SIOCGPGRP ioctl(2) と同じ。
FIOSETOWN
SIOCSPGRP ioctl(2) と同じ。
バージョン
SO_BINDTODEVICE は Linux 2.0.30 で導入された。 SO_PASSCRED は Linux 2.2 で登場した。 /proc
インタフェースは Linux 2.2 で導入された。 SO_RCVTIMEO と SO_SNDTIMEO は Linux 2.3.41 以降
でサポートされている。 それ以前は、タイムアウトはプロトコル固有の固定の設定値で、 読み書き
をすることはできなかった。
注意
Linux は、送受信バッファの半分を内部のカーネル構造体で用いると仮定している。 したがっ
て、対応する /proc ファイルはネットワーク回線上での大きさの 2 倍になる。
Linux では、 SO_REUSEADDR オプションでポートの再利用が許可されるのは、 そのポートに対して
bind(2) を前に実行したプログラムとそのポートを再利用 しようとするプログラムの両方で
SO_REUSEADDR がセットされた場合のみである。 この動作は (FreeBSD などの) いくつかの実装とは
異なる。これらでは、 後でポートを再利用しようとするプログラムで SO_REUSEADDR オプションを
セットするだけでよい。 たいていはこの違いは見えない。なぜなら、例えばサーバプログラムは 常
にこのオプションをセットするように設計されるからである。
バグ
CONFIG_FILTER ソケットオプションである SO_ATTACH_FILTER と SO_DETACH_FILTER について記載さ
れていない。これらは libpcap ライブラリを通して 用いる方が良い。
関連項目
getsockopt(2), connect(2), setsockopt(2), socket(2), capabilities(7), ddp(7), ip(7),
packet(7), tcp(7), udp(7), unix(7)
この文書について
この man ページは Linux man-pages プロジェクトのリリース 3.54 の一部 である。プロジェクト
の説明とバグ報告に関する情報は http://www.kernel.org/doc/man-pages/ に書かれている。