フラグ引き数¶

MSG_CMSG_CLOEXEC (recvmsg() のみ; Linux 2.6.23)

(unix(7) で説明されている) SCM_RIGHTS 操作を使って UNIX ドメインのファイルディスクリプター経由で受信した ファイルディスクリプターについて close-on-exec フラグをセットする。 このフラグは、 open(2) の O_CLOEXEC フラグと同じ理由で有用である。

MSG_DONTWAIT (Linux 2.2 以降)

非停止 (nonblocking) 操作を有効にする。 操作が停止するような場合にエラー EAGAIN か EWOULDBLOCK で呼び出しが失敗する (fcntl(2) の F_SETFL で O_NONBLOCK フラグを指定することによっても有効にできる)。

MSG_ERRQUEUE (Linux 2.2 以降)

このフラグを指定すると、 キューに入れられたエラーをソケットのエラーキューから取りだせるようになる。 このエラーは補助メッセージに組み込まれて渡され、 この補助メッセージの種別はプロトコルに依存する (IPv4 の場合は IP_RECVERR)。 ユーザーは十分なサイズのバッファーを用意しなければならない。 補助メッセージに関するより詳細な情報は cmsg(3) および ip(7) を参照のこと。 エラーの原因となったオリジナルパケットのペイロードは、 msg_iovec 経由で通常のデータとして渡される。 エラーを起こしたデータグラムのオリジナルの宛先アドレスは、 msg_name 経由で参照できる。

ローカルなエラーの場合はアドレスは渡されない (これは cmsghdr の cmsg_len メンバーでチェックできる)。 受信エラーの場合は MSG_ERRQUIE が msghdr にセットされる。 エラーが渡された後には、キューに入っている次のエラーに基いて、 処理待ちのソケットエラーが再生成され、次のソケット操作の際に渡される。

このエラーは sock_extended_err 構造体で提供される:

#define SO_EE_ORIGIN_NONE    0
#define SO_EE_ORIGIN_LOCAL   1
#define SO_EE_ORIGIN_ICMP    2
#define SO_EE_ORIGIN_ICMP6   3
struct sock_extended_err
{
    uint32_t ee_errno;   /* error number */
    uint8_t  ee_origin;  /* where the error originated */
    uint8_t  ee_type;    /* type */
    uint8_t  ee_code;    /* code */
    uint8_t  ee_pad;     /* padding */
    uint32_t ee_info;    /* additional information */
    uint32_t ee_data;    /* other data */
    /* More data may follow */
};
struct sockaddr *SO_EE_OFFENDER(struct sock_extended_err *);
    

ee_errno にはキューに入れられたエラーの errno が入っている。 ee_origin にはエラーが発生した場所のオリジンコード (origin code) が入っている。 他のフィールドはプロトコル依存である。 SO_EE_OFFENDER マクロは、この補助的なメッセージを引き数に取って、 エラーの発生したネットワークオブジェクトのアドレスへのポインターを返す。 アドレスが不明の場合には、 sockaddr の sa_family メンバーが AF_UNSPEC になっている。 sockaddr の他のフィールドは不定である。 エラーの発生したパケットのペイロードは通常のデータとして渡される。

ローカルなエラーの場合はアドレスは渡されない (これは cmsghdr の cmsg_len メンバーでチェックできる)。 受信エラーの場合は MSG_ERRQUIE が msghdr にセットされる。 エラーが渡された後には、キューに入っている次のエラーに基いて、 処理待ちのソケットエラーが再生成され、次のソケット操作の際に渡される。

MSG_OOB

このフラグは、通常のデータストリームでは受信できない 帯域外 (out-of-band) データの受信を要求する。 プロトコルによっては、 通常のデータキューの先頭に速達データを置くものがあるが、 そのようなプロトコルではこのフラグは使用できない。

MSG_PEEK

このフラグを指定すると、 受信キューの最初のデータを返すとき、キューからデータを削除しない。 したがって、この後でもう一度受信コールを呼び出すと、同じデータが返ることになる。

MSG_TRUNC (Linux 2.2 以降)

