release/man2/recv.2

   1 .\" Copyright (c) 1983, 1990, 1991 The Regents of the University of California.
   2 .\" All rights reserved.
   3 .\"
   4 .\" Redistribution and use in source and binary forms, with or without
   5 .\" modification, are permitted provided that the following conditions
   6 .\" are met:
   7 .\" 1. Redistributions of source code must retain the above copyright
   8 .\"    notice, this list of conditions and the following disclaimer.
   9 .\" 2. Redistributions in binary form must reproduce the above copyright
  10 .\"    notice, this list of conditions and the following disclaimer in the
  11 .\"    documentation and/or other materials provided with the distribution.
  12 .\" 3. All advertising materials mentioning features or use of this software
  13 .\"    must display the following acknowledgement:
  14 .\"     This product includes software developed by the University of
  15 .\"     California, Berkeley and its contributors.
  16 .\" 4. Neither the name of the University nor the names of its contributors
  17 .\"    may be used to endorse or promote products derived from this software
  18 .\"    without specific prior written permission.
  19 .\"
  20 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
  21 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  22 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  23 .\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
  24 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
  25 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
  26 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  27 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
  28 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
  29 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  30 .\" SUCH DAMAGE.
  31 .\"
  32 .\"     $Id: recv.2,v 1.3 1999/05/13 11:33:38 freitag Exp $
  33 .\"
  34 .\" Modified Sat Jul 24 00:22:20 1993 by Rik Faith <faith@cs.unc.edu>
  35 .\" Modified Tue Oct 22 17:45:19 1996 by Eric S. Raymond <esr@thyrsus.com>
  36 .\" Modified 1998,1999 by Andi Kleen
  37 .\" 2001-06-19 corrected SO_EE_OFFENDER, bug report by James Hawtin
  38 .\"
  39 .\"*******************************************************************
  40 .\"
  41 .\" This file was generated with po4a. Translate the source file.
  42 .\"
  43 .\"*******************************************************************
  44 .TH RECV 2 2011\-09\-16 Linux "Linux Programmer's Manual"
  45 .SH 名前
  46 recv, recvfrom, recvmsg \- ソケットからメッセージを受け取る
  47 .SH 書式
  48 .\" .B #include <sys/uio.h>
  49 .\" .br
  50 .nf
  51 \fB#include <sys/types.h>\fP
  52 .br
  53 \fB#include <sys/socket.h>\fP
  54 .sp
  55 \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
  56 .sp
  57 \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
  58 \fB                 struct sockaddr *\fP\fIsrc_addr\fP\fB, socklen_t *\fP\fIaddrlen\fP\fB);\fP
  59 .sp
  60 \fBssize_t recvmsg(int \fP\fIsockfd\fP\fB, struct msghdr *\fP\fImsg\fP\fB, int \fP\fIflags\fP\fB);\fP
  61 .fi
  62 .SH 説明
  63 \fBrecvfrom\fP()  と \fBrecvmsg\fP()  コールは、ソケットからメッセージを受け取るのに使用する。
  64 またソケットのデータ受信にも使うことができ、 このときソケットは接続指向 (connection\-oriened) であってもなくてもよい。
  65 .PP
  66 .\" (Note: for datagram sockets in both the UNIX and Internet domains,
  67 .\" .I src_addr
  68 .\" is filled in.
  69 .\" .I src_addr
  70 .\" is also filled in for stream sockets in the UNIX domain, but is not
  71 .\" filled in for stream sockets in the Internet domain.)
  72 .\" [The above notes on AF_UNIX and AF_INET sockets apply as at
  73 .\" Kernel 2.4.18. (MTK, 22 Jul 02)]
  74 \fIsrc_addr\fP が NULL 以外で、下層のプロトコルから送信元アドレスが分かる場合、 \fIsrc_addr\fP
  75 にはこの送信元アドレスが入れられる。 \fIsrc_addr\fP が NULL の場合、 \fIsrc_addr\fP には何も入らない。この場合、
  76 \fIaddrlen\fP は使用されず、この引き数は NULL にしておくべきである。 引き数 \fIaddrlen\fP
  77 は入出力両用の引き数である。呼び出し時には、呼び出し元が \fIsrc_addr\fP に割り当てたバッファの大きさで初期化しておくべきである。
  78 返ってくる時には、送信元アドレスの実際の大きさに変更される。 渡されたバッファが小さ過ぎる場合には、返されるアドレスの末尾は
  79 切り詰められる。この場合には、 \fIaddrlen\fP では、呼び出し時に渡された値よりも大きな値が返される。
  80 .PP
  81 \fBrecv\fP()  コールは通常 \fI接続済みの (connected)\fP ソケット (\fBconnect\fP(2)  を参照) についてのみ使用され、
  82 \fIsrc_addr\fP 引き数に NULL を指定した \fBrecvfrom\fP()  と等価である。
  83 .PP
  84 これらの三つのルーチンはいずれも、成功した場合にはメッセージの長さを返す。 メッセージが長過ぎて指定されたバッファに入り切らなかった場合には、
  85 メッセージを受信したソケットの種類によっては余分のバイトが捨てられる かもしれない。
  86 .PP
  87 ソケットに受け取るメッセージが存在しなかった場合、 受信用のコールはメッセージが到着するまで待つ。 ただし、ソケットが非停止 (nonblocking)
  88 に設定されていた場合 (\fBfcntl\fP(2)  を参照) は \-1 を返し、外部変数 \fIerrno\fP に \fBEAGAIN\fP か
  89 \fBEWOULDBLOCK\fP を設定する。 これらの受信用のコールは、受信したデータのサイズが要求したサイズに
  90 達するまで待つのではなく、何らかのデータを受信すると復帰する (受信されるデータの最大サイズは要求したサイズである)。
  91 .PP
  92 \fBselect\fP(2)  や \fBpoll\fP(2)  コールを使って、次のデータがいつ届くかを判断できる。
  93 .PP
  94 \fBrecv\fP()  コールの \fIflags\fP 引き数には、以下の値を 1つ以上、ビット単位の論理和 を取ったものを指定する:
  95 .TP
  96 \fBMSG_CMSG_CLOEXEC\fP (\fBrecvmsg\fP() のみ; Linux 2.6.23)
  97 (\fBunix\fP(7)  で説明されている)  \fBSCM_RIGHTS\fP 操作を使って UNIX ドメインのファイルディスクリプタ経由で受信した
  98 ファイルディスクリプタについて close\-on\-exec フラグをセットする。 このフラグは、 \fBopen\fP(2)  の \fBO_CLOEXEC\fP
  99 フラグと同じ理由で有用である。
 100 .TP
 101 \fBMSG_DONTWAIT\fP (Linux 2.2 以降)
 102 非停止 (nonblocking) 操作を有効にする。 操作が停止するような場合にエラー \fBEAGAIN\fP か \fBEWOULDBLOCK\fP
 103 で呼び出しが失敗する (\fBfcntl\fP(2)  の \fBF_SETFL\fP で \fBO_NONBLOCK\fP
 104 フラグを指定することによっても有効にできる)。
 105 .TP
 106 \fBMSG_ERRQUEUE\fP (Linux 2.2 以降)
 107 このフラグを指定すると、 キューに入れられたエラーをソケットのエラーキューから取りだせるようになる。 このエラーは補助メッセージに組み込まれて渡され、
 108 この補助メッセージの種別はプロトコルに依存する (IPv4 の場合は \fBIP_RECVERR\fP)。
 109 ユーザは十分なサイズのバッファを用意しなければならない。 補助メッセージに関するより詳細な情報は \fBcmsg\fP(3)  および \fBip\fP(7)
 110 を参照のこと。 エラーの原因となったオリジナルパケットのペイロードは、 \fImsg_iovec\fP 経由で通常のデータとして渡される。
 111 エラーを起こしたデータグラムのオリジナルの宛先アドレスは、 \fImsg_name\fP 経由で参照できる。
 112 .IP
 113 ローカルなエラーの場合はアドレスは渡されない
 114 (これは \fIcmsghdr\fP の \fIcmsg_len\fP メンバーでチェックできる)。
 115 受信エラーの場合は \fBMSG_ERRQUIE\fP が \fImsghdr\fP にセットされる。
 116 エラーが渡された後には、キューに入っている次のエラーに基いて、
 117 処理待ちのソケット・エラーが再生成され、次のソケット操作の際に渡される。
 118
 119 このエラーは \fIsock_extended_err\fP 構造体で提供される:
 120 .in +4n
 121 .nf
 122
 123 #define SO_EE_ORIGIN_NONE    0
 124 #define SO_EE_ORIGIN_LOCAL   1
 125 #define SO_EE_ORIGIN_ICMP    2
 126 #define SO_EE_ORIGIN_ICMP6   3
 127
 128 struct sock_extended_err
 129 {
 130     uint32_t ee_errno;   /* error number */
 131     uint8_t  ee_origin;  /* where the error originated */
 132     uint8_t  ee_type;    /* type */
 133     uint8_t  ee_code;    /* code */
 134     uint8_t  ee_pad;     /* padding */
 135     uint32_t ee_info;    /* additional information */
 136     uint32_t ee_data;    /* other data */
 137     /* More data may follow */
 138 };
 139
 140 struct sockaddr *SO_EE_OFFENDER(struct sock_extended_err *);
 141 .fi
 142 .in
 143 .IP
 144 \fIee_errno\fP にはキューに入れられたエラーの \fIerrno\fP が入っている。 \fIee_origin\fP
 145 にはエラーが発生した場所のオリジン・コード (origin code) が入っている。 他のフィールドはプロトコル依存である。
 146 \fBSO_EE_OFFENDER\fP マクロは、この補助的なメッセージを引き数に取って、
 147 エラーの発生したネットワークオブジェクトのアドレスへのポインタを返す。 アドレスが不明の場合には、 \fIsockaddr\fP の \fIsa_family\fP
 148 メンバーが \fBAF_UNSPEC\fP になっている。 \fIsockaddr\fP の他のフィールドは不定である。
 149 エラーの発生したパケットのペイロードは通常のデータとして渡される。
 150 .IP
 151 ローカルなエラーの場合はアドレスは渡されない
 152 (これは \fIcmsghdr\fP の \fIcmsg_len\fP メンバーでチェックできる)。
 153 受信エラーの場合は \fBMSG_ERRQUIE\fP が \fImsghdr\fP にセットされる。
 154 エラーが渡された後には、キューに入っている次のエラーに基いて、
 155 処理待ちのソケット・エラーが再生成され、次のソケット操作の際に渡される。
 156 .TP
 157 \fBMSG_OOB\fP
 158 このフラグは、通常のデータ・ストリームでは受信できない 帯域外 (out\-of\-band) データの受信を要求する。 プロトコルによっては、
 159 通常のデータ・キューの先頭に速達データを置くものがあるが、 そのようなプロトコルではこのフラグは使用できない。
 160 .TP
 161 \fBMSG_PEEK\fP
 162 このフラグを指定すると、 受信キューの最初のデータを返すとき、キューからデータを削除しない。
 163 したがって、この後でもう一度受信コールを呼び出すと、同じデータが返ることになる。
 164 .TP
 165 \fBMSG_TRUNC\fP (Linux 2.2 以降)
 166 raw ソケット (\fBAF_PACKET\fP)、 Internet datagram ソケット (Linux 2.4.27/2.6.8 以降)、
 167 netlink (Linux 2.6.22 以降) ソケットの場合、 パケットやデータグラムの長さが渡したバッファよりも長かった場合にも、
 168 パケットやデータグラムの実際の長さを返す。 UNIX ドメインソケット (\fBunix\fP(7))  ソケットについては実装されていない。
 169
 170 Internet ストリームソケットでの利用については \fBtcp\fP(7)  を参照。
 171 .TP
 172 \fBMSG_WAITALL\fP (Linux 2.2 以降)
 173 このフラグは、要求した量いっぱいのデータが到着するまで、 操作を停止 (block) するよう要求する。 但し、シグナルを受信したり、エラーや切断
 174 (disconnect) が発生したり、 次に受信されるデータが異なる型だったりした場合には、 要求した量よりデータが少なくても返ることがある。
 175 .PP
 176 \fBrecvmsg\fP()  コールは、直接渡す引き数の数を減らすために \fImsghdr\fP 構造体を使用する。この構造体は
 177 \fI<sys/socket.h>\fP で以下のように定義されている:
 178 .in +4n
 179 .nf
 180
 181 struct iovec {                    /* Scatter/gather array items */
 182     void  *iov_base;              /* Starting address */
 183     size_t iov_len;               /* Number of bytes to transfer */
 184 };
 185
 186 struct msghdr {
 187     void         *msg_name;       /* 追加のアドレス */
 188     socklen_t     msg_namelen;    /* アドレスのサイズ */
 189     struct iovec *msg_iov;        /* scatter/gather 配列 */
 190     size_t        msg_iovlen;     /* msg_iov の要素数 */
 191     void         *msg_control;    /* 補助データ (後述) */
 192     size_t        msg_controllen; /* 補助データバッファ長 */
 193     int           msg_flags;      /* 受信メッセージのフラグ */
 194 };
 195 .fi
 196 .in
 197 .PP
 198 \fImsg_name\fP と \fImsg_namelen\fP は、ソケットが接続されていない場合に送信元のアドレスを指定する。 名前が必要ない場合には
 199 \fImsg_name\fP に NULL ポインタを指定する。 \fImsg_iov\fP と \fImsg_iovlen\fP フィールドは \fBreadv\fP(2)
 200 に記述されているような分解/結合用のベクトル (scatter\-gather locations)  を指定する。 \fImsg_control\fP
 201 フィールドは \fImsg_controllen\fP の長さを持ち、他のプロトコル制御メッセージや 種々の補助データのためのバッファへのポインタである。
 202 \fBrecvmsg\fP()  を呼ぶ際には、 \fImsg_controllen\fP に \fImsg_control\fP
 203 のバッファの長さを入れておく必要がある。 コールが成功して返った場合、制御メッセージ列の長さが入っている。
 204 .PP
 205 メッセージの形式は以下の通り:
 206 .in +4n
 207 .nf
 208
 209 struct cmsghdr {
 210     socklen_t     cmsg_len;     /* data byte count, including hdr */
 211     int           cmsg_level;   /* originating protocol */
 212     int           cmsg_type;    /* protocol\-specific type */
 213 /* followed by
 214     unsigned char cmsg_data[]; */
 215 };
 216 .fi
 217 .in
 218 .PP
 219 補助データは、 \fBcmsg\fP(3)  に定義されたマクロ経由でのみアクセスすべきである。
 220 .PP
 221 例をあげると、 Linux はこの補助データのメカニズムを、 UNIX ドメインソケット上での拡張エラーや IP オプション、
 222 ファイル・ディスクリプタの受け渡しに利用している。
 223 .PP
 224 \fImsghdr\fP の \fImsg_flags\fP フィールドは \fBrecvmsg\fP()
 225 からのリターン時に設定される。ここにはいくつかのフラグが入る。
 226 .TP
 227 \fBMSG_EOR\fP
 228 これはレコードの終り (end\-of\-record) を示し、 返されたデータが完全なレコードであることを示す (一般的には
 229 \fBSOCK_SEQPACKET\fP 型のソケットで使用される)。
 230 .TP
 231 \fBMSG_TRUNC\fP
 232 データグラムが与えられたバッファより大きかったために、 データグラムのはみ出した部分が捨てられたことを示す。
 233 .TP
 234 \fBMSG_CTRUNC\fP
 235 補助データのためのバッファが不足したために、 制御データの一部が捨てられたことを示す。
 236 .TP
 237 \fBMSG_OOB\fP
 238 速達データや帯域外データを受信したことを示す。
 239 .TP
 240 \fBMSG_ERRQUEUE\fP
 241 データは受信しなかったが ソケットのエラー・キューから拡張エラーを受信したことを示す。
 242 .SH 返り値
 243 これらのコールは受信したバイト数を返す。 エラーの場合は \-1 を返す。 接続先が正しくシャットダウンを実行した場合は、返り値は 0 となる。
 244 .SH エラー
 245 これらはソケット層で発生する一般的なエラーである。 他のエラーが下層のプロトコル・モジュールで生成され、 返されるかもしれない。
 246 それらのマニュアルを参照すること。
 247 .TP
 248 \fBEAGAIN\fP または \fBEWOULDBLOCK\fP
 249 .\" Actually EAGAIN on Linux
 250 ソケットが非停止 (nonblocking) に設定されていて 受信操作が停止するような状況になったか、 受信に時間切れ (timeout)
 251 が設定されていて データを受信する前に時間切れになった。 POSIX.1\-2001 は、この場合にどちらのエラーを返すことも認めており、 これら 2
 252 つの定数が同じ値を持つことも求めていない。 したがって、移植性が必要なアプリケーションでは、両方の可能性を 確認すべきである。
 253 .TP
 254 \fBEBADF\fP
 255 引き数 \fIsockfd\fP が不正なディスクリプタである。
 256 .TP
 257 \fBECONNREFUSED\fP
 258 リモートのホストでネットワーク接続が拒否された (よくある理由としては、要求したサービスが起動されていないなどがある)。
 259 .TP
 260 \fBEFAULT\fP
 261 受信バッファへのポインタがプロセスのアドレス空間外を指している。
 262 .TP
 263 \fBEINTR\fP
 264 データを受信する前に、シグナルが配送されて割り込まれた。 \fBsignal\fP(7)  参照。
 265 .TP
 266 \fBEINVAL\fP
 267 .\" e.g., msg_namelen < 0 for recvmsg() or addrlen < 0 for recvfrom()
 268 不正な引き数が渡された。
 269 .TP
 270 \fBENOMEM\fP
 271 \fBrecvmsg\fP()  のためのメモリが確保できなかった。
 272 .TP
 273 \fBENOTCONN\fP
 274 ソケットに接続指向プロトコルが割り当てられており、 まだ接続されていない (\fBconnect\fP(2)  と \fBaccept\fP(2)
 275 を参照のこと)。
 276 .TP
 277 \fBENOTSOCK\fP
 278 引き数 \fIsockfd\fP がソケットを参照していない。
 279 .SH 準拠
 280 4.4BSD (これらの関数は 4.2BSD で現われた), POSIX.1\-2001。
 281 .LP
 282 POSIX.1\-2001 では、 \fBMSG_OOB\fP, \fBMSG_PEEK\fP, \fBMSG_WAITALL\fP フラグだけが記載されている。
 283 .SH 注意
 284 上記のプロトタイプは glibc2 にしたがっている。 Single UNIX Specification でも同様だが、 返り値の型が
 285 \fIssize_t\fP となっている (一方で 4.x BSD や libc4 や libc5 は全て \fIint\fP を使用している)。 \fIflags\fP
 286 引き数は 4.x BSD では \fIint\fP だが、libc4 と libc5 では \fIunsigned int\fP である。 \fIlen\fP 引き数は
 287 4.x BSD では \fIint\fP だが、 libc4 と libc5 では \fIsize_t\fP である。 \fIaddrlen\fP 引き数は 4.x
 288 BSD, libc4, libc5 では \fIint\ *\fP である。 現在の \fIsocklen_t\ *\fP は POSIX で発案された。
 289 \fBaccept\fP(2)  も参照すること。
 290
 291 .\" glibc bug raised 12 Mar 2006
 292 .\" http://sourceware.org/bugzilla/show_bug.cgi?id=2448
 293 .\" The problem is an underlying kernel issue: the size of the
 294 .\" __kernel_size_t type used to type this field varies
 295 .\" across architectures, but socklen_t is always 32 bits.
 296 POSIX.1\-2001 では、構造体 \fImsghdr\fP のフィールド \fImsg_controllen\fP は \fIsocklen_t\fP
 297 型であるべきだとされているが、 現在の glibc では \fIsize_t\fP 型である。
 298
 299 \fBrecvmmsg\fP(2)  には、一度の呼び出しでの複数のデータグラムに使用できる Linux 固有の システムコールに関する情報が書かれている。
 300 .SH 例
 301 \fBrecvfrom\fP()  の利用例が \fBgetaddrinfo\fP(3)  に記載されている。
 302 .SH 関連項目
 303 \fBfcntl\fP(2), \fBgetsockopt\fP(2), \fBread\fP(2), \fBrecvmmsg\fP(2), \fBselect\fP(2),
 304 \fBshutdown\fP(2), \fBsocket\fP(2), \fBcmsg\fP(3), \fBsockatmark\fP(3), \fBsocket\fP(7)