.\" The following are not yet documented:
.\" SO_PEERNAME (2.4?)
.\" get only
-.\" Seems to do something similar to getpeernam(), but then
+.\" Seems to do something similar to getpeername(), but then
.\" why is it necessary / how does it differ?
.\" SO_TIMESTAMPNS (2.6.22)
.\" Documentation/networking/timestamping.txt
.\" Documentation/networking/timestamping.txt
.\" commit cb9eff097831007afb30d64373f29d99825d0068
.\" Author: Patrick Ohly <patrick.ohly@intel.com>
-.\" SO_RXQ_OVFL (2.6.33)
-.\" commit 3b885787ea4112eaa80945999ea0901bf742707f
-.\" Author: Neil Horman <nhorman@tuxdriver.com>
.\" SO_WIFI_STATUS (3.3)
.\" commit 6e3e939f3b1bf8534b32ad09ff199d88800835a0
.\" Author: Johannes Berg <johannes.berg@intel.com>
.\" Also: SCM_WIFI_STATUS
-.\" SO_PEEK_OFF (3.4)
-.\" commit ef64a54f6e558155b4f149bb10666b9e914b6c54
-.\" Author: Pavel Emelyanov <xemul@parallels.com>
.\" SO_NOFCS (3.4)
.\" commit 3bdc0eba0b8b47797f4a76e377dd8360f317450f
.\" Author: Ben Greear <greearb@candelatech.com>
+.\" SO_GET_FILTER (3.8)
+.\" commit a8fc92778080c845eaadc369a0ecf5699a03bef0
+.\" Author: Pavel Emelyanov <xemul@parallels.com>
+.\" SO_REUSEPORT (3.9)
+.\" commit c617f398edd4db2b8567a28e899a88f8f574798d
+.\" https://lwn.net/Articles/542629/
+.\" SO_LOCK_FILTER (3.9)
+.\" commit d59577b6ffd313d0ab3be39cb1ab47e29bdc9182
+.\" Author: Vincent Bernat <bernat@luffy.cx>
+.\" SO_SELECT_ERR_QUEUE (3.10)
+.\" commit 7d4c04fc170087119727119074e72445f2bb192b
+.\" Author: Keller, Jacob E <jacob.e.keller@intel.com>
+.\" SO_MAX_PACING_RATE (3.13)
+.\" commit 62748f32d501f5d3712a7c372bbb92abc7c62bc7
.\"
.\"*******************************************************************
.\"
.\" This file was generated with po4a. Translate the source file.
.\"
.\"*******************************************************************
-.TH SOCKET 7 2013\-03\-15 Linux "Linux Programmer's Manual"
+.\"
+.\" Japanese Version Copyright (c) 1999 NAKANO Takeo all rights reserved.
+.\" Translated 1999-12-06, NAKANO Takeo <nakano@apm.seikei.ac.jp>
+.\" Updated 2003-01-20, Akihiro Motoki <amotoki@dd.iij4u.or.jp>
+.\" Updated 2005-02-23, Akihiro MOTOKI
+.\" Updated 2005-10-05, Akihiro MOTOKI
+.\" Updated 2005-12-05, Akihiro MOTOKI, Catch up to LDP man-pages 2.16
+.\" Updated 2005-12-26, Akihiro MOTOKI, Catch up to LDP man-pages 2.18
+.\" Updated 2006-04-15, Akihiro MOTOKI, Catch up to LDP man-pages 2.29
+.\" Updated 2007-01-05, Akihiro MOTOKI, Catch up to LDP man-pages 2.43
+.\" Updated 2013-05-01, Akihiro MOTOKI <amotoki@gmail.com>
+.\" Updated 2013-05-06, Akihiro MOTOKI <amotoki@gmail.com>
+.\" Updated 2013-07-24, Akihiro MOTOKI <amotoki@gmail.com>
+.\"
+.TH SOCKET 7 2014\-02\-21 Linux "Linux Programmer's Manual"
.SH 名前
socket \- Linux のソケットインターフェース
.SH 書式
も送信される。
T}
Write:POLLOUT:T{
-ã\82½ã\82±ã\83\83ã\83\88ã\81«ã\81¯æ\96°ã\81\97ã\81\84ã\83\87ã\83¼ã\82¿ã\82\92æ\9b¸ã\81\8dè¾¼ã\82\80ã\81®ã\81«å\85\85å\88\86ã\81ªã\83\90ã\83\83ã\83\95ã\82¡é \98å\9f\9fがある。
+ã\82½ã\82±ã\83\83ã\83\88ã\81«ã\81¯æ\96°ã\81\97ã\81\84ã\83\87ã\83¼ã\82¿ã\82\92æ\9b¸ã\81\8dè¾¼ã\82\80ã\81®ã\81«å\8d\81å\88\86ã\81ªã\83\90ã\83\83ã\83\95ã\82¡がある。
T}
Read/Write:T{
POLLIN|
シグナルを使う方法もある。 この方法を使うには、 \fBfcntl\fP(2) を用いてソケットのファイルディスクリプタに \fBO_ASYNC\fP
フラグをセットし、 \fBSIGIO\fP に対する有効なシグナルハンドラを \fBsigaction\fP(2) によって設定しておく必要がある。 後述の
\fIシグナル\fP に関する議論も参考にすること。
-.SS "Socket address structures"
-Each socket domain has its own format for socket addresses, with a
-domain\-specific address structure. Each of these structures begins with an
-integer "family" field (typed as \fIsa_family_t\fP) that indicates the type of
-the address structure. This allows the various system calls (e.g.,
-\fBconnect\fP(2), \fBbind\fP(2), \fBaccept\fP(2), \fBgetsockname\fP(2),
-\fBgetpeername\fP(2)), which are generic to all socket domains, to determine
-the domain of a particular socket address.
+.SS ソケットアドレス構造体
+各ソケットドメインにはそれぞれ独自のソケットアドレス形式があり、ドメイン固有のアドレス構造体を持っている。
+これらの構造体の先頭には、アドレス構造体の種類を示す整数の "family" フィールド (型は \fIsa_family_t\fP) がある。
+このフィールドにより、 すべてのソケットドメインで汎用的に使用されるシステムコール (例えば、 \fBconnect\fP(2), \fBbind\fP(2),
+\fBaccept\fP(2), \fBgetsockname\fP(2), \fBgetpeername\fP(2) など)
+が、特定のソケットアドレスのドメインを判定することができる。
-To allow any type of socket address to be passed to interfaces in the
-sockets API, the type \fIstruct sockaddr\fP is defined. The purpose of this
-type is purely to allow casting of domain\-specific socket address types to a
-"generic" type, so as to avoid compiler warnings about type mismatches in
-calls to the sockets API.
+任意の種類のソケットアドレスをソケット API のインターフェースに渡せるように、 \fIstruct sockaddr\fP 型が定義されている。
+この型の目的は、 純粋に、 ドメイン固有のソケットアドレスを 「汎用的な」型にキャストできるようにする点にある。 これにより、 ソケット API
+呼び出しにおいて、 コンパイラが型の不一致の警告を出すのを避けることができる。
-In addition, the sockets API provides the data type \fIstruct
-sockaddr_storage\fP. This type is suitable to accommodate all supported
-domain\-specific socket address structures; it is large enough and is aligned
-properly. (In particular, it is large enough to hold IPv6 socket
-addresses.) The structure includes the following field, which can be used
-to identify the type of socket address actually stored in the structure:
+これに加えて、ソケット API ではデータ型 \fIstruct sockaddr_storage\fP が提供されている。
+サポートしているすべてのドメイン固有のソケットアドレス構造体を収容するのに、この型を使うことができる。 この型は十分な大きさがあり、(メモリ境界への)
+アラインも適切に行われている (特に、 IPv6 ソケットアドレスを収容するのにも十分な大きさである)。 この構造体には次のフィールドがあり、
+このフィールドを使って、 この構造体に実際に格納されているソケットアドレスの型を特定することができる。
.in +4n
.nf
.fi
.in
-The \fIsockaddr_storage\fP structure is useful in programs that must handle
-socket addresses in a generic way (e.g., programs that must deal with both
-IPv4 and IPv6 socket addresses).
+\fIsockaddr_storage\fP 構造体は、 ソケットアドレスを汎用的な方法で扱う必要があるプログラム (例えば、 IPv4 と IPv6
+の両方のソケットアドレスを扱う必要があるプログラム) で有用である。
.SS ソケットオプション
.\" FIXME
.\" In the list below, the text used to describe argument types
.\" SO_ACCEPTCONN is in POSIX.1-2001, and its origin is explained in
.\" W R Stevens, UNPv1
これらのソケットオプションは、 \fBsetsockopt\fP(2) を用いれば設定でき、 \fBgetsockopt\fP(2) を用いれば取得できる。
-但し、どのソケットの場合も ソケットレベルには \fBSOL_SOCKET\fP を指定すること。
+但し、どのソケットの場合も ソケットレベルには \fBSOL_SOCKET\fP を指定すること。 注釈がない限り、 \fIoptval\fP は \fIint\fP
+へのポインタである。
.TP
\fBSO_ACCEPTCONN\fP
このソケットが \fBlisten\fP(2) によって接続待ち受け状態に設定されているかどうかを示す値を返す。 値 0 は listen
状態のソケットでないことを、 値 1 は listen 状態のソケットであることを示す。このソケットオプションは読み込み専用である。
.TP
\fBSO_BINDTODEVICE\fP
-このソケットを、引き数で渡したインターフェース名で指定される
-(\(lqeth0\(rq のような) 特定のデバイスにバインドする。
-名前が空文字列だったり、オプションの長さ (optlen) が 0 の場合には、
-ソケットのバインドが削除される。渡すオプションは、インターフェース名が
-入ったヌル文字で終端された可変長の文字列である。
-文字列の最大のサイズは \fBIFNAMSIX\fP である。
-ソケットがインターフェースにバインドされると、その特定のインターフェース
-から受信されたパケットだけを処理する。
-このオプションはいくつかのソケットタイプ、
-特に \fBAF_INET\fP に対してのみ動作する点に注意すること。
-パケットソケットではサポートされていない (通常の \fBbind\fP(2) を使うこと)。
+このソケットを、引き数で渡したインターフェース名で指定される (\(lqeth0\(rq のような) 特定のデバイスにバインドする。
+名前が空文字列だったり、オプションの長さ (optlen) が 0 の場合には、 ソケットのバインドが削除される。
+渡すオプションは、インターフェース名が 入ったヌル文字で終端された可変長の文字列である。 文字列の最大のサイズは \fBIFNAMSIX\fP である。
+ソケットがインターフェースにバインドされると、 その特定のインターフェースから受信されたパケットだけを処理する。
+このオプションはいくつかのソケットタイプ、 特に \fBAF_INET\fP に対してのみ動作する点に注意すること。 パケットソケットではサポートされていない
+(通常の \fBbind\fP(2) を使うこと)。
-Before Linux 3.8, this socket option could be set, but could not retrieved
-with \fBgetsockopt\fP(2). Since Linux 3.8, it is readable. The \fIoptlen\fP
-argument should contain the buffer size available to receive the device name
-and is recommended to be \fBIFNAMSZ\fP bytes. The real device name length is
-reported back in the \fIoptlen\fP argument.
+Linux 3.8 より前のバージョンでは、このソケットオプションは \fBgetsockname\fP(2)
+で設定することはできたが、取得することができなかった。 Linux 3.8 以降では、読み出すことができる。 \fIoptlen\fP 引き数には、
+デバイス名を格納するのに十分なバッファサイズを渡すべきであり、 \fBIFNAMSIZ\fP バイトにすることを推奨する。 実際のデバイス名の長さは
+\fIoptlen\fP 引き数に格納されて返される。
.TP
\fBSO_BROADCAST\fP
ブロードキャストフラグを設定・取得する。有効になっていると、データグラ
\fBSO_MARK\fP (Linux 2.6.25 以降)
.\" commit 4a19ec5800fc3bb64e2d87c4d9fdd9e636086fe0
.\" and 914a9ab386a288d0f22252fc268ecbc048cdcbd5
-Set the mark for each packet sent through this socket (similar to the
-netfilter MARK target but socket\-based). Changing the mark can be used for
-mark\-based routing without netfilter or for packet filtering. Setting this
-option requires the \fBCAP_NET_ADMIN\fP capability.
+このソケットから送信される各パケットにマークをセットする (netfilter の MARK ターゲットと似ているが、ソケット単位である点が異なる)。
+マークの変更は、 netfilter なしでのマークに基づいてのルーティングや、 パケットフィルタリングに使うことができる。
+このオプションを変更するには \fBCAP_NET_ADMIN\fP ケーパビリティが必要である。
.TP
\fBSO_OOBINLINE\fP
.\" don't document it because it can do too much harm.
.\" in the 2.6.18 ChangeLog
\fBSCM_CREDENTIALS\fP 制御メッセージの受信を有効/無効にする。詳細は \fBunix\fP(7) を参照のこと。
.TP
+\fBSO_PEEK_OFF\fP (Linux 3.4 以降)
+.\" commit ef64a54f6e558155b4f149bb10666b9e914b6c54
+\fBMSG_PEEK\fP フラグと一緒に使用された場合 \fBrecv\fP(2) システムコールの "peek offset"
+にこのオプションの値が設定される。現在のところ、このオプションは \fBunix\fP(7) ソケットでのみサポートされている。
+
+このオプションが負の値に設定された場合、従来の動作となる。 つまり \fBMSG_PEEK\fP フラグが指定された \fBrecv\fP(2)
+は、キューの先頭のデータに対して peek 処理を行う (データを読み出すが、キューからデータの削除を行わない)。
+新規のソケットではこのオプションの値は必ず \-1 に設定される。
+
+このオプションに 0 以上の値が設定されると、 そのソケットのキュー上のオプション値で指定されたバイトオフセットにあるデータが次の peek
+処理で返される。 同時に、 "peek offset" がキューから peek 処理されたバイト数だけ加算される。したがって、次の peek
+処理ではキューのその次にあるデータが返される。
+
+\fBrecv\fP(2) (や同様のシステムコール) の \fBMSG_PEEK\fP フラグなしの呼び出しでキューの先頭のデータが削除された場合、 "peek
+offset" は削除されたバイト数だけ減算される。 言い換えると、 \fBMSG_PEEK\fP フラグなしでデータを受信すると、 "peek
+offset" が指すキュー内の相対的な位置が狂わないように調整され、この後の peek では、
+データ削除が行われなかった場合に返されたのと同じ値が返されるということである。
+
+データグラムソケットでは、 "peek offset" がパケットの途中を指している場合には、 返されるデータには \fBMSG_TRUNC\fP
+フラグが付与される。
+
+以下の例は \fBSO_PEEK_OFF\fP の利用例を示している。ストリームソケットのキューに以下の入力データが入っているものとする。
+
+ aabbccddeeff
+
+.IP
+以下の順序で \fBrecv\fP(2) の呼び出しを行うと、コメントに書かれた結果となる。
+
+.in +4n
+.nf
+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
+.fi
+.in
+.TP
\fBSO_PEERCRED\fP
このソケットに接続してきた外部プロセスの信任状 (credential) を返す。このソケットオプションが利用できるのは、接続された
\fBAF_UNIX\fP ストリームソケット間、および \fBsocketpair\fP(2) を使って作成された \fBAF_UNIX\fP
のストリームソケットとデータグラムソケットのペアだけである。 \fBunix\fP(7) を参照のこと。 \fBconnect\fP(2) や
-\fBsocketpair\fP(2) が呼ばれた時に有効であった信任状が返される。引き数は \fIucred\fP
-構造体である。このソケットオプションは読み込み専用である。
+\fBsocketpair\fP(2) が呼ばれた時に有効であった信任状が返される。 引き数は \fIucred\fP 構造体である。この構造体の定義を
+\fI<sys/socket.h>\fP を得るには、 機能検査マクロ \fB_GNU_SOURCE\fP を定義すること。
+このソケットオプションは読み込み専用である。
.TP
\fBSO_PRIORITY\fP
プロトコルで定義された優先度を、このソケットから 送信される全てのパケットにセットする。 Linux はネットワークキュー内部の
状態のソケットがアドレス \fBINADDR_ANY\fP で特定のポートにバインドされている場合には、
このポートに対しては、どんなローカルアドレスでもバインドできない。 引き数はブール整数のフラグである。
.TP
+\fBSO_RXQ_OVFL\fP (Linux 2.6.33 以降)
+.\" commit 3b885787ea4112eaa80945999ea0901bf742707f
+最後の受信パケットとこの受信パケットの間にそのソケットで捨てられた (ドロップされた) パケット数を示す、unsigned 32
+ビット値の補助メッセージ (cmsg) を受信した skb に付与することを指示する。
+.TP
\fBSO_SNDBUF\fP
.\" Most (all?) other implementations do not do this -- MTK, Dec 05
.\" See also the comment to SO_RCVBUF (17 Jul 2012 LKML mail)
\fBSO_TYPE\fP
ソケットのタイプを整数で取得する (例: \fBSOCK_STREAM\fP)。
このソケットオプションは読み出し専用である。
+.TP
+\fBSO_BUSY_POLL\fP (Linux 3.11 以降)
+データがなかった際にブロッキング受信での busy polling のおおよその時間をマイクロ秒単位で設定する。 この値を増やすには
+\fBCAP_NET_ADMIN\fP ケーパビリティが必要である。 このオプションのデフォルト値は
+\fI/proc/sys/net/core/busy_read\fP で制御できる。
+
+\fI/proc/sys/net/core/busy_poll\fP の値により、 \fBSO_BUSY_POLL\fP がセットされたソケットに対して
+\fBselect\fP(2) や \fBpoll\fP(2) を行い、報告すべきイベントがない場合に、 \fBselect\fP(2) や \fBpoll\fP(2) が
+busy polling をどのくらいの時間行うかが決まる。
+
+どちらの場合も、busy polling は、そのソケットが最後にデータを受信したネットワークデバイスがこのオプションに対応している場合のみ行われる。
+
+busy polling により遅延が改善されるはアプリケーションもあるが、 busy polling は CPU
+使用率と電力使用量をともに増加させることになるので、使用する際は注意して行うこと。
.SS シグナル
(ローカルもしくはリモート側で) 切断された 接続指向 (connection\-oriented) のソケットに対して
書き込みを行うと、その書き込みを行ったプロセスに \fBSIGPIPE\fP が送られ、 \fBEPIPE\fP が返される。 write 呼び出しに
\fBCONFIG_FILTER\fP ソケットオプションである \fBSO_ATTACH_FILTER\fP と \fBSO_DETACH_FILTER\fP
について記載されていない。これらは libpcap ライブラリを通して 用いる方が良い。
.SH 関連項目
-\fBgetsockopt\fP(2), \fBconnect\fP(2), \fBsetsockopt\fP(2), \fBsocket\fP(2),
+\fBconnect\fP(2), \fBgetsockopt\fP(2), \fBsetsockopt\fP(2), \fBsocket\fP(2),
\fBcapabilities\fP(7), \fBddp\fP(7), \fBip\fP(7), \fBpacket\fP(7), \fBtcp\fP(7), \fBudp\fP(7),
\fBunix\fP(7)
.SH この文書について
-この man ページは Linux \fIman\-pages\fP プロジェクトのリリース 3.51 の一部
+この man ページは Linux \fIman\-pages\fP プロジェクトのリリース 3.67 の一部
である。プロジェクトの説明とバグ報告に関する情報は
http://www.kernel.org/doc/man\-pages/ に書かれている。
OSDN Git Service