raw ソケット (AF_PACKET)、 Internet datagram ソケット (Linux 2.4.27/2.6.8 以降)、 netlink (Linux 2.6.22 以降) ソケット、 UNIX datagram ソケット (Linux 3.4 以降) の場合、パケットやデータグラムの長さが渡したバッファーよりも長かった場合にも、 パケットやデータグラムの実際の長さを返す。

Internet ストリームソケットでの利用については tcp(7) を参照。

MSG_WAITALL (Linux 2.2 以降)

このフラグは、要求した量いっぱいのデータが到着するまで、 操作を停止 (block) するよう要求する。 但し、シグナルを受信したり、エラーや切断 (disconnect) が発生したり、 次に受信されるデータが異なる型だったりした場合には、 要求した量よりデータが少なくても返ることがある。

recvfrom()¶

src_addr が NULL 以外で、下層のプロトコルからメッセージの送信元アドレスが分かる場合、 この送信元アドレスが src_addr が指すバッファーに格納される。 この場合、 addrlen は入出力両用の引き数となる。 呼び出し前に、呼び出し元は src_addr に割り当てたバッファーの大きさで初期化しておくべきである。 返ってくる時には、 addrlen は送信元アドレスの実際の大きさに変更される。渡されたバッファーが小さ過ぎる場合には、返されるアドレスの末尾は 切り詰められる。この場合には、 addrlen では、呼び出し時に渡された値よりも大きな値が返される。

呼び出し元が送信元アドレスを必要としない場合は、 src_addr と addrlen には NULL を指定すべきである。

recv()¶

recvfrom(fd, buf, len, flags, NULL, 0));

recvmsg()¶

struct iovec {                    /* Scatter/gather array items */
    void  *iov_base;              /* Starting address */
    size_t iov_len;               /* Number of bytes to transfer */
};
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;      /* 受信メッセージのフラグ */
};

フィールド msg_name は、 ソケットが接続されていない場合に送信元アドレスを返すのに使用されるバッファーを指す。 このバッファーは呼び出し元が確保する。 呼び出し元は呼び出し前に msg_namelen にこのバッファーの大きさを設定しなければならない。 呼び出しが成功した場合、呼び出しから返って来た際には msg_namelen には返されるアドレスの長さが入っている。 アプリケーションが送信元アドレスを知る必要がない場合には、 msg_name に NULL を指定することができる。

msg_iov と msg_iovlen フィールドは scatter-gather 用の場所を指定する。 readv(2) に説明がある。

msg_control フィールドは msg_controllen の長さを持ち、他のプロトコル制御メッセージや 種々の補助データのためのバッファーへのポインターである。 recvmsg() を呼ぶ際には、 msg_controllen に msg_control のバッファーの長さを入れておく必要がある。 コールが成功して返った場合、制御メッセージ列の長さが入っている。

メッセージの形式は以下の通り:

struct cmsghdr {
    socklen_t     cmsg_len;     /* data byte count, including hdr */
    int           cmsg_level;   /* originating protocol */
    int           cmsg_type;    /* protocol-specific type */
/* followed by
    unsigned char cmsg_data[]; */
};

補助データは、 cmsg(3) に定義されたマクロ経由でのみアクセスすべきである。

例をあげると、 Linux はこの補助データのメカニズムを、 UNIX ドメインソケット上での拡張エラーや IP オプション、 ファイルディスクリプターの受け渡しに利用している。

msghdr の msg_flags フィールドは recvmsg() からのリターン時に設定される。ここにはいくつかのフラグが入る。

MSG_EOR

これはレコードの終り (end-of-record) を示し、 返されたデータが完全なレコードであることを示す (一般的には SOCK_SEQPACKET 型のソケットで使用される)。

MSG_TRUNC

データグラムが与えられたバッファーより大きかったために、 データグラムのはみ出した部分が捨てられたことを示す。

MSG_CTRUNC

補助データのためのバッファーが不足したために、 制御データの一部が捨てられたことを示す。

MSG_OOB

速達データや帯域外データを受信したことを示す。

MSG_ERRQUEUE

データは受信しなかったが ソケットのエラーキューから拡張エラーを受信したことを示す。