1 .\" Copyright (c) 1983, 1990, 1991 The Regents of the University of California.
2 .\" All rights reserved.
4 .\" %%%LICENSE_START(BSD_4_CLAUSE_UCB)
5 .\" Redistribution and use in source and binary forms, with or without
6 .\" modification, are permitted provided that the following conditions
8 .\" 1. Redistributions of source code must retain the above copyright
9 .\" notice, this list of conditions and the following disclaimer.
10 .\" 2. Redistributions in binary form must reproduce the above copyright
11 .\" notice, this list of conditions and the following disclaimer in the
12 .\" documentation and/or other materials provided with the distribution.
13 .\" 3. All advertising materials mentioning features or use of this software
14 .\" must display the following acknowledgement:
15 .\" This product includes software developed by the University of
16 .\" California, Berkeley and its contributors.
17 .\" 4. Neither the name of the University nor the names of its contributors
18 .\" may be used to endorse or promote products derived from this software
19 .\" without specific prior written permission.
21 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
22 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
23 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
24 .\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
25 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
26 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
27 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
28 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
29 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
30 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
34 .\" Modified 1993-07-24 by Rik Faith <faith@cs.unc.edu>
35 .\" Modified 1996-10-21 by Eric S. Raymond <esr@thyrsus.com>
36 .\" Modified 1998-2000 by Andi Kleen to match Linux 2.2 reality
37 .\" Modified 2002-04-23 by Roger Luethi <rl@hellgate.ch>
38 .\" Modified 2004-06-17 by Michael Kerrisk <mtk.manpages@gmail.com>
39 .\" 2008-12-04, mtk, Add documentation of accept4()
41 .\"*******************************************************************
43 .\" This file was generated with po4a. Translate the source file.
45 .\"*******************************************************************
47 .\" Japanese Version Copyright (c) 1998-2000 Shinya HANATAKA,
48 .\" Takeshi Hakamada and NAKANO Takeo
49 .\" all rights reserved.
50 .\" Translated 1998-04-06, Shinya HANATAKA <shinya@abyss.rim.or.jp>
51 .\" Takeshi Hakamada <hakamada@nsg.sgi.com>
52 .\" Updated & Modified 2000-10-12, NAKANO Takeo <nakano@apm.seikei.ac.jp
53 .\" Updated & Modified 2002-09-24, Akihiro MOTOKI <amotoki@dd.iij4u.or.jp>
54 .\" Updated & Modified 2005-02-23, Akihiro MOTOKI
55 .\" Updated & Modified 2006-04-14, Akihiro MOTOKI, LDP v2.29
56 .\" Updated & Modified 2008-12-24, Akihiro MOTOKI, LDP v3.15
57 .\" Updated 2008-04-13, Akihiro MOTOKI, LDP v3.20
59 .TH ACCEPT 2 2010\-09\-10 Linux "Linux Programmer's Manual"
61 accept, accept4 \- ソケットへの接続を受ける
64 \fB#include <sys/types.h>\fP /* 「注意」参照 */
65 \fB#include <sys/socket.h>\fP
67 \fBint accept(int \fP\fIsockfd\fP\fB, struct sockaddr *\fP\fIaddr\fP\fB, socklen_t *\fP\fIaddrlen\fP\fB);\fP
69 \fB#define _GNU_SOURCE\fP /* feature_test_macros(7) 参照 */
70 \fB#include <sys/socket.h>\fP
72 \fBint accept4(int \fP\fIsockfd\fP\fB, struct sockaddr *\fP\fIaddr\fP\fB,\fP
73 \fB socklen_t *\fP\fIaddrlen\fP\fB, int \fP\fIflags\fP\fB);\fP
76 \fBaccept\fP() システムコールは、接続指向のソケット型 (\fBSOCK_STREAM\fP, \fBSOCK_SEQPACKET\fP)
77 で用いられる。 この関数は、接続待ちソケット \fIsocket\fP 宛ての保留状態の接続要求が入っているキューから
78 先頭の接続要求を取り出し、接続済みソケットを新規に生成し、 そのソケットを参照する新しいファイル・ディスクリプタを返す。
79 新規に生成されたソケットは、接続待ち (listen) 状態ではない。 もともとのソケット \fIsockfd\fP はこの呼び出しによって影響を受けない。
81 引き数 \fIsockfd\fP は、 \fBsocket\fP(2) によって生成され、 \fBbind\fP(2) によってローカルアドレスにバインドされ、
82 \fBlisten\fP(2) を経て接続を待っているソケットである。
84 \fIaddr\fP 引き数は \fIsockaddr\fP 構造体へのポインタである。 この構造体には接続相手のソケットのアドレスが入っている。 \fIaddr\fP
85 引き数で返されるアドレスの正確なフォーマットは、 ソケットのアドレス種別によって変わる (\fBsocket\fP(2) およびそれぞれのプロトコルの
86 man ページを参照)。 \fIaddr\fP が NULL の場合、 \fIaddr\fP には何も入らない。この場合、 \fIaddrlen\fP
87 は使用されず、この引き数は NULL にしておくべきである。
89 \fIaddrlen\fP 引き数は入出力両用の引き数である。呼び出し時には、呼び出し元が \fIaddr\fP が指す構造体のサイズ (バイト単位)
90 で初期化しておかなければならない。 返ってくる時には、接続相手のアドレスの実際の大きさが格納される。
92 渡されたバッファが小さ過ぎた場合は、返されるアドレスの末尾が切り詰められる。
93 この場合には、 \fIaddrlen\fP には、呼び出し時に指定された値よりも大きな値が格納される。
95 キューに保留となっている接続要求がなく、 かつソケットが非停止になっていないときは、 \fBaccept\fP() は接続が発生するまで呼び出し元を停止
96 (block) する。 ソケットが非停止になっていて、 待ち状態の接続要求がキューに無いときは、 \fBaccept\fP() はエラー \fBEAGAIN\fP
97 か \fBEWOULDBLOCK\fP で失敗する。
99 ソケットへの接続到着を知るには、 \fBselect\fP(2) または \fBpoll\fP(2) を用いればよい。
100 新しい接続要求が来るとソケットは読み込み可能になるので、 そうしたら \fBaccept\fP() を呼んでその接続に対するソケットを取得すればよい。
101 あるいはソケットに設定を行い、何らかのアクションがあったときに \fBSIGIO\fP を配送 (deliver) させるようにすることもできる。詳細は
102 \fBsocket\fP(7) を参照のこと。
104 明示的な接続確認 (confirmation) を必要とするようなプロトコル (DECNet など) では、 \fBaccept\fP()
105 は単に次の接続要求をキューから取り出すだけであり、 接続確認は行わないことに注意せよ。接続確認は、 新しいファイル・ディスクリプタに対する
106 通常の読み取り/書き込みによってなされ、接続拒否 (rejection) は新しいソケットをクローズすることによってなされる。 現在のところ、
107 Linux 上でこれらのセマンティクスを持つのは DECNet だけである。
109 \fIflags\fP が 0 の場合、 \fBaccept4\fP() は \fBaccept\fP() と同じである。 \fIflags\fP
110 に以下の値をビット毎の論理和 (OR) で指定することで、 異なる動作をさせることができる。
113 新しく生成されるオープンファイル記述 (open file description) の \fBO_NONBLOCK\fP
114 ファイルステータスフラグをセットする。 このフラグを使うことで、 \fBO_NONBLOCK\fP をセットするために \fBfcntl\fP(2)
118 新しいファイルディスクリプタに対して close\-on\-exec (\fBFD_CLOEXEC\fP) フラグをセットする。
119 このフラグが役に立つ理由については、 \fBopen\fP(2) の \fBO_CLOEXEC\fP フラグの説明を参照のこと。
121 成功した場合、これらのシステムコールは 受け付けたソケットのディスクリプタである非負の整数値を返す。 エラーが発生した場合は \-1 を返し、
122 \fIerrno\fP を適切に設定する。
124 Linux の \fBaccept\fP() (と \fBaccept4\fP()) は、新しいソケットにおける、発生済みのネットワークエラーを
125 \fBaccept\fP() からのエラーコードとして渡す。 この振舞いは BSD ソケットの実装とは異なる。 信頼性の高い動作を行うためには、
126 アプリケーションはプロトコルで定義されているネットワークエラーの検知を \fBaccept\fP() のあとに行い、それらのエラーを \fBEAGAIN\fP
127 と同じように扱い、再試行 (retry) を行うべきである。 TCP/IP では、以下のエラーが該当する: \fBENETDOWN\fP,
128 \fBEPROTO\fP, \fBENOPROTOOPT\fP, \fBEHOSTDOWN\fP, \fBENONET\fP, \fBEHOSTUNREACH\fP,
129 \fBEOPNOTSUPP\fP, \fBENETUNREACH\fP
132 \fBEAGAIN\fP または \fBEWOULDBLOCK\fP
133 .\" Actually EAGAIN on Linux
134 ソケットが非停止になっていて、 かつ受付け対象の接続が存在しない。 POSIX.1\-2001 は、この場合にどちらのエラーを返すことも認めており、
135 これら 2 つの定数が同じ値を持つことも求めていない。 したがって、移植性が必要なアプリケーションでは、両方の可能性を 確認すべきである。
144 \fIaddr\fP 引き数がユーザアドレス空間の書き込み可能領域にない。
147 有効な接続が到着する前に捕捉されたシグナルによって システムコールが中断された。 \fBsignal\fP(7) 参照。
150 ソケットが接続待ち状態ではない。もしくは、 \fIaddrlen\fP が不正である (例えば、負の場合など)。
153 (\fBaccept4\fP()) \fIflags\fP に不正な値が指定されている。
156 1プロセスがオープンできるファイル・ディスクリプタ数の上限に達した。
159 オープンされたファイルの総数がシステム全体の上限に達していた。
161 \fBENOBUFS\fP, \fBENOMEM\fP
162 メモリが足りない。 多くの場合は、システムメモリが足りないわけではなく、 ソケットバッファの大きさによるメモリ割り当ての制限である。
165 ディスクリプタはソケットではなくファイルを参照している。
168 参照しているソケットの型が \fBSOCK_STREAM\fP でない。
173 上記に加えて、Linux の \fBaccept\fP() は以下のエラーで失敗する:
176 ファイアウォールのルールにより接続が禁止された。
178 この他に、新しいソケットに対するネットワークエラーが返されることもある。 これらはそれぞれのプロトコルで定義されている。 いろいろな Linux
179 カーネルでは、 以下に示すようなエラーを返すこともある。 \fBENOSR\fP, \fBESOCKTNOSUPPORT\fP,
180 \fBEPROTONOSUPPORT\fP, \fBETIMEDOUT\fP. \fBERESTARTSYS\fP がトレースの最中に現れることもある。
182 \fBaccept4\fP() システムコールは Linux 2.6.28 以降で利用可能である。 glibc でのサポートはバージョン 2.10
185 .\" The BSD man page documents five possible error returns
186 .\" (EBADF, ENOTSOCK, EOPNOTSUPP, EWOULDBLOCK, EFAULT).
187 .\" POSIX.1-2001 documents errors
188 .\" EAGAIN, EBADF, ECONNABORTED, EINTR, EINVAL, EMFILE,
189 .\" ENFILE, ENOBUFS, ENOMEM, ENOTSOCK, EOPNOTSUPP, EPROTO, EWOULDBLOCK.
190 .\" In addition, SUSv2 documents EFAULT and ENOSR.
191 \fBaccept\fP(): POSIX.1\-2001, SVr4, 4.4BSD, (\fBaccept\fP() は 4.2BSD で初めて実装された).
193 \fBaccept4\fP() は非標準の Linux による拡張である。
195 .\" Some testing seems to show that Tru64 5.1 and HP-UX 11 also
196 .\" do not inherit file status flags -- MTK Jun 05
197 Linux では、 \fBaccept\fP() が返す新しいソケットは listen を行っているソケットの ファイル状態フラグ
198 (\fBO_NONBLOCK\fP や \fBO_ASYNC\fP など) を継承「しない」。 この動作は標準的な BSD ソケットの実装とは異なっている。
199 移植性を考慮したプログラムではファイル状態フラグが継承されるかどうかは 前提にせず、常に \fBaccept\fP()
200 が返したソケットに対して全ての必要なフラグを明示的に設定するように すべきである。
202 POSIX.1\-2001 では \fI<sys/types.h>\fP のインクルードは必須とされておらず、 Linux
203 ではこのヘッダファイルは必要ではない。 しかし、歴史的には、いくつかの実装 (BSD 系) でこのヘッダファイルが
204 必要であり、移植性が必要なアプリケーションではこのファイルを インクルードするのが賢明であろう。
206 \fBSIGIO\fP が届けられた後や、 \fBselect\fP(2) または \fBpoll\fP(2) が読み込み可能イベントを返した後に、
207 必ずしも待機中の接続があるとは限らない。 なぜならその接続は、 \fBaccept\fP() が呼ばれる前に、非同期的なネットワークエラーや
208 他のスレッドから呼ばれた (別の) accept によって 削除されているかもしれないからである。 この場合、その \fBaccept\fP()
209 呼び出しは停止 (block) し、次の接続の到着を待ちつづける。 \fBaccept\fP() に停止を行わせないようにするには、引き数に渡すソケット
210 \fIsockfd\fP に \fBO_NONBLOCK\fP フラグをセットしておく必要がある (\fBsocket\fP(7) を見よ)。
212 \fBaccept\fP() の第 3 引き数は、もともと \fIint *\fP と宣言されていた (libc4 や libc5, 4.x BSD, SunOS
213 4, SGI など多くのシステムではそうなっている)。 POSIX.1g draft 標準は、 これを \fIsize_t *\fP
214 に変更しようとし、SunOS 5 ではそう宣言されている。 後に POSIX drafts には \fIsocklen_t *\fP が含まれるようになり、
215 Single UNIX Specification や glibc2 ではこのように宣言されるようになった。 Linus Torvald
218 .\" .I fails: only italicizes a single line
219 「まともなライブラリを作りたければ、 "socklen_t" のサイズは int と同じにしなきゃならない。 さもないと BSD
220 ソケット層を破壊することになっちゃう。 POSIX は最初こいつを size_t にしたんで、 ぼくは彼らに文句をがなりたてた
221 (多分そういう人は他にもいたと思う。多くはなかったようだけど)。 こいつを size_t にするのは完全にいかれてる。 例えば 64
222 ビットアーキテクチャでは、 size_t が "int" と同じサイズだなんてことはほとんどないからね。 このサイズは "int" と
223 同じでなきゃ『ダメ』なんだ。 BSD ソケットインターフェースっていうのはそういうものなんだから。 まあともかく POSIX の人たちも、
224 "socklen_t" を作るという解決策をなんとかひねり出した。 そもそも最初から放っておけば良かったんだが、 いじっちゃった以上、
225 名前付きの型を持たせなきゃならない、と思ったみたいだね。 なんでかはわかんないけど (きっと最初にやっちまった馬鹿な間違いで顔をつぶしたくなかったから、
226 こっそり名前を付け替えて自分たちの大失敗をごまかそうとしたんだろう)。」
230 \fBbind\fP(2), \fBconnect\fP(2), \fBlisten\fP(2), \fBselect\fP(2), \fBsocket\fP(2),
233 この man ページは Linux \fIman\-pages\fP プロジェクトのリリース 3.76 の一部
234 である。プロジェクトの説明とバグ報告に関する情報は
235 http://www.kernel.org/doc/man\-pages/ に書かれている。