--- /dev/null
+.\" Copyright (c) 1983, 1991 The Regents of the University of California.
+.\" All rights reserved.
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\" notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\" notice, this list of conditions and the following disclaimer in the
+.\" documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\" must display the following acknowledgement:
+.\" This product includes software developed by the University of
+.\" California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\" may be used to endorse or promote products derived from this software
+.\" without specific prior written permission.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\"
+.\" Modified 1993-07-24 by Rik Faith <faith@cs.unc.edu>
+.\" Modified 1996-10-22 by Eric S. Raymond <esr@thyrsus.com>
+.\" Modified Oct 1998 by Andi Kleen
+.\" Modified Oct 2003 by aeb
+.\" Modified 2004-07-01 by mtk
+.\"
+.\"*******************************************************************
+.\"
+.\" This file was generated with po4a. Translate the source file.
+.\"
+.\"*******************************************************************
+.TH SEND 2 2012\-04\-23 Linux "Linux Programmer's Manual"
+.SH 名前
+send, sendto, sendmsg \- ソケットへメッセージを送る
+.SH 書式
+.nf
+\fB#include <sys/types.h>\fP
+\fB#include <sys/socket.h>\fP
+.sp
+\fBssize_t send(int \fP\fIsockfd\fP\fB, const void *\fP\fIbuf\fP\fB, size_t \fP\fIlen\fP\fB, int \fP\fIflags\fP\fB);\fP
+
+\fBssize_t sendto(int \fP\fIsockfd\fP\fB, const void *\fP\fIbuf\fP\fB, size_t \fP\fIlen\fP\fB, int \fP\fIflags\fP\fB,\fP
+\fB const struct sockaddr *\fP\fIdest_addr\fP\fB, socklen_t \fP\fIaddrlen\fP\fB);\fP
+
+\fBssize_t sendmsg(int \fP\fIsockfd\fP\fB, const struct msghdr *\fP\fImsg\fP\fB, int \fP\fIflags\fP\fB);\fP
+.fi
+.SH 説明
+システムコール \fBsend\fP(), \fBsendto\fP(), \fBsendmsg\fP() は、もう一方のソケットへメッセージを転送するのに使用される。
+.PP
+\fBsend\fP() は、ソケットが \fI接続された (connected)\fP 状態にある場合にのみ使用できる
+(つまり、どの相手に送信するかは既知である)。 \fBsend\fP() と \fBwrite\fP(2) の違いは、引き数に \fIflags\fP
+があるかどうかだけである。 引き数 \fIflags\fP にフラグが指定されない場合、 \fBsend\fP() は \fBwrite\fP(2) と等価である。
+また、
+
+ send(sockfd, buf, len, flags);
+
+は以下と等価である。
+
+ sendto(sockfd, buf, len, flags, NULL, 0);
+.PP
+引き数 \fIsockfd\fP は、データを送信するパケットのファイル・ディスクリプタである。
+.PP
+\fBsendto\fP() は、接続型 (connection\-mode) のソケット (\fBSOCK_STREAM\fP,
+\fBSOCK_SEQPACKET\fP) で 使用された場合、引き数 \fIdest_addr\fP と \fIaddrlen\fP は無視される (各々の引き数が
+NULL と 0 でない場合は \fBEISCONN\fP エラーも返される)。 また、ソケットが実際には接続されていなかった時には \fBENOTCONN\fP
+エラーが返される。 接続型のソケット以外で使用された場合は、接続先のアドレスは \fIdest_addr\fP で与えられ、そのサイズは \fIaddrlen\fP
+で指定される。 \fBsendmsg\fP() では、接続先のアドレスは \fImsg.msg_name\fP で与えられ、そのサイズは
+\fImsg.msg_namelen\fP で指定される。
+.PP
+\fBsend\fP() と \fBsendto\fP() では、メッセージは \fIbuf\fP に格納されており、その長さは \fIlen\fP であると解釈される。
+\fBsendmsg\fP() では、メッセージは 配列 \fImsg.msg_iov\fP の各要素が指す位置に格納されている。 \fBsendmsg\fP()
+では、補助データ (制御情報とも呼ばれる) を送信することもできる。
+.PP
+メッセージ長が長過ぎるために、そのソケットが使用するプロトコルでは、 メッセージをソケットに渡されたままの形で送信することができない場合、
+\fBEMSGSIZE\fP エラーが返され、そのメッセージは転送されない。
+.PP
+\fBsend\fP() では、配送の失敗の通知は明示的に行われる。 ローカル側でエラーが検出された場合は、返り値 \-1 として通知される。
+.PP
+メッセージがソケットの送信バッファに入れることができない場合、 \fBsend\fP() は通常は停止 (block) する (ソケットが非停止
+(nonblocking) I/O モード でない場合)。非停止モードの場合にはエラー \fBEAGAIN\fP か \fBEWOULDBLOCK\fP
+で失敗する。 いつデータをさらに送信できるようになるかを知るために、 \fBselect\fP(2) コールを使用することができる。
+.PP
+.\" FIXME ? document MSG_PROXY (which went away in 2.3.15)
+\fIflags\fP 引き数は、以下のフラグの (0 個以上の) ビット単位の論理和を とったものを指定する。
+.TP
+\fBMSG_CONFIRM\fP (Linux 2.3.15 以降)
+転送処理に進展があった、つまり相手側から成功の応答を受けたことをリンク層に 知らせる。リンク層がこの通知を受け取らなかった場合には、通常どおり
+(ユニキャスト ARP を使うなどの方法で) 近傍 (neighbor) の再検索を行う。 \fBSOCK_DGRAM\fP と \fBSOCK_RAW\fP
+のソケットに対してのみ有効で、現在のところ IPv4 と IPv6 のみ実装されている。 詳しくは \fBarp\fP(7) 参照のこと。
+.TP
+\fBMSG_DONTROUTE\fP
+パケットを送り出すのにゲートウェイを使用せず、 直接接続されているネットワーク上のホストだけに送る。 通常、このフラグは診断 (diagnostic)
+やルーティング・プログラムに よってのみ使用される。このフラグは、経路制御が行われるプロトコルファミリー
+に対してのみ定義されている。パケットソケットには定義されていない。
+.TP
+\fBMSG_DONTWAIT\fP (Linux 2.2 以降)
+非停止 (nonblocking) 操作を有効にする。操作が停止されるような場合には \fBEAGAIN\fP か \fBEWOULDBLOCK\fP
+を返すようにする (\fBfcntl\fP(2) の \fBF_SETFL\fP で \fBO_NONBLOCK\fP フラグを指定することによっても有効にできる)。
+.TP
+\fBMSG_EOR\fP (Linux 2.2 以降)
+レコードの終了を指示する (\fBSOCK_SEQPACKET\fP のようにこの概念に対応しているソケット種別のときに有効)。
+.TP
+\fBMSG_MORE\fP (Linux 2.4.4 以降)
+呼び出し元にさらに送るデータがあることを示す。 このフラグは TCP ソケットとともに使用され、 \fBTCP_CORK\fP
+ソケットオプションと同じ効果が得られる (\fBtcp\fP(7) を参照)。 \fBTCP_CORK\fP との違いは、このフラグを使うと呼び出し単位で
+この機能を有効にできる点である。
+
+Linux 2.6 以降では、このフラグは UDP ソケットでもサポートされており、
+このフラグ付きで送信された全てのデータを一つのデータグラムにまとめて 送信することを、カーネルに知らせる。まとめられたデータグラムは、
+このフラグを指定せずにこのシステムコールが実行された際に初めて送信される (\fBudp\fP(7) に記載されているソケットオプション
+\fBUDP_CORK\fP も参照)。
+.TP
+\fBMSG_NOSIGNAL\fP (Linux 2.2 以降)
+ストリーム指向のソケットで相手側が接続を切断した時に、エラーとして \fBSIGPIPE\fP を送信しないように要求する。この場合でも \fBEPIPE\fP
+は返される。
+.TP
+\fBMSG_OOB\fP
+\fI帯域外 (out\-of\-band)\fP データをサポートするソケット (例えば \fBSOCK_STREAM\fP) で \fI帯域外\fP
+データを送る。下位プロトコルも \fI帯域外\fP データをサポートしている必要がある。
+.PP
+\fImsghdr\fP 構造体の内容は以下の通り。 各フィールドの正確な記述については \fBrecv\fP(2) と以下の説明を参照すること。
+.in +4n
+.nf
+
+struct msghdr {
+ void *msg_name; /* 追加のアドレス */
+ socklen_t msg_namelen; /* アドレスのサイズ */
+ struct iovec *msg_iov; /* scatter/gather 配列 */
+ size_t msg_iovlen; /* msg_iov の要素数 */
+ void *msg_control; /* 補助データ (後述) */
+ size_t msg_controllen; /* 補助データバッファ長 */
+ int msg_flags; /* 受信メッセージのフラグ */
+};
+.fi
+.in
+.PP
+.\" Still to be documented:
+.\" Send file descriptors and user credentials using the
+.\" msg_control* fields.
+.\" The flags returned in msg_flags.
+\fImsg_control\fP と \fImsg_controllen\fP メンバーを使用して制御情報を送信することができる。
+カーネルが処理できる制御バッファのソケットあたりの最大長は、 \fI/proc/sys/net/core/optmem_max\fP の値に制限されている。
+\fBsocket\fP(7) を参照。
+.SH 返り値
+成功した場合、これらのシステムコールは送信されたバイト数を返す。 エラーの場合、 \-1 を返し、 \fIerrno\fP を適切に設定にする。
+.SH エラー
+これらはソケット層で発生する一般的なエラーである。これ以外に、下層の プロトコル・モジュールで生成されたエラーが返されるかもしれない。
+これらについては、それぞれのマニュアルを参照すること。
+.TP
+\fBEACCES\fP
+(UNIX ドメインソケットの場合; パス名で識別される。)
+
+ソケット・ファイルへの書き込み許可がなかったか、パス名へ到達するまでの
+ディレクトリのいずれかに対する検索許可がなかった。
+(\fBpath_resolution\fP(7) も参照のこと)
+.sp
+(UDP ソケットの場合) ユニキャストアドレスであるかのように、
+ネットワークアドレスやブロードキャストアドレスへの送信が試みられた。
+.TP
+\fBEAGAIN\fP または \fBEWOULDBLOCK\fP
+.\" Actually EAGAIN on Linux
+ソケットが非停止に設定されており、 要求された操作が停止した。 POSIX.1\-2001 は、この場合にどちらのエラーを返すことも認めており、 これら
+2 つの定数が同じ値を持つことも求めていない。 したがって、移植性が必要なアプリケーションでは、両方の可能性を 確認すべきである。
+.TP
+\fBEBADF\fP
+無効なディスクリプターが指定された。
+.TP
+\fBECONNRESET\fP
+接続が接続相手によりリセットされた。
+.TP
+\fBEDESTADDRREQ\fP
+ソケットが接続型 (connection\-mode) ではなく、 かつ送信先のアドレスが設定されていない。
+.TP
+\fBEFAULT\fP
+ユーザー空間として不正なアドレスがパラメーターとして指定された。
+.TP
+\fBEINTR\fP
+データが送信される前に、シグナルが発生した。 \fBsignal\fP(7) 参照。
+.TP
+\fBEINVAL\fP
+不正な引き数が渡された。
+.TP
+\fBEISCONN\fP
+接続型ソケットの接続がすでに確立していたが、受信者が指定されていた。 (現在のところ、この状況では、このエラーが返されるか、
+受信者の指定が無視されるか、のいずれかとなる)
+.TP
+\fBEMSGSIZE\fP
+.\" (e.g., SOCK_DGRAM )
+そのソケット種別 ではソケットに渡されたままの形でメッセージを送信する必要があるが、 メッセージが大き過ぎるため送信することができない。
+.TP
+\fBENOBUFS\fP
+ネットワーク・インターフェースの出力キューが一杯である。 一般的には、一時的な輻輳 (congestion) のためにインターフェースが
+送信を止めていることを意味する。 (通常、Linux ではこのようなことは起こらない。デバイスのキューが
+オーバーフローした場合にはパケットは黙って捨てられる)
+.TP
+\fBENOMEM\fP
+メモリが足りない。
+.TP
+\fBENOTCONN\fP
+ソケットが接続されておらず、接続先も指定されていない。
+.TP
+\fBENOTSOCK\fP
+引き数 \fIsockfd\fP はソケットではない。
+.TP
+\fBEOPNOTSUPP\fP
+引き数 \fIflags\fP のいくつかのビットが、そのソケット種別では不適切なものである。
+.TP
+\fBEPIPE\fP
+接続指向のソケットでローカル側が閉じられている。 この場合、 \fBMSG_NOSIGNAL\fP が設定されていなければ、プロセスには \fBSIGPIPE\fP
+も同時に送られる。
+.SH 準拠
+4.4BSD, SVr4, POSIX.1\-2001. (これらの関数コールは 4.2BSD で最初に登場した)。
+.LP
+POSIX.1\-2001 には、 \fBMSG_OOB\fP と \fBMSG_EOR\fP フラグだけが記載されている。 POSIX.1\-2008 では
+\fBMSG_NOSIGNAL\fP が規格に追加されている。 \fBMSG_CONFIRM\fP フラグは Linux での拡張である。
+.SH 注意
+上記のプロトタイプは Single UNIX Specification に従っている。 glibc2 も同様である。 \fIflags\fP 引き数は
+4.x BSD では \fIint\fP であり、 libc4 と libc5 では \fIunsigned int\fP である。 \fIlen\fP 引き数は 4.x
+BSD と libc4 では \fIint\fP であり、 libc5 では \fIsize_t\fP である。 \fIaddrlen\fP 引き数は 4.x BSD と
+libc4 と libc5 では \fIint\fP である。 \fBaccept\fP(2) も参照すること。
+
+.\" glibc bug raised 12 Mar 2006
+.\" http://sourceware.org/bugzilla/show_bug.cgi?id=2448
+.\" The problem is an underlying kernel issue: the size of the
+.\" __kernel_size_t type used to type this field varies
+.\" across architectures, but socklen_t is always 32 bits.
+POSIX.1\-2001 では、構造体 \fImsghdr\fP のフィールド \fImsg_controllen\fP は \fIsocklen_t\fP
+型であるべきだとされているが、 現在の glibc では \fIsize_t\fP 型である。
+
+\fBsendmmsg\fP(2) には、一度の呼び出しでの複数のデータグラムの送信に使用できる
+Linux 固有の システムコールに関する情報が書かれている。
+.SH バグ
+Linux は \fBENOTCONN\fP を返す状況で \fBEPIPE\fP を返すことがある。
+.SH 例
+\fBsendto\fP() の利用例が \fBgetaddrinfo\fP(3) に記載されている。
+.SH 関連項目
+\fBfcntl\fP(2), \fBgetsockopt\fP(2), \fBrecv\fP(2), \fBselect\fP(2), \fBsendfile\fP(2),
+\fBsendmmsg\fP(2), \fBshutdown\fP(2), \fBsocket\fP(2), \fBwrite\fP(2), \fBcmsg\fP(3),
+\fBip\fP(7), \fBsocket\fP(7), \fBtcp\fP(7), \fBudp\fP(7)
+.SH この文書について
+この man ページは Linux \fIman\-pages\fP プロジェクトのリリース 3.40 の一部
+である。プロジェクトの説明とバグ報告に関する情報は
+http://www.kernel.org/doc/man\-pages/ に書かれている。
OSDN Git Service
