release/man2/recv.2

   1 .\" Copyright (c) 1983, 1990, 1991 The Regents of the University of California.
   2 .\" All rights reserved.
   3 .\"
   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
   7 .\" are met:
   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.
  20 .\"
  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
  31 .\" SUCH DAMAGE.
  32 .\" %%%LICENSE_END
  33 .\"
  34 .\"     $Id: recv.2,v 1.3 1999/05/13 11:33:38 freitag Exp $
  35 .\"
  36 .\" Modified Sat Jul 24 00:22:20 1993 by Rik Faith <faith@cs.unc.edu>
  37 .\" Modified Tue Oct 22 17:45:19 1996 by Eric S. Raymond <esr@thyrsus.com>
  38 .\" Modified 1998,1999 by Andi Kleen
  39 .\" 2001-06-19 corrected SO_EE_OFFENDER, bug report by James Hawtin
  40 .\"
  41 .\"*******************************************************************
  42 .\"
  43 .\" This file was generated with po4a. Translate the source file.
  44 .\"
  45 .\"*******************************************************************
  46 .\"
  47 .\" Japanese Version Copyright (c) 1996 Akira Yoshiyama
  48 .\"         all rights reserved.
  49 .\" Translated 1996-07-18, Akira Yoshiyama <yosshy@jedi.seg.kobe-u.ac.jp>
  50 .\" Modified 1997-12-14, HANATAKA Shinya <hanataka@abyss.rim.or.jp>
  51 .\" Modified 1999-08-14, HANATAKA Shinya <hanataka@abyss.rim.or.jp>
  52 .\" Updated & Modified 2000-10-12, HAYAKAWA Hitoshi <cz8cb01@linux.or.jp>
  53 .\"        and NAKANO Takeo <nakano@apm.seikei.ac.jp>
  54 .\" Updated & Modified 2001-02-09, NAKANO Takeo
  55 .\" Updated 2003-10-11, Kentaro Shirakata <argrath@ub32.org>
  56 .\" Updated 2005-03-14, Akihiro MOTOKI <amotoki@dd.iij4u.or.jp>
  57 .\" Updated 2006-04-15, Akihiro MOTOKI, Catch up to LDP v2.29
  58 .\" Updated 2007-10-12, Akihiro MOTOKI, LDP v2.66
  59 .\" Updated 2008-08-06, Akihiro MOTOKI, LDP v3.05
  60 .\" Updated 2009-04-13, Akihiro MOTOKI, LDP v3.20
  61 .\" Updated 2013-03-26, Akihiro MOTOKI <amotoki@gmail.com>
  62 .\" Updated 2013-07-22, Akihiro MOTOKI <amotoki@gmail.com>
  63 .\"
  64 .TH RECV 2 2014\-08\-19 Linux "Linux Programmer's Manual"
  65 .SH 名前
  66 recv, recvfrom, recvmsg \- ソケットからメッセージを受け取る
  67 .SH 書式
  68 .\" .B #include <sys/uio.h>
  69 .\" .br
  70 .nf
  71 \fB#include <sys/types.h>\fP
  72 .br
  73 \fB#include <sys/socket.h>\fP
  74 .sp
  75 \fBssize_t recv(int \fP\fIsockfd\fP\fB, void *\fP\fIbuf\fP\fB, size_t \fP\fIlen\fP\fB, int \fP\fIflags\fP\fB);\fP
  76 .sp
  77 \fBssize_t recvfrom(int \fP\fIsockfd\fP\fB, void *\fP\fIbuf\fP\fB, size_t \fP\fIlen\fP\fB, int \fP\fIflags\fP\fB,\fP
  78 \fB                 struct sockaddr *\fP\fIsrc_addr\fP\fB, socklen_t *\fP\fIaddrlen\fP\fB);\fP
  79 .sp
  80 \fBssize_t recvmsg(int \fP\fIsockfd\fP\fB, struct msghdr *\fP\fImsg\fP\fB, int \fP\fIflags\fP\fB);\fP
  81 .fi
  82 .SH 説明
  83 \fBrecv\fP(), \fBrecvfrom\fP(), \fBrecvmsg\fP() コールは、 ソケットからメッセージを受け取るのに使用される。
  84 これらはコネクションレス型のソケットにも接続指向 (connection\-oriened) 型のソケットにも使用できる。 このページでは、まずこれら 3
  85 つのシステムコールすべてに共通の機能について説明し、 システムコール間の違いについて説明する。
  86 .PP
  87 これらの三つのシステムコールはいずれも、成功した場合にはメッセージの長さを返す。 メッセージが長過ぎて指定されたバッファーに入り切らなかった場合には、
  88 メッセージを受信したソケットの種類によっては余分のバイトが捨てられる かもしれない。
  89 .PP
  90 ソケットに受け取るメッセージが存在しなかった場合、 受信用のコールはメッセージが到着するまで待つ。 ただし、ソケットが非停止 (nonblocking)
  91 に設定されていた場合 (\fBfcntl\fP(2)  を参照) は \-1 を返し、外部変数 \fIerrno\fP に \fBEAGAIN\fP か
  92 \fBEWOULDBLOCK\fP を設定する。 これらの受信用のコールは、受信したデータのサイズが要求したサイズに
  93 達するまで待つのではなく、何らかのデータを受信すると復帰する (受信されるデータの最大サイズは要求したサイズである)。
  94 .PP
  95 アプリケーションは \fBselect\fP(2), \fBpoll\fP(2), \fBepoll\fP(7)
  96 を使って、ソケットにさらにデータが到着しているかを判定することができる。
  97 .SS フラグ引き数
  98 \fIflags\fP 引き数には、以下の値を 1つ以上、ビット単位の論理和 を取ったものを指定する:
  99 .TP
 100 \fBMSG_CMSG_CLOEXEC\fP (\fBrecvmsg\fP() のみ; Linux 2.6.23)
 101 (\fBunix\fP(7)  で説明されている)  \fBSCM_RIGHTS\fP 操作を使って UNIX ドメインのファイルディスクリプター経由で受信した
 102 ファイルディスクリプターについて close\-on\-exec フラグをセットする。 このフラグは、 \fBopen\fP(2)  の \fBO_CLOEXEC\fP
 103 フラグと同じ理由で有用である。
 104 .TP
 105 \fBMSG_DONTWAIT\fP (Linux 2.2 以降)
 106 非停止 (nonblocking) 操作を有効にする。 操作が停止するような場合にエラー \fBEAGAIN\fP か \fBEWOULDBLOCK\fP
 107 で呼び出しが失敗する (\fBfcntl\fP(2)  の \fBF_SETFL\fP で \fBO_NONBLOCK\fP
 108 フラグを指定することによっても有効にできる)。
 109 .TP
 110 \fBMSG_ERRQUEUE\fP (Linux 2.2 以降)
 111 このフラグを指定すると、 キューに入れられたエラーをソケットのエラーキューから取りだせるようになる。 このエラーは補助メッセージに組み込まれて渡され、
 112 この補助メッセージの種別はプロトコルに依存する (IPv4 の場合は \fBIP_RECVERR\fP)。
 113 ユーザーは十分なサイズのバッファーを用意しなければならない。 補助メッセージに関するより詳細な情報は \fBcmsg\fP(3)  および \fBip\fP(7)
 114 を参照のこと。 エラーの原因となったオリジナルパケットのペイロードは、 \fImsg_iovec\fP 経由で通常のデータとして渡される。
 115 エラーを起こしたデータグラムのオリジナルの宛先アドレスは、 \fImsg_name\fP 経由で参照できる。
 116 .IP
 117 ローカルなエラーの場合はアドレスは渡されない
 118 (これは \fIcmsghdr\fP の \fIcmsg_len\fP メンバーでチェックできる)。
 119 受信エラーの場合は \fBMSG_ERRQUIE\fP が \fImsghdr\fP にセットされる。
 120 エラーが渡された後には、キューに入っている次のエラーに基いて、
 121 処理待ちのソケットエラーが再生成され、次のソケット操作の際に渡される。
 122
 123 このエラーは \fIsock_extended_err\fP 構造体で提供される:
 124 .in +4n
 125 .nf
 126
 127 #define SO_EE_ORIGIN_NONE    0
 128 #define SO_EE_ORIGIN_LOCAL   1
 129 #define SO_EE_ORIGIN_ICMP    2
 130 #define SO_EE_ORIGIN_ICMP6   3
 131
 132 struct sock_extended_err
 133 {
 134     uint32_t ee_errno;   /* error number */
 135     uint8_t  ee_origin;  /* where the error originated */
 136     uint8_t  ee_type;    /* type */
 137     uint8_t  ee_code;    /* code */
 138     uint8_t  ee_pad;     /* padding */
 139     uint32_t ee_info;    /* additional information */
 140     uint32_t ee_data;    /* other data */
 141     /* More data may follow */
 142 };
 143
 144 struct sockaddr *SO_EE_OFFENDER(struct sock_extended_err *);
 145 .fi
 146 .in
 147 .IP
 148 \fIee_errno\fP にはキューに入れられたエラーの \fIerrno\fP が入っている。 \fIee_origin\fP
 149 にはエラーが発生した場所のオリジンコード (origin code) が入っている。 他のフィールドはプロトコル依存である。
 150 \fBSO_EE_OFFENDER\fP マクロは、この補助的なメッセージを引き数に取って、
 151 エラーの発生したネットワークオブジェクトのアドレスへのポインターを返す。 アドレスが不明の場合には、 \fIsockaddr\fP の
 152 \fIsa_family\fP メンバーが \fBAF_UNSPEC\fP になっている。 \fIsockaddr\fP の他のフィールドは不定である。
 153 エラーの発生したパケットのペイロードは通常のデータとして渡される。
 154 .IP
 155 ローカルなエラーの場合はアドレスは渡されない
 156 (これは \fIcmsghdr\fP の \fIcmsg_len\fP メンバーでチェックできる)。
 157 受信エラーの場合は \fBMSG_ERRQUIE\fP が \fImsghdr\fP にセットされる。
 158 エラーが渡された後には、キューに入っている次のエラーに基いて、
 159 処理待ちのソケットエラーが再生成され、次のソケット操作の際に渡される。
 160 .TP
 161 \fBMSG_OOB\fP
 162 このフラグは、通常のデータストリームでは受信できない 帯域外 (out\-of\-band) データの受信を要求する。 プロトコルによっては、
 163 通常のデータキューの先頭に速達データを置くものがあるが、 そのようなプロトコルではこのフラグは使用できない。
 164 .TP
 165 \fBMSG_PEEK\fP
 166 このフラグを指定すると、 受信キューの最初のデータを返すとき、キューからデータを削除しない。
 167 したがって、この後でもう一度受信コールを呼び出すと、同じデータが返ることになる。
 168 .TP
 169 \fBMSG_TRUNC\fP (Linux 2.2 以降)
 170 raw ソケット (\fBAF_PACKET\fP)、 Internet datagram ソケット (Linux 2.4.27/2.6.8 以降)、
 171 netlink (Linux 2.6.22 以降) ソケット、 UNIX datagram ソケット (Linux 3.4 以降)
 172 の場合、パケットやデータグラムの長さが渡したバッファーよりも長かった場合にも、 パケットやデータグラムの実際の長さを返す。
 173
 174 Internet ストリームソケットでの利用については \fBtcp\fP(7)  を参照。
 175 .TP
 176 \fBMSG_WAITALL\fP (Linux 2.2 以降)
 177 .\"
 178 このフラグは、要求した量いっぱいのデータが到着するまで、 操作を停止 (block) するよう要求する。 但し、シグナルを受信したり、エラーや切断
 179 (disconnect) が発生したり、 次に受信されるデータが異なる型だったりした場合には、 要求した量よりデータが少なくても返ることがある。
 180 .SS recvfrom()
 181 \fBrecvfrom\fP() は受信したメッセージをバッファー \fIbuf\fP に格納する。 呼び出し元はバッファーサイズを \fIlen\fP
 182 で指定しなければならない。
 183
 184 .\" (Note: for datagram sockets in both the UNIX and Internet domains,
 185 .\" .I src_addr
 186 .\" is filled in.
 187 .\" .I src_addr
 188 .\" is also filled in for stream sockets in the UNIX domain, but is not
 189 .\" filled in for stream sockets in the Internet domain.)
 190 .\" [The above notes on AF_UNIX and AF_INET sockets apply as at
 191 .\" Kernel 2.4.18. (MTK, 22 Jul 02)]
 192 \fIsrc_addr\fP が NULL 以外で、下層のプロトコルからメッセージの送信元アドレスが分かる場合、 この送信元アドレスが \fIsrc_addr\fP
 193 が指すバッファーに格納される。 この場合、 \fIaddrlen\fP は入出力両用の引き数となる。 呼び出し前に、呼び出し元は \fIsrc_addr\fP
 194 に割り当てたバッファーの大きさで初期化しておくべきである。 返ってくる時には、 \fIaddrlen\fP
 195 は送信元アドレスの実際の大きさに変更される。渡されたバッファーが小さ過ぎる場合には、返されるアドレスの末尾は 切り詰められる。この場合には、
 196 \fIaddrlen\fP では、呼び出し時に渡された値よりも大きな値が返される。
 197
 198 .\"
 199 呼び出し元が送信元アドレスを必要としない場合は、 \fIsrc_addr\fP と \fIaddrlen\fP には NULL を指定すべきである。
 200 .SS recv()
 201 \fBrecv\fP()  コールは通常 \fI接続済みの (connected)\fP ソケットに対してのみ使用される (\fBconnect\fP(2)
 202 参照)。次の呼び出しと等価である。
 203
 204 .\"
 205     recvfrom(fd, buf, len, flags, NULL, 0));
 206 .SS recvmsg()
 207 \fBrecvmsg\fP()  コールは、直接渡す引き数の数を減らすために \fImsghdr\fP 構造体を使用する。この構造体は
 208 \fI<sys/socket.h>\fP で以下のように定義されている:
 209 .in +4n
 210 .nf
 211
 212 struct iovec {                    /* Scatter/gather array items */
 213     void  *iov_base;              /* Starting address */
 214     size_t iov_len;               /* Number of bytes to transfer */
 215 };
 216
 217 struct msghdr {
 218     void         *msg_name;       /* 追加のアドレス */
 219     socklen_t     msg_namelen;    /* アドレスのサイズ */
 220     struct iovec *msg_iov;        /* scatter/gather 配列 */
 221     size_t        msg_iovlen;     /* msg_iov の要素数 */
 222     void         *msg_control;    /* 補助データ (後述) */
 223     size_t        msg_controllen; /* 補助データバッファー長 */
 224     int           msg_flags;      /* 受信メッセージのフラグ */
 225 };
 226 .fi
 227 .in
 228 .PP
 229 フィールド \fImsg_name\fP は、 ソケットが接続されていない場合に送信元アドレスを返すのに使用されるバッファーを指す。
 230 このバッファーは呼び出し元が確保する。 呼び出し元は呼び出し前に \fImsg_namelen\fP にこのバッファーの大きさを設定しなければならない。
 231 呼び出しが成功した場合、呼び出しから返って来た際には \fImsg_namelen\fP には返されるアドレスの長さが入っている。
 232 アプリケーションが送信元アドレスを知る必要がない場合には、 \fImsg_name\fP に NULL を指定することができる。
 233
 234 \fImsg_iov\fP と \fImsg_iovlen\fP フィールドは scatter\-gather 用の場所を指定する。 \fBreadv\fP(2)
 235 に説明がある。
 236
 237 \fImsg_control\fP フィールドは \fImsg_controllen\fP の長さを持ち、他のプロトコル制御メッセージや
 238 種々の補助データのためのバッファーへのポインターである。 \fBrecvmsg\fP()  を呼ぶ際には、 \fImsg_controllen\fP に
 239 \fImsg_control\fP のバッファーの長さを入れておく必要がある。 コールが成功して返った場合、制御メッセージ列の長さが入っている。
 240 .PP
 241 メッセージの形式は以下の通り:
 242 .in +4n
 243 .nf
 244
 245 struct cmsghdr {
 246     socklen_t     cmsg_len;     /* data byte count, including hdr */
 247     int           cmsg_level;   /* originating protocol */
 248     int           cmsg_type;    /* protocol\-specific type */
 249 /* followed by
 250     unsigned char cmsg_data[]; */
 251 };
 252 .fi
 253 .in
 254 .PP
 255 補助データは、 \fBcmsg\fP(3)  に定義されたマクロ経由でのみアクセスすべきである。
 256 .PP
 257 例をあげると、 Linux はこの補助データのメカニズムを、 UNIX ドメインソケット上での拡張エラーや IP オプション、
 258 ファイルディスクリプターの受け渡しに利用している。
 259 .PP
 260 \fImsghdr\fP の \fImsg_flags\fP フィールドは \fBrecvmsg\fP()
 261 からのリターン時に設定される。ここにはいくつかのフラグが入る。
 262 .TP
 263 \fBMSG_EOR\fP
 264 これはレコードの終り (end\-of\-record) を示し、 返されたデータが完全なレコードであることを示す (一般的には
 265 \fBSOCK_SEQPACKET\fP 型のソケットで使用される)。
 266 .TP
 267 \fBMSG_TRUNC\fP
 268 データグラムが与えられたバッファーより大きかったために、 データグラムのはみ出した部分が捨てられたことを示す。
 269 .TP
 270 \fBMSG_CTRUNC\fP
 271 補助データのためのバッファーが不足したために、 制御データの一部が捨てられたことを示す。
 272 .TP
 273 \fBMSG_OOB\fP
 274 速達データや帯域外データを受信したことを示す。
 275 .TP
 276 \fBMSG_ERRQUEUE\fP
 277 データは受信しなかったが ソケットのエラーキューから拡張エラーを受信したことを示す。
 278 .SH 返り値
 279 これらのコールは受信したバイト数を返す。 エラーの場合は \-1 を返し、 \fIerrno\fP にエラーを示す値を設定する。
 280
 281 ストリームソケットの接続相手が正しくシャットダウンを実行した場合は、
 282 返り値は 0 (昔ながらの "end\-of\-file" の戻り値) となる。
 283
 284 いくつかのドメインのデータグラムソケット (UNIX ドメインやインターネットドメインなど) では、長さ 0 のデータグラムが送信できる。
 285 このようなデータグラムを受信した場合、 返り値は 0 となる。
 286
 287 ストリームソケットに対する受信要求バイト数が 0 だった場合も、 値 0 が返される。
 288 .SH エラー
 289 これらはソケット層で発生する一般的なエラーである。 他のエラーが下層のプロトコルモジュールで生成され、 返されるかもしれない。
 290 それらのマニュアルを参照すること。
 291 .TP
 292 \fBEAGAIN\fP または \fBEWOULDBLOCK\fP
 293 .\" Actually EAGAIN on Linux
 294 ソケットが非停止 (nonblocking) に設定されていて 受信操作が停止するような状況になったか、 受信に時間切れ (timeout)
 295 が設定されていて データを受信する前に時間切れになった。 POSIX.1\-2001 は、この場合にどちらのエラーを返すことも認めており、 これら 2
 296 つの定数が同じ値を持つことも求めていない。 したがって、移植性が必要なアプリケーションでは、両方の可能性を 確認すべきである。
 297 .TP
 298 \fBEBADF\fP
 299 引き数 \fIsockfd\fP が不正なディスクリプターである。
 300 .TP
 301 \fBECONNREFUSED\fP
 302 リモートのホストでネットワーク接続が拒否された (よくある理由としては、要求したサービスが起動されていないなどがある)。
 303 .TP
 304 \fBEFAULT\fP
 305 受信バッファーへのポインターがプロセスのアドレス空間外を指している。
 306 .TP
 307 \fBEINTR\fP
 308 データを受信する前に、シグナルが配送されて割り込まれた。 \fBsignal\fP(7)  参照。
 309 .TP
 310 \fBEINVAL\fP
 311 .\" e.g., msg_namelen < 0 for recvmsg() or addrlen < 0 for recvfrom()
 312 不正な引き数が渡された。
 313 .TP
 314 \fBENOMEM\fP
 315 \fBrecvmsg\fP()  のためのメモリーが確保できなかった。
 316 .TP
 317 \fBENOTCONN\fP
 318 ソケットに接続指向プロトコルが割り当てられており、 まだ接続されていない (\fBconnect\fP(2)  と \fBaccept\fP(2)
 319 を参照のこと)。
 320 .TP
 321 \fBENOTSOCK\fP
 322 引き数 \fIsockfd\fP がソケットを参照していない。
 323 .SH 準拠
 324 4.4BSD (これらの関数は 4.2BSD で現われた), POSIX.1\-2001。
 325 .LP
 326 POSIX.1\-2001 では、 \fBMSG_OOB\fP, \fBMSG_PEEK\fP, \fBMSG_WAITALL\fP フラグだけが記載されている。
 327 .SH 注意
 328 \fIsocklen_t\fP 型は POSIX で発案された。 \fBaccept\fP(2) も参照。
 329
 330 .\" glibc bug raised 12 Mar 2006
 331 .\" http://sourceware.org/bugzilla/show_bug.cgi?id=2448
 332 .\" The problem is an underlying kernel issue: the size of the
 333 .\" __kernel_size_t type used to type this field varies
 334 .\" across architectures, but socklen_t is always 32 bits.
 335 POSIX.1\-2001 では、構造体 \fImsghdr\fP のフィールド \fImsg_controllen\fP は \fIsocklen_t\fP
 336 型であるべきだとされているが、 現在の glibc では \fIsize_t\fP 型である。
 337
 338 \fBrecvmmsg\fP(2)  には、一度の呼び出しでの複数のデータグラムに使用できる Linux 固有の システムコールに関する情報が書かれている。
 339 .SH 例
 340 \fBrecvfrom\fP()  の利用例が \fBgetaddrinfo\fP(3)  に記載されている。
 341 .SH 関連項目
 342 \fBfcntl\fP(2), \fBgetsockopt\fP(2), \fBread\fP(2), \fBrecvmmsg\fP(2), \fBselect\fP(2),
 343 \fBshutdown\fP(2), \fBsocket\fP(2), \fBcmsg\fP(3), \fBsockatmark\fP(3), \fBsocket\fP(7)
 344 .SH この文書について
 345 この man ページは Linux \fIman\-pages\fP プロジェクトのリリース 3.78 の一部
 346 である。プロジェクトの説明とバグ報告に関する情報は
 347 http://www.kernel.org/doc/man\-pages/ に書かれている。