Internet Engineering Task Force (IETF) R. Stewart
Request for Comments: 6458 Adara Networks
Category: Informational M. Tuexen
ISSN: 2070-1721 Muenster Univ. of Appl. Sciences
K. Poon
Oracle Corporation
P. Lei
Cisco Systems, Inc.
V. Yasevich
HP
December 2011
Sockets API Extensions
for the Stream Control Transmission Protocol (SCTP)
Abstract
抽象
This document describes a mapping of the Stream Control Transmission Protocol (SCTP) into a sockets API. The benefits of this mapping include compatibility for TCP applications, access to new SCTP features, and a consolidated error and event notification scheme.
このドキュメントでは、ソケットAPIにストリーム制御伝送プロトコル（SCTP）のマッピングを説明しています。このマッピングのメリットは、TCPアプリケーションの互換性、新しいSCTP機能へのアクセス、および統合エラーおよびイベント通知の手法を採用しています。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6458.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6458で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................6
2. Data Types ......................................................8
3. One-to-Many Style Interface .....................................8
3.1. Basic Operation ............................................8
3.1.1. socket() ............................................9
3.1.2. bind() .............................................10
3.1.3. listen() ...........................................11
3.1.4. sendmsg() and recvmsg() ............................12
3.1.5. close() ............................................14
3.1.6. connect() ..........................................14
3.2. Non-Blocking Mode .........................................15
3.3. Special Considerations ....................................16
4. One-to-One Style Interface .....................................18
4.1. Basic Operation ...........................................18
4.1.1. socket() ...........................................19
4.1.2. bind() .............................................19
4.1.3. listen() ...........................................21
4.1.4. accept() ...........................................21
4.1.5. connect() ..........................................22
4.1.6. close() ............................................23
4.1.7. shutdown() .........................................23
4.1.8. sendmsg() and recvmsg() ............................24
4.1.9. getpeername() ......................................24
5. Data Structures ................................................25
5.1. The msghdr and cmsghdr Structures .........................25
5.2. Ancillary Data Considerations and Semantics ...............26
5.2.1. Multiple Items and Ordering ........................27
5.2.2. Accessing and Manipulating Ancillary Data ..........27
5.2.3. Control Message Buffer Sizing ......................28
5.3. SCTP msg_control Structures ...............................28
5.3.1. SCTP Initiation Structure (SCTP_INIT) ..............29
5.3.2. SCTP Header Information Structure
(SCTP_SNDRCV) - DEPRECATED .........................30
5.3.3. Extended SCTP Header Information Structure
(SCTP_EXTRCV) - DEPRECATED .........................33
5.3.4. SCTP Send Information Structure (SCTP_SNDINFO) .....35
5.3.5. SCTP Receive Information Structure (SCTP_RCVINFO) ..37
5.3.6. SCTP Next Receive Information Structure
(SCTP_NXTINFO) .....................................38
5.3.7. SCTP PR-SCTP Information Structure (SCTP_PRINFO) ...39
5.3.8. SCTP AUTH Information Structure (SCTP_AUTHINFO) ....40
5.3.9. SCTP Destination IPv4 Address Structure
(SCTP_DSTADDRV4) ...................................41
5.3.10. SCTP Destination IPv6 Address Structure
(SCTP_DSTADDRV6) ..................................41
6. SCTP Events and Notifications ..................................41
6.1. SCTP Notification Structure ...............................42
6.1.1. SCTP_ASSOC_CHANGE ..................................43
6.1.2. SCTP_PEER_ADDR_CHANGE ..............................45
6.1.3. SCTP_REMOTE_ERROR ..................................46
6.1.4. SCTP_SEND_FAILED - DEPRECATED ......................47
6.1.5. SCTP_SHUTDOWN_EVENT ................................48
6.1.6. SCTP_ADAPTATION_INDICATION .........................49
6.1.7. SCTP_PARTIAL_DELIVERY_EVENT ........................49
6.1.8. SCTP_AUTHENTICATION_EVENT ..........................50
6.1.9. SCTP_SENDER_DRY_EVENT ..............................51
6.1.10. SCTP_NOTIFICATIONS_STOPPED_EVENT ..................52
6.1.11. SCTP_SEND_FAILED_EVENT ............................52
6.2. Notification Interest Options .............................54
6.2.1. SCTP_EVENTS Option - DEPRECATED ....................54
6.2.2. SCTP_EVENT Option ..................................56
7. Common Operations for Both Styles ..............................57
7.1. send(), recv(), sendto(), and recvfrom() ..................57
7.2. setsockopt() and getsockopt() .............................59
7.3. read() and write() ........................................60
7.4. getsockname() .............................................60
7.5. Implicit Association Setup ................................61
8. Socket Options .................................................61
8.1. Read/Write Options ........................................63
8.1.1. Retransmission Timeout Parameters (SCTP_RTOINFO) ...63
8.1.2. Association Parameters (SCTP_ASSOCINFO) ............64
8.1.3. Initialization Parameters (SCTP_INITMSG) ...........66
8.1.4. SO_LINGER ..........................................66
8.1.5. SCTP_NODELAY .......................................66
8.1.6. SO_RCVBUF ..........................................67
8.1.7. SO_SNDBUF ..........................................67
8.1.8. Automatic Close of Associations (SCTP_AUTOCLOSE) ...67
8.1.9. Set Primary Address (SCTP_PRIMARY_ADDR) ............68
8.1.10. Set Adaptation Layer Indicator
(SCTP_ADAPTATION_LAYER) ...........................68
8.1.11. Enable/Disable Message Fragmentation
(SCTP_DISABLE_FRAGMENTS) ..........................68
8.1.12. Peer Address Parameters (SCTP_PEER_ADDR_PARAMS) ...69
8.1.13. Set Default Send Parameters
(SCTP_DEFAULT_SEND_PARAM) - DEPRECATED ............71
8.1.14. Set Notification and Ancillary Events
(SCTP_EVENTS) - DEPRECATED ........................72
8.1.15. Set/Clear IPv4 Mapped Addresses
(SCTP_I_WANT_MAPPED_V4_ADDR) ......................72
8.1.16. Get or Set the Maximum Fragmentation Size
(SCTP_MAXSEG) .....................................72
8.1.17. Get or Set the List of Supported HMAC
Identifiers (SCTP_HMAC_IDENT) .....................73
8.1.18. Get or Set the Active Shared Key
(SCTP_AUTH_ACTIVE_KEY) ............................74
8.1.19. Get or Set Delayed SACK Timer
(SCTP_DELAYED_SACK) ...............................74
8.1.20. Get or Set Fragmented Interleave
(SCTP_FRAGMENT_INTERLEAVE) ........................75
8.1.21. Set or Get the SCTP Partial Delivery Point
(SCTP_PARTIAL_DELIVERY_POINT) .....................77
8.1.22. Set or Get the Use of Extended Receive Info
(SCTP_USE_EXT_RCVINFO) - DEPRECATED ...............77
8.1.23. Set or Get the Auto ASCONF Flag
(SCTP_AUTO_ASCONF) ................................77
8.1.24. Set or Get the Maximum Burst (SCTP_MAX_BURST) .....78
8.1.25. Set or Get the Default Context (SCTP_CONTEXT) .....78
8.1.26. Enable or Disable Explicit EOR Marking
(SCTP_EXPLICIT_EOR) ...............................79
8.1.27. Enable SCTP Port Reusage (SCTP_REUSE_PORT) ........79
8.1.28. Set Notification Event (SCTP_EVENT) ...............79
8.1.29. Enable or Disable the Delivery of SCTP_RCVINFO
as Ancillary Data (SCTP_RECVRCVINFO) ..............79
8.1.30. Enable or Disable the Delivery of SCTP_NXTINFO
as Ancillary Data (SCTP_RECVNXTINFO) ..............80
8.1.31. Set Default Send Parameters
(SCTP_DEFAULT_SNDINFO) ............................80
8.1.32. Set Default PR-SCTP Parameters
(SCTP_DEFAULT_PRINFO) .............................80
8.2. Read-Only Options .........................................81
8.2.1. Association Status (SCTP_STATUS) ...................81
8.2.2. Peer Address Information
(SCTP_GET_PEER_ADDR_INFO) ..........................82
8.2.3. Get the List of Chunks the Peer Requires to
Be Authenticated (SCTP_PEER_AUTH_CHUNKS) ...........84
8.2.4. Get the List of Chunks the Local Endpoint Requires
to Be Authenticated (SCTP_LOCAL_AUTH_CHUNKS) .......84
8.2.5. Get the Current Number of Associations
(SCTP_GET_ASSOC_NUMBER) ............................85
8.2.6. Get the Current Identifiers of Associations
(SCTP_GET_ASSOC_ID_LIST) ...........................85
8.3. Write-Only Options ........................................85
8.3.1. Set Peer Primary Address
(SCTP_SET_PEER_PRIMARY_ADDR) .......................86
8.3.2. Add a Chunk That Must Be Authenticated
(SCTP_AUTH_CHUNK) ..................................86
8.3.3. Set a Shared Key (SCTP_AUTH_KEY) ...................86
8.3.4. Deactivate a Shared Key
(SCTP_AUTH_DEACTIVATE_KEY) .........................87
8.3.5. Delete a Shared Key (SCTP_AUTH_DELETE_KEY) .........88
9. New Functions ..................................................88
9.1. sctp_bindx() ..............................................88
9.2. sctp_peeloff() ............................................90
9.3. sctp_getpaddrs() ..........................................91
9.4. sctp_freepaddrs() .........................................92
9.5. sctp_getladdrs() ..........................................92
9.6. sctp_freeladdrs() .........................................93
9.7. sctp_sendmsg() - DEPRECATED ...............................93
9.8. sctp_recvmsg() - DEPRECATED ...............................94
9.9. sctp_connectx() ...........................................95
9.10. sctp_send() - DEPRECATED .................................96
9.11. sctp_sendx() - DEPRECATED ................................97
9.12. sctp_sendv() .............................................98
9.13. sctp_recvv() ............................................101
10. Security Considerations ......................................103
11. Acknowledgments ..............................................103
12. References ...................................................104
12.1. Normative References ....................................104
12.2. Informative References ..................................104
Appendix A. Example Using One-to-One Style Sockets ...............106
Appendix B. Example Using One-to-Many Style Sockets ..............109
The sockets API has provided a standard mapping of the Internet Protocol suite to many operating systems. Both TCP [RFC0793] and UDP [RFC0768] have benefited from this standard representation and access method across many diverse platforms. SCTP is a new protocol that provides many of the characteristics of TCP but also incorporates semantics more akin to UDP. This document defines a method to map the existing sockets API for use with SCTP, providing both a base for access to new features and compatibility so that most existing TCP applications can be migrated to SCTP with few (if any) changes.
ソケットAPIは、多くのオペレーティング・システムにインターネット・プロトコル・スイートの標準マッピングを提供してきました。 TCP [RFC0793]およびUDP [RFC0768]の両方が多くの多様なプラットフォーム間で、この標準表現とアクセス方法の恩恵を受けています。 SCTPは、TCPの特性の多くを提供する新しいプロトコルであるだけでなく、UDPに意味論より似組み込まれています。この文書では、ほとんどの既存のTCPアプリケーションは、（もしあれば）いくつかの変更をSCTPに移行できるように、新しい機能との互換性にアクセスするためのベースの両方を提供し、SCTPで使用するための既存のソケットAPIをマッピングする方法を定義します。
There are three basic design objectives:
三つの基本的な設計目標があります。
1. Maintain consistency with existing sockets APIs: We define a sockets mapping for SCTP that is consistent with other sockets API protocol mappings (for instance UDP, TCP, IPv4, and IPv6).
1.既存のソケットAPIとの整合性を維持：我々は（例えばUDP、TCP、のIPv4、及びIPv6のための）他のソケットAPIプロトコルマッピングと一致しているSCTP用ソケットのマッピングを定義します。
2. Support a one-to-many style interface: This set of semantics is similar to that defined for connectionless protocols, such as UDP. A one-to-many style SCTP socket should be able to control multiple SCTP associations. This is similar to a UDP socket, which can communicate with many peer endpoints. Each of these associations is assigned an association identifier so that an application can use the ID to differentiate them. Note that SCTP is connection-oriented in nature, and it does not support broadcast or multicast communications, as UDP does.
2. 1対多のスタイルのインターフェイスをサポートしています：意味のこのセットは、UDPなどのコネクションレス型プロトコルのために定義されたものと同様です。一対多スタイルのSCTPソケットは複数のSCTPアソシエーションを制御することができるはずです。これは、多くのピアエンドポイントと通信することができUDPソケットに似ています。アプリケーションがそれらを区別するためにIDを使用できるようにこれらの関連のそれぞれは、関連識別子を割り当てられます。 SCTPはコネクション指向の性質であることに注意してください、とUDPはないとして、それは、ブロードキャストやマルチキャスト通信をサポートしていません。
3. Support a one-to-one style interface: This interface supports a similar semantics as sockets for connection-oriented protocols, such as TCP. A one-to-one style SCTP socket should only control one SCTP association. One purpose of defining this interface is to allow existing applications built on other connection-oriented protocols to be ported to use SCTP with very little effort. Developers familiar with these semantics can easily adapt to SCTP. Another purpose is to make sure that existing mechanisms in most operating systems that support sockets, such as select(), should continue to work with this style of socket. Extensions are added to this mapping to provide mechanisms to exploit new features of SCTP.
3. 1対1形式のインターフェイスをサポートしています：このインタフェースは、TCPなどのコネクション指向のプロトコルのためのソケットと同様のセマンティクスをサポートしています。 1対1スタイルのSCTPソケットは、唯一のSCTPアソシエーションを制御する必要があります。このインタフェースを定義する1つの目的は、他の接続指向のプロトコルの上に構築された既存のアプリケーションは非常に少ない労力でSCTPを使用するように移植できるようにすることです。これらのセマンティクスに精通している開発者は簡単にSCTPに適応することができます。もう一つの目的は、（選択としてソケットをサポートするほとんどのオペレーティングシステムで既存のメカニズムは、）、ソケットのこのスタイルで作業を継続すべきであることを確認することです。拡張機能は、SCTPの新しい機能を活用するためのメカニズムを提供するために、このマッピングに追加されます。
Goals 2 and 3 are not compatible, so this document defines two modes of mapping, namely the one-to-many style mapping and the one-to-one style mapping. These two modes share some common data structures and operations, but will require the use of two different application programming styles. Note that all new SCTP features can be used with both styles of socket. The decision on which one to use depends mainly on the nature of the applications.
目標2及び3は、互換性がないので、この文書は、マッピングの二つのモード、すなわち、1対多スタイルマッピングと一対一のスタイルマッピングを定義します。これらの2つのモードは、いくつかの共通のデータ構造と操作を共有して、2つの異なるアプリケーション・プログラミング・スタイルを使用する必要があります。すべての新しいSCTP機能は、ソケットの両方のスタイルで使用することができることに注意してください。使用する1つ上の決定は、アプリケーションの性質に主に依存します。
A mechanism is defined to extract an SCTP association from a one-to-many style socket into a one-to-one style socket.
機構は一対一の様式ソケットに1対多スタイルソケットからSCTPアソシエーションを抽出するために定義されています。
Some of the SCTP mechanisms cannot be adequately mapped to an existing socket interface. In some cases, it is more desirable to have a new interface instead of using existing socket calls. Section 9 of this document describes these new interfaces.
SCTPメカニズムの一部が適切に既存のソケット・インタフェースにマッピングすることはできません。いくつかのケースでは、代わりに、既存のソケット呼び出しを使用しての新しいインターフェイスを持つことがより望ましいです。このドキュメントのセクション9は、これらの新しいインタフェースについて説明します。
Please note that some elements of the SCTP sockets API are declared as deprecated. During the evolution of this document, elements of the API were introduced, implemented, and later on replaced by other elements. These replaced elements are declared as deprecated, since they are still available in some implementations and the replacement functions are not. This applies especially to older versions of operating systems supporting SCTP. New SCTP socket implementations must implement at least the non-deprecated elements. Implementations intending interoperability with older versions of the API should also include the deprecated functions.
非推奨としてSCTPソケットAPIのいくつかの要素が宣言されていることに注意してください。このドキュメントの進化の間に、APIの要素は、導入された実装、および後に他の元素に置き換えられました。非推奨として、彼らはまだいくつかの実装で利用可能であり、交換用の機能ではないため、これらの置換要素は、宣言されています。これは特に、SCTPをサポートしているオペレーティング・システムの以前のバージョンに適用されます。新しいSCTPソケットの実装は、少なくとも非非推奨の要素を実装する必要があります。 APIの旧バージョンとの相互運用性を意図また、実装は非推奨の機能を含める必要があります。
Whenever possible, Portable Operating System Interface (POSIX) data types defined in [IEEE-1003.1-2008] are used: uintN_t means an unsigned integer of exactly N bits (e.g., uint16_t). This document also assumes the argument data types from POSIX when possible (e.g., the final argument to setsockopt() is a socklen_t value). Whenever buffer sizes are specified, the POSIX size_t data type is used.
可能な限り、[IEEE-1003.1から2008]で定義されたポータブルオペレーティングシステムインタフェース（POSIX）のデータ・タイプが使用される：uintN_tは正確にNビット（例えば、uint16_t）の符号なし整数を意味します。この文書はまた、POSIX可能な場合（例えば、最後の引数は（SETSOCKOPTする）のsocklen_t値）からの引数データ型を想定しています。バッファサイズが指定されているときはいつでも、POSIX size_tのデータ型が使用されています。
In the one-to-many style interface, there is a one-to-many relationship between sockets and associations.
1対多のスタイルのインターフェイスでは、ソケットと組合との間に1対多の関係があります。
A typical server in this style uses the following socket calls in sequence to prepare an endpoint for servicing requests:
このスタイルでの一般的なサーバーは要求を処理するためにエンドポイントを準備するために順番に次のソケット・コールを使用しています。
o socket()
Oソケット（）
o bind()
Oバインド（）
o listen()
O）（聞きます
o recvmsg()
入出力のrecvmsg（）
o sendmsg()
Oは、sendmsg（）
o close()
O閉じます（）
A typical client uses the following calls in sequence to set up an association with a server to request services:
典型的なクライアントがサービスを要求するために、サーバーとの関連付けを設定するにはシーケンス内の次の呼び出しを使用しています：
o socket()
Oソケット（）
o sendmsg()
Oは、sendmsg（）
o recvmsg()
入出力のrecvmsg（）
o close()
O閉じます（）
In this style, by default, all of the associations connected to the endpoint are represented with a single socket. Each association is assigned an association identifier (the type is sctp_assoc_t) so that an application can use it to differentiate among them. In some implementations, the peer endpoints' addresses can also be used for this purpose. But this is not required for performance reasons. If an implementation does not support using addresses to differentiate between different associations, the sendto() call can only be used to set up an association implicitly. It cannot be used to send data to an established association, as the association identifier cannot be specified.
このスタイルでは、デフォルトでは、エンドポイントに接続されている団体のすべてが単一のソケットで表現されています。アプリケーションがそれらの間を区別するためにそれを使用できるように、各アソシエーションは、（タイプsctp_assoc_tある）アソシエーション識別子が割り当てられます。いくつかの実装形態では、ピアエンドポイントのアドレスもこの目的のために使用することができます。しかし、これはパフォーマンス上の理由から必要とされていません。実装は異なる団体を区別するためにアドレスを使用してサポートしていない場合、のsendto（）の呼び出しは、暗黙的に関連付けを設定するために使用することができます。関連識別子を指定することができないように、確立されたアソシエーションにデータを送信するために使用することができません。
Once an association identifier is assigned to an SCTP association, that identifier will not be reused until the application explicitly terminates the use of the association. The resources belonging to that association will not be freed until that happens. This is similar to the close() operation on a normal socket. The only exception is when the SCTP_AUTOCLOSE option (Section 8.1.8) is set. In this case, after the association is terminated gracefully and automatically, the association identifier assigned to it can be reused. All applications using this option should be aware of this to avoid the possible problem of sending data to an incorrect peer endpoint.
アソシエーション識別子がSCTP協会に割り当てられると、アプリケーションが明示的に関連の使用を終了するまで、その識別子は再利用されることはありません。それが起こるまで、その関連付けに属するリソースが解放されません。これは、通常のソケットのクローズ（）の動作と同様です。 SCTP_AUTOCLOSEオプション（セクション8.1.8）が設定されている場合は例外です。この場合、アソシエーションが正常と自動的に終了した後、それに割り当てられた関連識別子を再利用することができます。このオプションを使用するすべてのアプリケーションは、間違ったピア・エンドポイントにデータを送信する可能性の問題を回避するために、このことを認識する必要があります。
If the server or client wishes to branch an existing association off to a separate socket, it is required to call sctp_peeloff() and to specify the association identifier. The sctp_peeloff() call will return a new one-to-one style socket that can then be used with recv() and send() functions for message passing. See Section 9.2 for more on branched-off associations.
サーバーまたはクライアントが別のソケットを切った既存の関連付けを分岐したい場合は、sctp_peeloff（）を呼び出すと、関連識別子を指定する必要があります。 sctp_peeloff（）の呼び出しは、その後のrecv（で使用することができ、新たな1対1のスタイルのソケットを返す）とメッセージパッシングのために（）関数を送信します。分岐オフ会の詳細については9.2節を参照してください。
Once an association is branched off to a separate socket, it becomes completely separated from the original socket. All subsequent control and data operations to that association must be done through the new socket. For example, the close() operation on the original socket will not terminate any associations that have been branched off to a different socket.
アソシエーションは、別個のソケットに分岐された後、元のソケットから完全に分離なります。その協会へのその後のすべての制御およびデータの操作は、新しいソケットを介して行う必要があります。例えば、元のソケットのクローズ（）オペレーションは、異なるソケットに分岐されている任意の関連付けを終了しません。
One-to-many style socket calls are discussed in more detail in the following subsections.
一対多スタイルのソケットコールは、以下のサブセクションで詳しく説明されています。
Applications use socket() to create a socket descriptor to represent an SCTP endpoint.
アプリケーションは、SCTP終点を表すソケット記述子を作成するためにソケットを（）を使用します。
The function prototype is
関数プロトタイプは、
int socket(int domain, int type, int protocol);
INTソケット（INTドメイン、int型、int型のプロトコル）。
and one uses PF_INET or PF_INET6 as the domain, SOCK_SEQPACKET as the type, and IPPROTO_SCTP as the protocol.
一つのプロトコルとしてPF_INETまたはPF_INET6ドメインとして、タイプとしてSOCK_SEQPACKET、およびIPPROTO_SCTPを使用します。
Here, SOCK_SEQPACKET indicates the creation of a one-to-many style socket.
ここで、SOCK_SEQPACKETは1対多のスタイルのソケットの作成を示します。
The function returns a socket descriptor, or -1 in case of an error.
関数は、ソケット記述子を戻し、または-1エラーの場合。
Using the PF_INET domain indicates the creation of an endpoint that can use only IPv4 addresses, while PF_INET6 creates an endpoint that can use both IPv6 and IPv4 addresses.
PF_INET6は、IPv6とIPv4の両方のアドレスを使用することができますエンドポイントを作成しながら、PF_INETドメインを使用すると、IPv4アドレスのみを使用することができますエンドポイントの作成を示します。
Applications use bind() to specify with which local address and port the SCTP endpoint should associate itself.
アプリケーションは、SCTP終点は、それ自体を関連付けるべきローカルアドレスとポートを指定するには、バインドを（）を使用します。
An SCTP endpoint can be associated with multiple addresses. To do this, sctp_bindx() is introduced in Section 9.1 to help applications do the job of associating multiple addresses. But note that an endpoint can only be associated with one local port.
SCTP終点は、複数のアドレスに関連付けることができます。これを行うには、と、sctp_bindx（）は、アプリケーションが複数のアドレスを関連付けるの仕事を助けるために、セクション9.1で導入されました。しかし、エンドポイントが一つだけのローカルポートに関連付けることができることに注意してください。
These addresses associated with a socket are the eligible transport addresses for the endpoint to send and receive data. The endpoint will also present these addresses to its peers during the association initialization process; see [RFC4960].
ソケットに関連付けられているこれらのアドレスは、データを送受信するエンドポイントの対象トランスポートアドレスです。エンドポイントはまた、関連の初期化プロセスの間にそのピアにこれらのアドレスを提示します。 [RFC4960]を参照してください。
After calling bind(), if the endpoint wishes to accept new associations on the socket, it must call listen() (see Section 3.1.3).
エンドポイントは、ソケットに新しいアソシエーションを許可したい場合）（バインドを呼び出した後、それは（）聞く呼び出す必要があります（3.1.3項を参照してください）。
The function prototype of bind() is
バインドの関数プロトタイプ（）であります
int bind(int sd, struct sockaddr *addr, socklen_t addrlen);
int型バインド（int型SD、sockaddr構造体の* addrの、のsocklen_t addrlenは）。
and the arguments are
そして、引数は、
sd: The socket descriptor returned by socket().
SD：ソケットから返されたソケット記述子（）。
addr: The address structure (struct sockaddr_in for an IPv4 address or struct sockaddr_in6 for an IPv6 address; see [RFC3493]).
ADDR：アドレス構造体（IPv6アドレスのIPv4アドレスまたは構造体SOCKADDR_IN6用構造体のsockaddr_in; [RFC3493]を参照）。
addrlen: The size of the address structure.
addrlenは：アドレス構造体のサイズ。
bind() returns 0 on success and -1 in case of an error.
バインド（）エラーの場合は成功時に0と-1を返します。
If sd is an IPv4 socket, the address passed must be an IPv4 address. If the sd is an IPv6 socket, the address passed can either be an IPv4 or an IPv6 address.
SDはIPv4ソケットである場合には、渡されたアドレスは、IPv4アドレスでなければなりません。 SDはIPv6ソケットである場合は、渡されたアドレスはIPv4またはIPv6のアドレスを指定できます。
Applications cannot call bind() multiple times to associate multiple addresses to an endpoint. After the first call to bind(), all subsequent calls will return an error.
アプリケーションは、エンドポイントに複数のアドレスを関連付けるために）（複数回バインドを呼び出すことはできません。最初の呼び出しは（）をバインドした後、後続のすべての呼び出しはエラーを返します。
If the IP address part of addr is specified as a wildcard (INADDR_ANY for an IPv4 address, or as IN6ADDR_ANY_INIT or in6addr_any for an IPv6 address), the operating system will associate the endpoint with an optimal address set of the available interfaces. If the IPv4 sin_port or IPv6 sin6_port is set to 0, the operating system will choose an ephemeral port for the endpoint.
ADDRのIPアドレス部分が（IPv4アドレスまたはIPv6アドレスのためのIN6ADDR_ANY_INIT又はIN6ADDR_ANYなどのためにINADDR_ANY）ワイルドカードとして指定されている場合、オペレーティングシステムは、利用可能なインターフェースの最適アドレスセットとエンドポイントを関連付けます。 IPv4またはIPv6 sin_portはのsin6_portが0に設定されている場合は、オペレーティング・システムは、エンドポイントの一時的なポートを選択します。
If bind() is not called prior to a sendmsg() call that initiates a new association, the system picks an ephemeral port and will choose an address set equivalent to binding with a wildcard address. One of those addresses will be the primary address for the association. This automatically enables the multi-homing capability of SCTP.
バインド（）を前に、新たな関連付けを開始しにsendmsg（）の呼び出しに呼び出されない場合、システムが一時的なポートをピックアップし、ワイルドカードアドレスとの結合に相当設定されたアドレスを選択します。これらのアドレスの一つは、協会の主なアドレスになります。これは自動的にSCTPのマルチホーミング機能を有効にします。
The completion of this bind() process does not allow the SCTP endpoint to accept inbound SCTP association requests. Until a listen() system call, described below, is performed on the socket, the SCTP endpoint will promptly reject an inbound SCTP INIT request with an SCTP ABORT.
このバインド（）プロセスの完了は、SCTP終点は、インバウンドSCTPアソシエーション要求を受け入れることはできません。以下で説明を聞く（）システムコールは、ソケット上で実行されるまでは、SCTP終点は、速やかにSCTPのABORTとのインバウンドSCTPのINIT要求を拒否します。
By default, a one-to-many style socket does not accept new association requests. An application uses listen() to mark a socket as being able to accept new associations.
デフォルトでは、1対多のスタイルのソケットは、新しいアソシエーション要求を受け付けません。アプリケーションは、新しい団体を受け入れることができるものとしてソケットをマークする）（聞いて使用しています。
The function prototype is
関数プロトタイプは、
int listen(int sd, int backlog);
int型（int型SD、int型のバックログ）聞きます。
and the arguments are
そして、引数は、
sd: The socket descriptor of the endpoint.
SD：エンドポイントのソケット記述子。
backlog: If backlog is non-zero, enable listening, else disable listening.
バックログ：バックログがゼロでない場合、リスニング、他の無効化リスニングを有効にします。
listen() returns 0 on success and -1 in case of an error.
（）エラーの場合は成功時に0と-1を返し聞きます。
Note that one-to-many style socket consumers do not need to call accept() to retrieve new associations. Calling accept() on a one-to-many style socket should return EOPNOTSUPP. Rather, new associations are accepted automatically, and notifications of the new associations are delivered via recvmsg() with the SCTP_ASSOC_CHANGE event (if these notifications are enabled). Clients will typically not call listen(), so that they can be assured that only actively initiated associations are possible on the socket. Server or peer-to-peer sockets, on the other hand, will always accept new associations, so a well-written application using server one-to-many style sockets must be prepared to handle new associations from unwanted peers.
1対多のスタイルのソケット消費者が新しい関連付けを取得するためにaccept（）を呼び出す必要がないことに注意してください。 1対多のスタイルのソケットにaccept（）を呼び出すと、EOPNOTSUPPを返す必要があります。むしろ、新しい関連付けは自動的に受け入れられ、新団体の通知は（これらの通知が有効になっている場合）SCTP_ASSOC_CHANGEイベントとのrecvmsg（）を介して配信されています。クライアントは通常、彼らは唯一積極的に開始した団体は、ソケット上で可能であることを保証することができるように、聞く（）を呼び出すことはありません。サーバまたはピア・ツー・ピアのソケットは、他の一方で、常に新しいアソシエーションを許可しますので、サーバ1対多のスタイルのソケットを使用して、よく書かれたアプリケーションは、不要なピアから新しい関連付けを処理するために準備する必要があります。
Also note that the SCTP_ASSOC_CHANGE event provides the association identifier for a new association, so if applications wish to use the association identifier as a parameter to other socket calls, they should ensure that the SCTP_ASSOC_CHANGE event is enabled.
またSCTP_ASSOC_CHANGEイベントは新しいアソシエーションのアソシエーション識別子を提供することに留意されたいので、アプリケーションは他のソケット呼び出しのパラメータとしてアソシエーション識別子を使用したい場合、彼らはSCTP_ASSOC_CHANGEイベントが有効になっていることを確認する必要があります。
An application uses the sendmsg() and recvmsg() calls to transmit data to and receive data from its peer.
アプリケーションはsendmsgの（）とのrecvmsg（）にデータを送信し、そのピアからデータを受信するために呼び出しを使用します。
The function prototypes are
関数プロトタイプは、
ssize_t sendmsg(int sd, const struct msghdr *message, int flags);
ssize_tのにsendmsg（int型のSD、constの構造体のmsghdr *メッセージ、フラグをint型）;
and
そして
ssize_t recvmsg(int sd, struct msghdr *message, int flags);
ssize_tののrecvmsg（int型SD、構造体のmsghdr *メッセージ、int型のフラグ）;
using the following arguments:
次の引数を使用しました：
sd: The socket descriptor of the endpoint.
SD：エンドポイントのソケット記述子。
message: Pointer to the msghdr structure that contains a single user message and possibly some ancillary data. See Section 5 for a complete description of the data structures.
メッセージ：単一のユーザーのメッセージと、おそらくいくつかの補助的なデータが含まれているmsghdr構造体へのポインタ。データ構造の完全な説明については、セクション5を参照してください。
flags: No new flags are defined for SCTP at this level. See Section 5 for SCTP-specific flags used in the msghdr structure.
フラグ：いいえ新しいフラグは、このレベルでSCTPのために定義されています。 msghdr構造体で使用されるSCTP固有のフラグについては、セクション5を参照してください。
sendmsg() returns the number of bytes accepted by the kernel or -1 in case of an error. recvmsg() returns the number of bytes received or -1 in case of an error.
sendmsgの（）は-1エラーの場合にカーネルが受け付けたバイト数を返します。 recvmsg（）はエラーの場合に受信または-1バイト数を返します。
As described in Section 5, different types of ancillary data can be sent and received along with user data. When sending, the ancillary data is used to specify the sent behavior, such as the SCTP stream number to use. When receiving, the ancillary data is used to describe the received data, such as the SCTP stream sequence number of the message.
セクション5で説明したように、補助データの異なるタイプのユーザデータと共に送受信することができます。送信時、補助データは、使用するSCTPストリーム番号として、送信された動作を指定するために使用されます。受信した場合、補助データは、メッセージのSCTPストリームシーケンス番号として受信したデータを記述するために使用されます。
When sending user data with sendmsg(), the msg_name field in the msghdr structure will be filled with one of the transport addresses of the intended receiver. If there is no existing association between the sender and the intended receiver, the sender's SCTP stack will set up a new association and then send the user data (see Section 7.5 for more on implicit association setup). If sendmsg() is called with no data and there is no existing association, a new one will be established. The SCTP_INIT type ancillary data can be used to change some of the parameters used to set up a new association. If sendmsg() is called with NULL data, and there is no existing association but the SCTP_ABORT or SCTP_EOF flags are set as described in Section 5.3.4, then -1 is returned and errno is set to EINVAL. Sending a message using sendmsg() is atomic unless explicit end of record (EOR) marking is enabled on the socket specified by sd (see Section 8.1.26).
（）にsendmsgでユーザデータを送信する場合、msghdr構造体にはmsg_nameフィールドは、意図された受信機のトランスポート・アドレスのいずれかで満たされます。送信者と意図した受信機の間には既存の関連付けがない場合は、送信者のSCTPスタックは、新たな関連付けを設定し、ユーザーのデータを（暗黙の関連の設定の詳細については、セクション7.5を参照）を送信します。 sendmsg（）はデータなしで呼び出され、既存の関連付けが存在していない場合は、新しいものが確立されます。 SCTP_INITタイプの補助データは、新たな関連付けを設定するために使用されるパラメータの一部を変更するために使用することができます。セクション5.3.4に記載したようにsendmsg（）がNULLデータと呼ばれ、既存の関連付けが、SCTP_ABORT又はSCTP_EOFフラグが存在していないが設定されている場合、-1が返され、errnoがEINVALに設定されています。レコードの明示的な終了（EOR）マーキングがSDで指定されたソケットで有効になっていない限り）（にsendmsgを使用してメッセージを送信すると、（セクション8.1.26を参照してください）アトミックです。
If a peer sends a SHUTDOWN, an SCTP_SHUTDOWN_EVENT notification will be delivered if that notification has been enabled, and no more data can be sent to that association. Any attempt to send more data will cause sendmsg() to return with an ESHUTDOWN error. Note that the socket is still open for reading at this point, so it is possible to retrieve notifications.
ピアがSHUTDOWNを送信した場合、その通知が有効になっている、そしてそれ以上のデータは、その関連付けに送信できない場合、SCTP_SHUTDOWN_EVENT通知が配信されます。より多くのデータを送信しようとすると、sendmsgの（）がESHUTDOWNエラーで返すことになります。ソケットがまだこの時点で読み取るためのオープンであることに注意してくださいので、通知を取得することが可能です。
When receiving a user message with recvmsg(), the msg_name field in the msghdr structure will be populated with the source transport address of the user data. The caller of recvmsg() can use this address information to determine to which association the received user message belongs. Note that if SCTP_ASSOC_CHANGE events are disabled, applications must use the peer transport address provided in the msg_name field by recvmsg() to perform correlation to an association, since they will not have the association identifier.
）のrecvmsg（持つユーザメッセージを受信した場合、msghdr構造体にはmsg_nameフィールドは、ユーザデータのソーストランスポートアドレスが移入されます。 recvmsgの発信者は、（）受信したユーザメッセージが属する関連するかを決定するために、このアドレス情報を使用することができます。 SCTP_ASSOC_CHANGEイベントが無効になっている場合、彼らは関連識別子を持っていないので、アプリケーションは、協会に相関を実行するために）（のrecvmsgによってはmsg_nameフィールドで提供ピアトランスポート・アドレスを使用しなければならないことに注意してください。
If all data in a single message has been delivered, MSG_EOR will be set in the msg_flags field of the msghdr structure (see Section 5.1).
単一のメッセージ内のすべてのデータが配信されている場合は、MSG_EORはmsghdr構造体のmsg_flagsフィールドに設定されます（5.1節を参照してください）。
If the application does not provide enough buffer space to completely receive a data message, MSG_EOR will not be set in msg_flags. Successive reads will consume more of the same message until the entire message has been delivered, and MSG_EOR will be set.
アプリケーションは完全にデータメッセージを受信するために十分なバッファスペースを提供していない場合は、MSG_EORはmsg_flagsに設定されません。歴代全体メッセージが配信されるまで、同じメッセージの多くを消費します読み込み、MSG_EORが設定されます。
If the SCTP stack is running low on buffers, it may partially deliver a message. In this case, MSG_EOR will not be set, and more calls to recvmsg() will be necessary to completely consume the message. Only one message at a time can be partially delivered in any stream. The socket option SCTP_FRAGMENT_INTERLEAVE controls various aspects of what interlacing of messages occurs for both the one-to-one and the one-to-many style sockets. Please consult Section 8.1.20 for further details on message delivery options.
SCTPスタックはバッファが不足している場合は、それは部分的にメッセージを配信することができます。この場合、MSG_EORは設定されず、完全にメッセージを消費するのrecvmsgに複数のコール（）が必要となります。一度に1つのメッセージのみが部分的に任意のストリームで配信することができます。ソケットオプションSCTP_FRAGMENT_INTERLEAVEは両方とも1対1および1対多のスタイルのソケットに発生したメッセージのどのようなインターレースのさまざまな側面を制御します。メッセージ配信オプションの詳細については、セクション8.1.20を参照してください。
Applications use close() to perform graceful shutdown (as described in Section 10.1 of [RFC4960]) on all of the associations currently represented by a one-to-many style socket.
アプリケーションは、（[RFC4960]のセクション10.1で説明したように）現在、1対多のスタイルのソケットに代表される団体のすべてに正常なシャットダウンを実行するためにclose（）を使用します。
The function prototype is
関数プロトタイプは、
int close(int sd);
（SD int型）の近くのint;
and the argument is
そして引数があります
sd: The socket descriptor of the associations to be closed.
SD：クローズする団体のソケット記述子。
0 is returned on success and -1 in case of an error.
0はエラーの場合に成功し、-1に返されます。
To gracefully shut down a specific association represented by the one-to-many style socket, an application should use the sendmsg() call and include the SCTP_EOF flag. A user may optionally terminate an association non-gracefully by using sendmsg() with the SCTP_ABORT flag set and possibly passing a user-specified abort code in the data field. Both flags SCTP_EOF and SCTP_ABORT are passed with ancillary data (see Section 5.3.4) in the sendmsg() call.
正常一対多スタイルソケットで表される特定の関連付けをシャットダウンするために、アプリケーションはsendmsgの（）コールを使用してSCTP_EOFフラグを含むべきです。ユーザが任意に設定し、おそらくデータフィールドにユーザが指定したアボートコードを通過SCTP_ABORTフラグとにsendmsg（）を使用して、非正常アソシエーションを終了することができます。両フラグSCTP_EOFとSCTP_ABORTはsendmsgの（）の呼び出しで（5.3.4項を参照）の補助データで渡されます。
If sd in the close() call is a branched-off socket representing only one association, the shutdown is performed on that association only.
クローズ（）呼び出しでSDが唯一の関連付けを表す分岐オフソケットである場合、シャットダウンは、アソシエーション上でのみ実行されます。
An application may use the connect() call in the one-to-many style to initiate an association without sending data.
アプリケーションは、データを送信せずにアソシエーションを開始するために1対多スタイルで、Connect（）の呼び出しを使用してもよいです。
The function prototype is
関数プロトタイプは、
int connect(int sd, const struct sockaddr *nam, socklen_t len);
int型（int型のSD、constのsockaddr構造体の*ナム、socklen_tをLEN）を接続します。
and the arguments are
そして、引数は、
sd: The socket descriptor to which a new association is added.
SD：新しいアソシエーションが付加されたソケット記述子。
nam: The address structure (struct sockaddr_in for an IPv4 address or struct sockaddr_in6 for an IPv6 address; see [RFC3493]).
ナム：アドレス構造体（IPv4アドレスまたはIPv6アドレスの構造体SOCKADDR_IN6用構造体のsockaddr_in; [RFC3493]を参照）。
len: The size of the address.
LEN：アドレスのサイズ。
0 is returned on success and -1 in case of an error.
0はエラーの場合に成功し、-1に返されます。
Multiple connect() calls can be made on the same socket to create multiple associations. This is different from the semantics of connect() on a UDP socket.
複数の接続（）の呼び出しは、複数の関連付けを作成するために、同じソケット上で行うことができます。これは、UDPソケットの接続のセマンティクス（）と異なっています。
Note that SCTP allows data exchange, similar to T/TCP [RFC1644] (made Historic by [RFC6247]), during the association setup phase. If an application wants to do this, it cannot use the connect() call. Instead, it should use sendto() or sendmsg() to initiate an association. If it uses sendto() and it wants to change the initialization behavior, it needs to use the SCTP_INITMSG socket option before calling sendto(). Or it can use sendmsg() with SCTP_INIT type ancillary data to initiate an association without calling setsockopt(). Note that the implicit setup is supported for the one-to-many style sockets.
SCTPアソシエーションのセットアップフェーズ中にT / TCP [RFC1644]（[RFC6247]で歴史製）と同様のデータ交換を、可能にすることに留意されたいです。アプリケーションはこれをしたい場合は、それは、connect（）の呼び出しを使用することはできません。代わりに、アソシエーションを開始するためのsendto（）またはsendmsgの（）を使用すべきです。それはのsendto（）を使用し、それが初期化動作を変更したい場合、それはのsendtoを呼び出す前にSCTP_INITMSGソケットオプションを使用する必要があります（）。あるいは、それはのsetsockoptを呼び出すことなく、アソシエーションを開始するSCTP_INIT型補助データとにsendmsg（）を使用することができます（）。暗黙のセットアップは1対多のスタイルのソケットにサポートされていることに注意してください。
SCTP does not support half close semantics. This means that unlike T/TCP, MSG_EOF should not be set in the flags parameter when calling sendto() or sendmsg() when the call is used to initiate a connection. MSG_EOF is not an acceptable flag with an SCTP socket.
SCTPは、半分近くのセマンティクスをサポートしていません。これは、コールが接続を開始するために使用されたときのsendto（）またはsendmsgの（）を呼び出すときにT / TCPとは異なり、MSG_EOFがflagsパラメータで設定すべきではないことを意味します。 MSG_EOFはSCTPソケットと許容されるフラグではありません。
Some SCTP applications may wish to avoid being blocked when calling a socket interface function.
いくつかのSCTPアプリケーションは、ソケットインタフェース関数を呼び出すときにブロックされないように望むことができます。
Once a bind() call and/or subsequent sctp_bindx() calls are complete on a one-to-many style socket, an application may set the non-blocking option via a fcntl() (such as O_NONBLOCK). After setting the socket to non-blocking mode, the sendmsg() function returns immediately. The success or failure of sending the data message (with possible SCTP_INITMSG ancillary data) will be signaled by the SCTP_ASSOC_CHANGE event with SCTP_COMM_UP or SCTP_CANT_START_ASSOC. If user data could not be sent (due to an SCTP_CANT_START_ASSOC), the sender will also receive an SCTP_SEND_FAILED_EVENT event. Events can be received by the user calling recvmsg(). A server (having called listen()) is also notified of an association-up event via the reception of an SCTP_ASSOC_CHANGE with SCTP_COMM_UP via the calling of recvmsg() and possibly the reception of the first data message.
バインド（）コールおよび/またはそれに続くと、sctp_bindx（）呼び出しは1対多のスタイルのソケットに完了すると、アプリケーションは、（O_NONBLOCKなど））（fcntlのを経由して非ブロックオプションを設定することができます。非ブロッキングモードにソケットを設定した後、sendmsgの（）関数は直ちに戻ります。 （可能SCTP_INITMSG補助データとともに）データメッセージの送信の成功または失敗はSCTP_COMM_UP又はSCTP_CANT_START_ASSOCとSCTP_ASSOC_CHANGEイベントによって通知されるであろう。ユーザデータが（原因SCTP_CANT_START_ASSOCに）送ることができなかった場合、送信者はまたSCTP_SEND_FAILED_EVENTイベントを受信します。イベントは、ユーザーの呼び出しのrecvmsg（）で受信することができます。サーバ（呼び出された試聴（））ものrecvmsgの呼び出し（）と最初のデータメッセージの可能性受信介しSCTP_COMM_UPとSCTP_ASSOC_CHANGEの受信を介して、関連アップイベントが通知されます。
To shut down the association gracefully, the user must call sendmsg() with no data and with the SCTP_EOF flag set as described in Section 5.3.4. The function returns immediately, and completion of the graceful shutdown is indicated by an SCTP_ASSOC_CHANGE notification of type SCTP_SHUTDOWN_COMP (see Section 6.1.1). Note that this can also be done using the sctp_sendv() call described in Section 9.12.
正常アソシエーションをシャットダウンするために、ユーザは、sendmsgの（）データなしで、セクション5.3.4に記載されるように設定さSCTP_EOFフラグで呼び出す必要があります。関数は直ちに戻り、正常なシャットダウンの完了は、タイプSCTP_SHUTDOWN_COMPのSCTP_ASSOC_CHANGE通知（セクション6.1.1を参照）で示されています。これはまた、セクション9.12に記載sctp_sendv（）コールを使用して行うことができることに留意されたいです。
It is recommended that an application use caution when using select() (or poll()) for writing on a one-to-many style socket, because the interpretation of select() on write is implementation specific. Generally, a positive return on a select() on write would only indicate that one of the associations represented by the one-to-many style socket is writable. An application that writes after the select() returns may still block, since the association that was writable is not the destination association of the write call. Likewise, select() (or poll()) for reading from a one-to-many style socket will only return an indication that one of the associations represented by the socket has data to be read.
書き込みの選択の解釈は、（）実装固有のものですので、1対多のスタイルのソケットに書き込むための選択を使用した場合）（そのアプリケーションの使用は注意を推奨（またはポーリング（））です。一般的に、書き込みの選択にプラスのリターンは（）のみ1対多のスタイルのソケットに代表される団体の一つが書き込み可能であることを示します。書き込み可能であったアソシエーションので、依然としてブロックすることがselect（）の復帰後に書き込むアプリケーションは書き込みコールの宛先の関連はありません。同様に、（）を選択します（またはポーリング（））1対多のスタイルのソケットから読み込むためには、ソケットのみによって表される団体の一つが読み込まれるデータを持っているという指示を返します。
An application that wishes to know that a particular association is ready for reading or writing should either use the one-to-one style or use the sctp_peeloff() function (see Section 9.2) to separate the association of interest from the one-to-many style socket.
特に関連が読み取りまたは書き込みの準備ができていることを知りたいアプリケーションは、1対1のスタイルを使用するか、1対の関心の関連を分離するためにsctp_peeloff（）関数（9.2節を参照）を使用する必要がありますどちらか多くのスタイルのソケット。
Note that some implementations may have an extended select call, such as epoll or kqueue, that may escape this limitation and allow a select on a specific association of a one-to-many style socket, but this is an implementation-specific detail that a portable application cannot depend on.
いくつかの実装は、この制限を逃れると1対多スタイルソケットの特異的会合に選択可能にすることができるようなファイルディスクリプタやたkqueueなどの拡張選択コールを有していてもよいことに留意されたいが、これはその実装に固有の詳細でポータブルアプリケーションが依存することはできません。
The fact that a one-to-many style socket can provide access to many SCTP associations through a single socket descriptor has important implications for both application programmers and system programmers implementing this API. A key issue is how buffer space inside the sockets layer is managed. Because this implementation detail directly affects how application programmers must write their code to ensure correct operation and portability, this section provides some guidance to both implementers and application programmers.
1対多のスタイルのソケットは、単一ソケット記述を通じて多くのSCTP協会へのアクセスを提供することができるという事実は、このAPIを実装し、両方のアプリケーションプログラマとシステム・プログラマのための重要な意味を持ちます。重要な問題は、ソケット層内部のバッファスペースが管理されている方法です。この実装の詳細は、直接アプリケーションプログラマは、正しい操作とポータビリティを確保するためにコードを記述する必要がありますどのように影響するため、このセクションでは、実装とアプリケーションプログラマの両方にいくつかのガイダンスを提供します。
An important feature that SCTP shares with TCP is flow control. Specifically, a sender may not send data faster than the receiver can consume it.
TCPとSCTPの株式は、フロー制御であることが重要な特徴。具体的には、送信者はそれを消費する可能性が速く受信機よりデータを送信しないことがあります。
For TCP, flow control is typically provided for in the sockets API as follows. If the reader stops reading, the sender queues messages in the socket layer until the send socket buffer is completely filled. This results in a "stalled connection". Further attempts to write to the socket will block or return the error EAGAIN or EWOULDBLOCK for a non-blocking socket. At some point, either the connection is closed, or the receiver begins to read, again freeing space in the output queue.
以下のようにTCPの場合、フロー制御は、一般的に、ソケットAPI内で提供されます。読者が読んで停止した場合は送信ソケットバッファが完全に満たされるまで、送信側はソケット層でメッセージをキューに入れます。これが「失速接続」になります。さらなる試みは、ブロックまたは非ブロックソケットのエラーEAGAINまたはEWOULDBLOCKが返されるソケットに書き込みます。ある時点で、接続のいずれかが閉じている、または受信機は再び出力キューにスペースを解放し、読み始めます。
For one-to-one style SCTP sockets (this includes sockets descriptors that were separated from a one-to-many style socket with sctp_peeloff()), the behavior is identical. For one-to-many style SCTP sockets, there are multiple associations for a single socket, which makes the situation more complicated. If the implementation uses a single buffer space allocation shared by all associations, a single stalled association can prevent the further sending of data on all associations active on a particular one-to-many style socket.
一対一のスタイルSCTPソケット（これはsctp_peeloff（と1対多のスタイルのソケットから分離したソケット記述子を含む））のために、動作は同じです。一対多スタイルのSCTPソケットの場合、状況はより複雑になり、単一のソケットのための複数のアソシエーションがあります。実装はすべての関連付けによって共有される単一のバッファスペースの割り当てを使用する場合、単一ストールした関連付けは、特定の1対多スタイルソケット上のアクティブすべての関連付けにデータの送信を防止することができます。
For a blocking socket, it should be clear that a single stalled association can block the entire socket. For this reason, application programmers may want to use non-blocking one-to-many style sockets. The application should at least be able to send messages to the non-stalled associations.
ブロッキングソケットの場合は、単一ストールアソシエーション全体ソケットを遮断することができることは明らかです。このため、アプリケーションプログラマは、非ブロック1対多のスタイルのソケットを使用することをお勧めします。アプリケーションは、少なくとも非ストールした団体にメッセージを送信することができるはずです。
But a non-blocking socket is not sufficient if the API implementer has chosen a single shared buffer allocation for the socket. A single stalled association would eventually cause the shared allocation to fill, and it would become impossible to send even to non-stalled associations.
APIの実装は、ソケットのための単一の共有バッファの割り当てを選択した場合でも、非ブロッキングソケットは十分ではありません。単一ストールした関連付けは、最終的に共有割り当てがいっぱいに引き起こす、と言っても非失速団体に送信することは不可能になります。
The API implementer can solve this problem by providing each association with its own allocation of outbound buffer space. Each association should conceptually have as much buffer space as it would have if it had its own socket. As a bonus, this simplifies the implementation of sctp_peeloff().
APIの実装者は、アウトバウンドバッファ領域の独自の配分で、各関連を提供することによって、この問題を解決することができます。各協会は、概念的には、独自のソケットを持っていた場合、それは持っているだろうと同じくらいのバッファ容量が必要です。ボーナスとして、これは）（sctp_peeloffの実装を簡素化します。
To ensure that a given stalled association will not prevent other non-stalled associations from being writable, application programmers should either
与えられたストールした関連付けが書き込み可能であることから、他の非ストールした関連付けを妨げないことを保証するために、アプリケーションプログラマは、どちらかのはず
o demand that the underlying implementation dedicates independent buffer space reservation to each association (as suggested above), or
実装が各関連する独立したバッファスペース予約を捧げることO要求（上記で示唆されるように）、又は
o verify that their application-layer protocol does not permit large amounts of unread data at the receiver (this is true of some request-response protocols, for example), or
Oそれらのアプリケーション層プロトコル（これは例えば、いくつかの要求 - 応答プロトコルの真である）受信機において未読の大量のデータを許可しないことを確認し、又は
o use one-to-one style sockets for association, which may potentially stall (either from the beginning, or by using sctp_peeloff() before sending large amounts of data that may cause a stalled condition).
O潜在的に（最初から、または失速状態を引き起こす可能性があり、大量のデータを送信する前にsctp_peeloff（）を使用してのいずれか）ストールして関連付けのための1対1のスタイルのソケットを使用します。
The goal of this style is to follow as closely as possible the current practice of using the sockets interface for a connection-oriented protocol such as TCP. This style enables existing applications using connection-oriented protocols to be ported to SCTP with very little effort.
このスタイルの目標は、できるだけ、TCPなどのコネクション指向のプロトコルのためのソケットインタフェースを使用して、現在の慣行に従うことです。このスタイルは、コネクション指向のプロトコルを使用して、既存のアプリケーションは非常に少ない労力でSCTPに移植することができます。
One-to-one style sockets can be connected (explicitly or implicitly) at most once, similar to TCP sockets.
一対一のスタイルのソケットはTCPソケットに似て、高々度（明示的または暗黙的に）接続することができます。
Note that some new SCTP features and some new SCTP socket options can only be utilized through the use of sendmsg() and recvmsg() calls; see Section 4.1.8.
いくつかの新しいSCTP機能といくつかの新しいSCTPソケットオプションのみにsendmsg（）およびrecvmsgの（）の呼び出しを使用して利用できることに注意してください。セクション4.1.8を参照してください。
A typical one-to-one style server uses the following system call sequence to prepare an SCTP endpoint for servicing requests:
典型的な1対1スタイルのサーバーは、要求を処理するためにSCTPエンドポイントを準備するには、次のシステムコール・シーケンスを使用しています。
o socket()
Oソケット（）
o bind()
Oバインド（）
o listen()
O）（聞きます
o accept()
O）（受け入れます
The accept() call blocks until a new association is set up. It returns with a new socket descriptor. The server then uses the new socket descriptor to communicate with the client, using recv() and send() calls to get requests and send back responses.
受け入れる（）新しいアソシエーションが設定されるまでブロックを呼び出します。これは、新しいソケット記述子を返します。その後、サーバーはRECV（）とsend（）要求を取得し、レスポンスを返送への呼び出しを使用して、クライアントと通信するための新しいソケット記述子を使用しています。
Then it calls
そして、それが呼び出されます
o close()
O閉じます（）
to terminate the association.
関連付けを終了します。
A typical client uses the following system call sequence to set up an association with a server to request services:
典型的なクライアントがサービスを要求するために、サーバーとの関連付けを設定するには、次のシステムコール・シーケンスを使用しています。
o socket()
Oソケット（）
o connect()
O接続（）
After returning from the connect() call, the client uses send()/ sendmsg() and recv()/recvmsg() calls to send out requests and receive responses from the server.
Connect（）の呼び出しから戻った後、クライアントは）（）/にsendmsgを（送信使用とのrecv（）/のrecvmsg（）リクエストを送信し、サーバからの応答を受信するために呼び出します。
The client calls
クライアントコール
o close()
O閉じます（）
to terminate this association when done.
完了したら、この関連付けを終了します。
Applications call socket() to create a socket descriptor to represent an SCTP endpoint.
アプリケーションは、SCTP終点を表すソケット記述子を作成するためにソケットを（）を呼び出します。
The function prototype is
関数プロトタイプは、
int socket(int domain, int type, int protocol);
INTソケット（INTドメイン、int型、int型のプロトコル）。
and one uses PF_INET or PF_INET6 as the domain, SOCK_STREAM as the type, and IPPROTO_SCTP as the protocol.
一つのプロトコルとしてPF_INETまたはPF_INET6ドメインとして、タイプとしてSOCK_STREAM、及びIPPROTO_SCTPを使用します。
Here, SOCK_STREAM indicates the creation of a one-to-one style socket.
ここでは、SOCK_STREAMは1対1のスタイルのソケットの作成を示します。
Using the PF_INET domain indicates the creation of an endpoint that can use only IPv4 addresses, while PF_INET6 creates an endpoint that can use both IPv6 and IPv4 addresses.
PF_INET6は、IPv6とIPv4の両方のアドレスを使用することができますエンドポイントを作成しながら、PF_INETドメインを使用すると、IPv4アドレスのみを使用することができますエンドポイントの作成を示します。
Applications use bind() to specify with which local address and port the SCTP endpoint should associate itself.
アプリケーションは、SCTP終点は、それ自体を関連付けるべきローカルアドレスとポートを指定するには、バインドを（）を使用します。
An SCTP endpoint can be associated with multiple addresses. To do this, sctp_bindx() is introduced in Section 9.1 to help applications do the job of associating multiple addresses. But note that an endpoint can only be associated with one local port.
SCTP終点は、複数のアドレスに関連付けることができます。これを行うには、と、sctp_bindx（）は、アプリケーションが複数のアドレスを関連付けるの仕事を助けるために、セクション9.1で導入されました。しかし、エンドポイントが一つだけのローカルポートに関連付けることができることに注意してください。
These addresses associated with a socket are the eligible transport addresses for the endpoint to send and receive data. The endpoint will also present these addresses to its peers during the association initialization process; see [RFC4960].
ソケットに関連付けられているこれらのアドレスは、データを送受信するエンドポイントの対象トランスポートアドレスです。エンドポイントはまた、関連の初期化プロセスの間にそのピアにこれらのアドレスを提示します。 [RFC4960]を参照してください。
The function prototype of bind() is
バインドの関数プロトタイプ（）であります
int bind(int sd, struct sockaddr *addr, socklen_t addrlen);
int型バインド（int型SD、sockaddr構造体の* addrの、のsocklen_t addrlenは）。
and the arguments are
そして、引数は、
sd: The socket descriptor returned by socket().
SD：ソケットから返されたソケット記述子（）。
addr: The address structure (struct sockaddr_in for an IPv4 address or struct sockaddr_in6 for an IPv6 address; see [RFC3493]).
ADDR：アドレス構造体（IPv6アドレスのIPv4アドレスまたは構造体SOCKADDR_IN6用構造体のsockaddr_in; [RFC3493]を参照）。
addrlen: The size of the address structure.
addrlenは：アドレス構造体のサイズ。
If sd is an IPv4 socket, the address passed must be an IPv4 address. If sd is an IPv6 socket, the address passed can either be an IPv4 or an IPv6 address.
SDはIPv4ソケットである場合には、渡されたアドレスは、IPv4アドレスでなければなりません。 SDはIPv6ソケットである場合は、渡されたアドレスはIPv4またはIPv6のアドレスを指定できます。
Applications cannot call bind() multiple times to associate multiple addresses to the endpoint. After the first call to bind(), all subsequent calls will return an error.
アプリケーションは、エンドポイントに複数のアドレスを関連付けるために）（複数回バインドを呼び出すことはできません。最初の呼び出しは（）をバインドした後、後続のすべての呼び出しはエラーを返します。
If the IP address part of addr is specified as a wildcard (INADDR_ANY for an IPv4 address, or as IN6ADDR_ANY_INIT or in6addr_any for an IPv6 address), the operating system will associate the endpoint with an optimal address set of the available interfaces. If the IPv4 sin_port or IPv6 sin6_port is set to 0, the operating system will choose an ephemeral port for the endpoint.
ADDRのIPアドレス部分が（IPv4アドレスまたはIPv6アドレスのためのIN6ADDR_ANY_INIT又はIN6ADDR_ANYなどのためにINADDR_ANY）ワイルドカードとして指定されている場合、オペレーティングシステムは、利用可能なインターフェースの最適アドレスセットとエンドポイントを関連付けます。 IPv4またはIPv6 sin_portはのsin6_portが0に設定されている場合は、オペレーティング・システムは、エンドポイントの一時的なポートを選択します。
If bind() is not called prior to the connect() call, the system picks an ephemeral port and will choose an address set equivalent to binding with a wildcard address. One of these addresses will be the primary address for the association. This automatically enables the multi-homing capability of SCTP.
バインド（）を前に、Connect（）の呼び出しに呼び出されない場合、システムが一時的なポートをピックアップし、ワイルドカードアドレスとの結合に相当設定されたアドレスを選択します。これらのアドレスの一つは、協会の主なアドレスになります。これは自動的にSCTPのマルチホーミング機能を有効にします。
The completion of this bind() process does not allow the SCTP endpoint to accept inbound SCTP association requests. Until a listen() system call, described below, is performed on the socket, the SCTP endpoint will promptly reject an inbound SCTP INIT request with an SCTP ABORT.
このバインド（）プロセスの完了は、SCTP終点は、インバウンドSCTPアソシエーション要求を受け入れることはできません。以下で説明を聞く（）システムコールは、ソケット上で実行されるまでは、SCTP終点は、速やかにSCTPのABORTとのインバウンドSCTPのINIT要求を拒否します。
Applications use listen() to allow the SCTP endpoint to accept inbound associations.
アプリケーションは、SCTP終点は、インバウンドの関連付けを受け入れることができるように（）を使用聞きます。
The function prototype is
関数プロトタイプは、
int listen(int sd, int backlog);
int型（int型SD、int型のバックログ）聞きます。
and the arguments are
そして、引数は、
sd: The socket descriptor of the SCTP endpoint.
SD：SCTP終点のソケット記述子。
backlog: Specifies the max number of outstanding associations allowed in the socket's accept queue. These are the associations that have finished the four-way initiation handshake (see Section 5 of [RFC4960]) and are in the ESTABLISHED state. Note that a backlog of '0' indicates that the caller no longer wishes to receive new associations.
バックログは：ソケットの受け入れキューで許可される優れた団体の最大数を指定します。これらは、四方開始ハンドシェークを終了（[RFC4960]のセクション5を参照）、確立状態にあるている団体です。 「0」のバックログは、発信者は、もはや新しい関連付けを受信したいことを示していないことに注意してください。
listen() returns 0 on success and -1 in case of an error.
（）エラーの場合は成功時に0と-1を返し聞きます。
Applications use the accept() call to remove an established SCTP association from the accept queue of the endpoint. A new socket descriptor will be returned from accept() to represent the newly formed association.
アプリケーションは、エンドポイントの受け入れキューから確立SCTPアソシエーションを削除するために受け入れる（）の呼び出しを使用しています。新しいソケット記述子が新たに形成された関連付けを表すために受け入れる（）から返されます。
The function prototype is
関数プロトタイプは、
int accept(int sd, struct sockaddr *addr, socklen_t *addrlen);
int型（int型SD、sockaddr構造体の* addrの、のsocklen_t * addrlenは）を受け入れます。
and the arguments are
そして、引数は、
sd: The listening socket descriptor.
SD：リスニングソケット記述子。
addr: On return, addr (struct sockaddr_in for an IPv4 address or struct sockaddr_in6 for an IPv6 address; see [RFC3493]) will contain the primary address of the peer endpoint.
ADDR：戻ったとき、addrが（IPv6アドレスのIPv4アドレスまたは構造体SOCKADDR_IN6用構造体のsockaddr_in; [RFC3493]を参照）ピアエンドポイントの一次アドレスを含むことになります。
addrlen: On return, addrlen will contain the size of addr.
addrlenは：リターンで、addrlenははADDRのサイズが含まれています。
The function returns the socket descriptor for the newly formed association on success and -1 in case of an error.
関数は、エラーの場合に成功と-1に新たに形成されたアソシエーションのソケット記述子を戻します。
Applications use connect() to initiate an association to a peer.
アプリケーションは、ピアへの関連付けを開始するためにconnect（）を使用します。
The function prototype is
関数プロトタイプは、
int connect(int sd, const struct sockaddr *addr, socklen_t addrlen);
int型（int型のSD、constのsockaddr構造体の* addrの、のsocklen_t addrlenは）を接続します。
and the arguments are
そして、引数は、
sd: The socket descriptor of the endpoint.
SD：エンドポイントのソケット記述子。
addr: The peer's (struct sockaddr_in for an IPv4 address or struct sockaddr_in6 for an IPv6 address; see [RFC3493]) address.
ADDR：ピアの、アドレス（IPv6アドレスのIPv4アドレスまたは構造体SOCKADDR_IN6用構造体のsockaddr_inは[RFC3493]を参照します）。
addrlen: The size of the address.
addrlenは：アドレスのサイズ。
connect() returns 0 on success and -1 on error.
接続（）成功すると0を返し、エラーの場合は-1。
This operation corresponds to the ASSOCIATE primitive described in Section 10.1 of [RFC4960].
この操作は、[RFC4960]のセクション10.1で説明プリミティブ関連付けるように対応しています。
The number of outbound streams the new association has is stack dependent. Before connecting, applications can use the SCTP_INITMSG option described in Section 8.1.3 to change the number of outbound streams.
新しい関連付けがあり、発信ストリームの数は従属スタックです。接続する前に、アプリケーションは、アウトバウンドストリーム数を変更するには、セクション8.1.3で説明SCTP_INITMSGオプションを使用することができます。
If bind() is not called prior to the connect() call, the system picks an ephemeral port and will choose an address set equivalent to binding with INADDR_ANY and IN6ADDR_ANY_INIT for IPv4 and IPv6 sockets, respectively. One of the addresses will be the primary address for the association. This automatically enables the multi-homing capability of SCTP.
バインド（）がConnect（）の呼び出しの前に呼び出されていない場合、システムは、エフェメラルポートを選ぶとアドレスは、それぞれ、IPv4およびIPv6ソケットにINADDR_ANYとIN6ADDR_ANY_INITとの結合に相当する設定を選択します。アドレスの一つは、協会の主なアドレスになります。これは自動的にSCTPのマルチホーミング機能を有効にします。
Note that SCTP allows data exchange, similar to T/TCP [RFC1644] (made Historic by [RFC6247]), during the association setup phase. If an application wants to do this, it cannot use the connect() call. Instead, it should use sendto() or sendmsg() to initiate an association. If it uses sendto() and it wants to change the initialization behavior, it needs to use the SCTP_INITMSG socket option before calling sendto(). Or it can use sendmsg() with SCTP_INIT type ancillary data to initiate an association without calling setsockopt(). Note that the implicit setup is supported for the one-to-one style sockets.
SCTPアソシエーションのセットアップフェーズ中にT / TCP [RFC1644]（[RFC6247]で歴史製）と同様のデータ交換を、可能にすることに留意されたいです。アプリケーションはこれをしたい場合は、それは、connect（）の呼び出しを使用することはできません。代わりに、アソシエーションを開始するためのsendto（）またはsendmsgの（）を使用すべきです。それはのsendto（）を使用し、それが初期化動作を変更したい場合、それはのsendtoを呼び出す前にSCTP_INITMSGソケットオプションを使用する必要があります（）。あるいは、それはのsetsockoptを呼び出すことなく、アソシエーションを開始するSCTP_INIT型補助データとにsendmsg（）を使用することができます（）。暗黙のセットアップが1対1スタイルソケットではサポートされていることに注意してください。
SCTP does not support half close semantics. This means that unlike T/TCP, MSG_EOF should not be set in the flags parameter when calling sendto() or sendmsg() when the call is used to initiate a connection. MSG_EOF is not an acceptable flag with an SCTP socket.
SCTPは、半分近くのセマンティクスをサポートしていません。これは、コールが接続を開始するために使用されたときのsendto（）またはsendmsgの（）を呼び出すときにT / TCPとは異なり、MSG_EOFがflagsパラメータで設定すべきではないことを意味します。 MSG_EOFはSCTPソケットと許容されるフラグではありません。
Applications use close() to gracefully close down an association.
アプリケーションは、正常の関連付けを閉鎖する）（クローズを使用します。
The function prototype is
関数プロトタイプは、
int close(int sd);
（SD int型）の近くのint;
and the argument is
そして引数があります
sd: The socket descriptor of the association to be closed.
SD：関連のソケット記述子をクローズします。
close() returns 0 on success and -1 in case of an error.
（）エラーの場合に成功すると0と-1を返す近いです。
After an application calls close() on a socket descriptor, no further socket operations will succeed on that descriptor.
ソケット記述子に近いアプリケーションの呼び出し（）した後、それ以上のソケット操作は、その記述に成功しないだろう。
SCTP differs from TCP in that it does not have half close semantics. Hence, the shutdown() call for SCTP is an approximation of the TCP shutdown() call, and solves some different problems. Full TCP compatibility is not provided, so developers porting TCP applications to SCTP may need to recode sections that use shutdown(). (Note that it is possible to achieve the same results as half close in SCTP using SCTP streams.)
それは半分近い意味を持っていないという点でSCTPはTCPとは異なります。したがって、SCTPのシャットダウン（）の呼び出しは、TCPのシャットダウン（）呼び出しの近似値であり、いくつかの異なる問題を解決します。 SCTPにTCPアプリケーションを移植する開発者がシャットダウンを使用するセクションを再コーディングする必要があるかもしれませんので、完全なTCPの互換性は、提供されていません（）。 （SCTPストリームを使用して、SCTPにおける半分近くと同じ結果を達成することが可能であることに注意してください。）
The function prototype is
関数プロトタイプは、
int shutdown(int sd, int how);
int型のシャットダウン（int型SD、どのようにint型）;
and the arguments are
そして、引数は、
sd: The socket descriptor of the association to be closed.
SD：関連のソケット記述子をクローズします。
how: Specifies the type of shutdown. The values are as follows:
どのように：シャットダウンのタイプを指定します。値は次のとおりです。
SHUT_RD: Disables further receive operations. No SCTP protocol action is taken.
SHUT_RD：さらに受信操作を無効にします。いいえSCTPプロトコルアクションは実行されません。
SHUT_WR: Disables further send operations, and initiates the SCTP shutdown sequence.
SHUT_WR：さらに操作を送っ無効にして、SCTPのシャットダウンシーケンスを開始します。
SHUT_RDWR: Disables further send and receive operations, and initiates the SCTP shutdown sequence.
SHUT_RDWRは：さらに操作を送受信無効にし、SCTPのシャットダウンシーケンスを開始します。
shutdown() returns 0 on success and -1 in case of an error.
シャットダウン（）エラーの場合は成功時に0と-1を返します。
The major difference between SCTP and TCP shutdown() is that SCTP SHUT_WR initiates immediate and full protocol shutdown, whereas TCP SHUT_WR causes TCP to go into the half close state. SHUT_RD behaves the same for SCTP as for TCP. The purpose of SCTP SHUT_WR is to close the SCTP association while still leaving the socket descriptor open. This allows the caller to receive back any data that SCTP is unable to deliver (see Section 6.1.4 for more information) and receive event notifications.
SCTPとTCPのシャットダウン（）の主な違いは、TCP SHUT_WRが半分近い状態に行くためにTCPの原因となるのに対し、SCTP SHUT_WRは、即時かつ完全なプロトコルシャットダウンを開始していることです。 SHUT_RDはTCP用としてSCTPのために同じ動作をします。 SCTP SHUT_WRの目的は、まだオープンソケット記述を残したまま、SCTPアソシエーションを閉じることです。これは、呼び出し側がSCTPが（詳細については、6.1.4項を参照）を提供し、イベント通知を受け取ることができない任意のデータをバック受け取ることができます。
To perform the ABORT operation described in Section 10.1 of [RFC4960], an application can use the socket option SO_LINGER. SO_LINGER is described in Section 8.1.4.
[RFC4960]のセクション10.1で説明ABORT操作を実行するために、アプリケーションがソケットオプションSO_LINGERを使用することができます。 SO_LINGERは、セクション8.1.4に記載されています。
With a one-to-one style socket, the application can also use sendmsg() and recvmsg() to transmit data to and receive data from its peer. The semantics is similar to those used in the one-to-many style (see Section 3.1.4), with the following differences:
一対一の様式ソケットと、アプリケーションは、にデータを送信し、そのピアからデータを受信するためにsendmsg（）とのrecvmsg（）を使用することができます。セマンティクス以下の違いで、（3.1.4項を参照してください）1対多のスタイルで使用されるものと同様です。
1. When sending, the msg_name field in the msghdr is not used to specify the intended receiver; rather, it is used to indicate a preferred peer address if the sender wishes to discourage the stack from sending the message to the primary address of the receiver. If the socket is connected and the transport address given is not part of the current association, the data will not be sent, and an SCTP_SEND_FAILED_EVENT event will be delivered to the application if send failure events are enabled.
送信するとき1.体msghdrにはmsg_nameフィールドは、意図された受信機を指定するために使用されていません。むしろ、送信者が受信者のプライマリアドレスにメッセージを送信し、スタックを阻止することを望む場合、好ましいピアアドレスを示すために使用されます。ソケットが接続されており、所与のトランスポートアドレスは現在のアソシエーションの一部ではないされている場合は、データが送信されず、送信失敗イベントが有効になっている場合SCTP_SEND_FAILED_EVENTイベントがアプリケーションに配信されます。
2. Using sendmsg() on a non-connected one-to-one style socket for implicit connection setup may or may not work, depending on the SCTP implementation.
2.またはSCTPの実装に応じて、動作しない場合があり、暗黙的な接続設定のための非接続一対一様式のソケットには、sendmsg（）を使用。
Applications use getpeername() to retrieve the primary socket address of the peer. This call is for TCP compatibility and is not multi-homed. It may not work with one-to-many style sockets, depending on the implementation. See Section 9.3 for a multi-homed style version of the call.
アプリケーションは、ピアの主要なソケットアドレスを取得するために、getpeername（）を使用します。この呼び出しは、TCPの互換性のためのものであり、マルチホームではありません。これは、実装に依存し、1対多のスタイルのソケットでは動作しない場合があります。コールのマルチホームスタイルのバージョンについては、セクション9.3を参照してください。
The function prototype is
関数プロトタイプは、
int getpeername(int sd, struct sockaddr *address, socklen_t *len);
int型getpeername（int型SD、sockaddr構造体の*アドレス、のsocklen_t * LEN）;
and the arguments are
そして、引数は、
sd: The socket descriptor to be queried.
SD：照会するソケット記述子。
address: On return, the peer primary address is stored in this buffer. If the socket is an IPv4 socket, the address will be IPv4. If the socket is an IPv6 socket, the address will be either an IPv6 or IPv4 address.
住所：リターンで、ピアのプライマリアドレスは、このバッファに格納されます。ソケットはIPv4ソケットである場合、アドレスは、IPv4となります。ソケットはIPv6ソケットである場合、アドレスは、IPv6またはIPv4アドレスのどちらかになります。
len: The caller should set the length of address here. On return, this is set to the length of the returned address.
LEN：呼び出し側は、ここではアドレスの長さを設定する必要があります。リターンでは、これは、返されたアドレスの長さに設定されています。
getpeername() returns 0 on success and -1 in case of an error.
getpeername（）が成功すると0を返し、-1エラーの場合には。
If the actual length of the address is greater than the length of the supplied sockaddr structure, the stored address will be truncated.
アドレスの実際の長さは、供給されたsockaddr構造体の長さよりも大きい場合には、格納されたアドレスが切り捨てられます。
This section discusses important data structures that are specific to SCTP and are used with sendmsg() and recvmsg() calls to control SCTP endpoint operations and to access ancillary information and notifications.
このセクションでは、SCTPに固有の重要なデータ構造を説明し、sendmsgのに使用されている（）とのrecvmsg（）は、SCTP終点の操作を制御し、補助的な情報や通知にアクセスするために呼び出します。
The msghdr structure used in the sendmsg() and recvmsg() calls, as well as the ancillary data carried in the structure, is the key for the application to set and get various control information from the SCTP endpoint.
sendmsgのに使用msghdr構造体（）とのrecvmsg（）コール、ならびに構造で運ばれる補助データは、SCTPエンドポイントから各種制御情報を設定し、取得するアプリケーションのためのキーです。
The msghdr and the related cmsghdr structures are defined and discussed in detail in [RFC3542]. They are defined as
体msghdrおよび関連のcmsghdr構造は[RFC3542]で定義されており、詳細に説明します。彼らは次のように定義されています
struct msghdr {
void *msg_name; /* ptr to socket address structure */
socklen_t msg_namelen; /* size of socket address structure */
struct iovec *msg_iov; /* scatter/gather array */
int msg_iovlen; /* # elements in msg_iov */
void *msg_control; /* ancillary data */
socklen_t msg_controllen; /* ancillary data buffer length */
int msg_flags; /* flags on received message */
};
struct cmsghdr {
socklen_t cmsg_len; /* # bytes, including this header */
int cmsg_level; /* originating protocol */
int cmsg_type; /* protocol-specific type */
/* followed by unsigned char cmsg_data[]; */
};
In the msghdr structure, the usage of msg_name has been discussed in previous sections (see Sections 3.1.4 and 4.1.8).
msghdr構造体では、はmsg_nameの使用量は、（セクション3.1.4および4.1.8を参照）、前のセクションで説明されています。
The scatter/gather buffers, or I/O vectors (pointed to by the msg_iov field) are treated by SCTP as a single user message for both sendmsg() and recvmsg().
スキャッタ/バッファ、または（msg_iovフィールドによって指される）I / Oベクトルはsendmsgの（両方のための単一のユーザメッセージとしてSCTPによって処理されギャザー）とのrecvmsg（）。
The SCTP stack uses the ancillary data (msg_control field) to communicate the attributes, such as SCTP_RCVINFO, of the message stored in msg_iov to the socket endpoint. The different ancillary data types are described in Section 5.3.
SCTPスタックは、ソケットエンドポイントにmsg_iovに格納されたメッセージのようSCTP_RCVINFOなどの属性を、通信する補助データ（msg_controlフィールド）を使用します。別の補助的なデータタイプは、5.3節で説明されています。
The msg_flags are not used when sending a message with sendmsg().
（）にsendmsgを持つメッセージを送信するときmsg_flagsが使用されません。
If a notification has arrived, recvmsg() will return the notification in the msg_iov field and set the MSG_NOTIFICATION flag in msg_flags. If the MSG_NOTIFICATION flag is not set, recvmsg() will return data. See Section 6 for more information about notifications.
通知が届いた場合は、のrecvmsg（）はmsg_iovフィールドに通知を返すとmsg_flagsにMSG_NOTIFICATIONフラグを設定します。 MSG_NOTIFICATIONフラグが設定されていない場合、のrecvmsg（）データを返します。通知の詳細については、第6章を参照してください。
If all portions of a data frame or notification have been read, recvmsg() will return with MSG_EOR set in msg_flags.
データフレームまたは通知の全ての部分が読み取られた場合、のrecvmsg（）msg_flagsに設定MSG_EORと戻ります。
Programming with ancillary socket data (msg_control) contains some subtleties and pitfalls, which are discussed below.
補助ソケットデータとプログラム（msg_control）が以下に説明されるいくつかの微妙な落とし穴とを含んでいます。
Multiple ancillary data items may be included in any call to sendmsg() or recvmsg(); these may include multiple SCTP items, non-SCTP items (such as IP-level items), or both.
複数の補助的なデータ項目が（SENDMSGへの呼び出しに含まれていてもよい）またはのrecvmsg（）。これらは、複数のSCTP項目（例えば、IPレベルのアイテムのような）非SCTPのアイテム、またはその両方を含むことができます。
The ordering of ancillary data items (either by SCTP or another protocol) is not significant and is implementation dependent, so applications must not depend on any ordering.
補助的なデータ項目（どちらかSCTPまたは別のプロトコルによる）の順序は重要ではなく、実装に依存するので、アプリケーションは任意の順序に依存してはなりません。
SCTP_SNDRCV/SCTP_SNDINFO/SCTP_RCVINFO type ancillary data always corresponds to the data in the msghdr's msg_iov member. There can be only one such type of ancillary data for each sendmsg() or recvmsg() call.
SCTP_SNDRCV / SCTP_SNDINFO / SCTP_RCVINFOタイプの補助的なデータは常に体msghdrのmsg_iovメンバーのデータに対応します。それぞれにsendmsg（）またはのrecvmsg（）呼び出しのための補助データの唯一のようなタイプが存在することができます。
Applications can infer the presence of data or ancillary data by examining the msg_iovlen and msg_controllen msghdr members, respectively.
アプリケーションは、それぞれ、msg_iovlenとmsg_controllenのmsghdrのメンバーを調べることによって、データまたは補助データの存在を推測することができます。
Implementations may have different padding requirements for ancillary data, so portable applications should make use of the macros CMSG_FIRSTHDR, CMSG_NXTHDR, CMSG_DATA, CMSG_SPACE, and CMSG_LEN. See [RFC3542] and the SCTP implementation's documentation for more information. The following is an example, from [RFC3542], demonstrating the use of these macros to access ancillary data:
実装は、補助データのための異なるパディング要件を有することができるので、ポータブルアプリケーションでは、マクロCMSG_FIRSTHDR、CMSG_NXTHDR、CMSG_DATA、CMSG_SPACE、およびCMSG_LENを利用する必要があります。 [RFC3542]や詳細については、SCTPの実装のマニュアルを参照してください。以下は、補助データにアクセスするためにこれらのマクロの使用を示す、[RFC3542]から、実施例です。
struct msghdr msg;
struct cmsghdr *cmsgptr;
/* fill in msg */
/* call recvmsg() */
for (cmsgptr = CMSG_FIRSTHDR(&msg); cmsgptr != NULL;
cmsgptr = CMSG_NXTHDR(&msg, cmsgptr)) {
if (cmsgptr->cmsg_len == 0) {
/* Error handling */
break;
}
if (cmsgptr->cmsg_level == ... && cmsgptr->cmsg_type == ... ) {
u_char *ptr;
ptr = CMSG_DATA(cmsgptr);
/* process data pointed to by ptr */
}
}
The information conveyed via SCTP_SNDRCV/SCTP_SNDINFO/SCTP_RCVINFO ancillary data will often be fundamental to the correct and sane operation of the sockets application. This is particularly true for one-to-many style sockets, but also for one-to-one style sockets. For example, if an application needs to send and receive data on different SCTP streams, SCTP_SNDRCV/SCTP_SNDINFO/SCTP_RCVINFO ancillary data is indispensable.
SCTP_SNDRCV / SCTP_SNDINFO / SCTP_RCVINFO補助データを介して伝達される情報は、多くの場合、ソケットアプリケーションの正しいと正気動作の基本であろう。これは、1対多のスタイルのソケットのでなく、1対1スタイルソケットでは特にそうです。アプリケーションが異なるSCTPストリームでデータを送受信する必要がある場合、例えば、SCTP_SNDRCV / SCTP_SNDINFO / SCTP_RCVINFO補助データが不可欠です。
Given that some ancillary data is critical, and that multiple ancillary data items may appear in any order, applications should be carefully written to always provide a large enough buffer to contain all possible ancillary data that can be presented by recvmsg(). If the buffer is too small, and crucial data is truncated, it may pose a fatal error condition.
いくつかの補助的なデータが重要であり、その複数の補助的なデータ項目がどのような順序で表示される場合がありますことを考えると、アプリケーションは慎重に常に）のrecvmsg（によって提示されることができるすべての可能な補助データを格納するバッファ十分な大きさを提供するために記述する必要があります。バッファが小さすぎて、重要なデータが切り捨てられた場合、それは致命的なエラー状態を引き起こす可能性があります。
Thus, it is essential that applications be able to deterministically calculate the maximum required buffer size to pass to recvmsg(). One constraint imposed on this specification that makes this possible is that all ancillary data definitions are of a fixed length. One way to calculate the maximum required buffer size might be to take the sum of the sizes of all enabled ancillary data item structures, as calculated by CMSG_SPACE. For example, if we enabled SCTP_SNDRCV_INFO and IPV6_RECVPKTINFO [RFC3542], we would calculate and allocate the buffer size as follows:
これにより、アプリケーションが決定論のrecvmsgに渡すために必要な最大バッファサイズを計算することができることが必須です（）。これを可能にする、本明細書に課せられた一つの制約は、すべての補助データの定義が固定長であることです。最大必要なバッファサイズを計算するための一つの方法は、CMSG_SPACEによって計算されるように、すべての有効な補助的なデータ項目構造体のサイズの合計を取るかもしれません。我々はSCTP_SNDRCV_INFOとIPV6_RECVPKTINFO [RFC3542]を有効にした場合、例えば、次のように、我々は、バッファサイズを計算し、割り当てることになります。
size_t total;
void *buf;
total = CMSG_SPACE(sizeof(struct sctp_sndrcvinfo)) + CMSG_SPACE(sizeof(struct in6_pktinfo));
合計= CMSG_SPACE（はsizeof（構造体にsctp_sndrcvinfo））+ CMSG_SPACE（のsizeof（構造体in6_pktinfo））。
buf = malloc(total);
BUF = malloc関数（合計）。
We could then use this buffer (buf) for msg_control on each call to recvmsg() and be assured that we would not lose any ancillary data to truncation.
私たちは、その後のrecvmsgする呼び出しごとにmsg_controlのために、このバッファ（BUF）を使用することができます（）と私たちは切り捨てに任意の補助的なデータを失わないことを保証します。
A key element of all SCTP-specific socket extensions is the use of ancillary data to specify and access SCTP-specific data via the msghdr structure's msg_control member used in sendmsg() and recvmsg(). Fine-grained control over initialization and sending parameters are handled with ancillary data.
全てSCTP固有のソケット拡張機能の重要な要素は、msghdr構造体のmsg_controlのsendmsgのに使用される部材（）とのrecvmsg（）を介して指定する補助データの使用およびアクセスSCTP固有のデータです。初期きめ細かく制御し、送信パラメータは、補助データで処理されます。
Each ancillary data item is preceded by a struct cmsghdr (see Section 5.1), which defines the function and purpose of the data contained in the cmsg_data[] member.
各補助的データ項目はCMSG_DATA []メンバに含まれるデータの機能と目的を定義する構造体のcmsghdr（セクション5.1を参照）によって先行されます。
By default, on either style of socket, SCTP will pass no ancillary data. Specific ancillary data items can be enabled with socket options defined for SCTP; see Section 6.2.
デフォルトでは、ソケットのいずれかのスタイルに、SCTPには補助的なデータを渡しません。特定の補助的なデータ項目は、SCTP用に定義されたソケットオプションを有効にすることができます。 6.2節を参照してください。
Note that all ancillary types are of fixed length; see Section 5.2 for further discussion on this. These data structures use struct sockaddr_storage (defined in [RFC3493]) as a portable, fixed-length address format.
すべての補助的なタイプが固定長であることに留意されたいです。これについてさらなる議論については、セクション5.2を参照してください。これらのデータ構造は、携帯型、固定長アドレス形式として（[RFC3493]で定義された）構造体SOCKADDR_STORAGEを使用します。
Other protocols may also provide ancillary data to the socket layer consumer. These ancillary data items from other protocols may intermingle with SCTP data. For example, the IPv6 sockets API definitions ([RFC3542] and [RFC3493]) define a number of ancillary data items. If a sockets API consumer enables delivery of both SCTP and IPv6 ancillary data, they both may appear in the same msg_control buffer in any order. An application may thus need to handle other types of ancillary data besides those passed by SCTP.
他のプロトコルも、ソケット層の消費者への補助的なデータを提供することができます。他のプロトコルからのこれらの補助的なデータ項目は、SCTPデータと混在します。例えば、IPv6は、APIの定義（[RFC3542]及び[RFC3493]）補助的なデータ項目の数を定義するソケット。ソケットAPIの消費者はSCTPとIPv6の補助データの両方の配信を可能にした場合、それらの両方は、任意の順序で同じmsg_controlのバッファに表示されることがあります。アプリケーションは、このようにSCTPから渡されたもの以外の補助的な他のタイプのデータを処理する必要があるかもしれません。
The sockets application must provide a buffer large enough to accommodate all ancillary data provided via recvmsg(). If the buffer is not large enough, the ancillary data will be truncated and the msghdr's msg_flags will include MSG_CTRUNC.
ソケットアプリケーション）のrecvmsg（経由で提供される全ての補助データを収容するのに十分な大きさのバッファを提供しなければなりません。バッファの大きさが十分でない場合、補助データは切り捨てられますとのmsghdrのmsg_flagsはMSG_CTRUNCが含まれます。
This cmsghdr structure provides information for initializing new SCTP associations with sendmsg(). The SCTP_INITMSG socket option uses this same data structure. This structure is not used for recvmsg().
このcmsghdr構造体は、（）にsendmsgで新しいSCTP関連付けを初期化するための情報を提供します。 SCTP_INITMSGソケットオプションは、この同じデータ構造を使用しています。この構造は、（）のrecvmsgのために使用されていません。
+--------------+-----------+---------------------+
| cmsg_level | cmsg_type | cmsg_data[] |
+--------------+-----------+---------------------+
| IPPROTO_SCTP | SCTP_INIT | struct sctp_initmsg |
+--------------+-----------+---------------------+
The sctp_initmsg structure is defined below:
sctp_initmsg構造を以下のように定義されています。
struct sctp_initmsg {
uint16_t sinit_num_ostreams;
uint16_t sinit_max_instreams;
uint16_t sinit_max_attempts;
uint16_t sinit_max_init_timeo;
};
sinit_num_ostreams: This is an integer representing the number of streams to which the application wishes to be able to send. This number is confirmed in the SCTP_COMM_UP notification and must be verified, since it is a negotiated number with the remote endpoint. The default value of 0 indicates the use of the endpoint's default value.
sinit_num_ostreams：これは、アプリケーションが送信することができることを望むれるストリームの数を表す整数です。それは、リモートエンドポイントと交渉し数であるので、この数は、SCTP_COMM_UP通知で確認され、検証されなければなりません。 0のデフォルト値は、エンドポイントのデフォルト値の使用を示しています。
sinit_max_instreams: This value represents the maximum number of inbound streams the application is prepared to support. This value is bounded by the actual implementation. In other words, the user may be able to support more streams than the operating system. In such a case, the operating-system limit overrides the value requested by the user. The default value of 0 indicates the use of the endpoint's default value.
sinit_max_instreams：この値は、アプリケーションをサポートするために用意されたインバウンドストリームの最大数を表します。この値は、実際の実装によって制限されます。換言すれば、ユーザは、オペレーティングシステムよりもストリームをサポートすることができてもよいです。このような場合には、オペレーティング・システムの制限は、ユーザによって要求された値を上書き。 0のデフォルト値は、エンドポイントのデフォルト値の使用を示しています。
sinit_max_attempts: This integer specifies how many attempts the SCTP endpoint should make at resending the INIT. This value overrides the system SCTP 'Max.Init.Retransmits' value. The default value of 0 indicates the use of the endpoint's default value. This is normally set to the system's default 'Max.Init.Retransmit' value.
sinit_max_attempts：この整数は、多くの試みが、SCTP終点はINITを再送で作る方法を指定します。この値は、システムSCTP「Max.Init.Retransmits」の値を上書きします。 0のデフォルト値は、エンドポイントのデフォルト値の使用を示しています。これは通常、システムのデフォルトの「Max.Init.Retransmit」の値に設定されています。
sinit_max_init_timeo: This value represents the largest timeout or retransmission timeout (RTO) value (in milliseconds) to use in attempting an INIT. Normally, the 'RTO.Max' is used to limit the doubling of the RTO upon timeout. For the INIT message, this value may override 'RTO.Max'. This value must not influence 'RTO.Max' during data transmission and is only used to bound the initial setup time. A default value of 0 indicates the use of the endpoint's default value. This is normally set to the system's 'RTO.Max' value (60 seconds).
sinit_max_init_timeo：この値は、INITを試みる際に使用する最大のタイムアウトまたは再送タイムアウト（ミリ秒）（RTO）の値を表します。通常、「RTO.Max」は、タイムアウト時RTOの倍増を制限するために使用されます。 INITメッセージの場合、この値は「RTO.Max」を無効にすることができます。この値は、データ送信中に「RTO.Max」を影響を与えてはいけないとだけ初期セットアップ時間をバインドするために使用されます。 0のデフォルト値は、エンドポイントのデフォルト値の使用を示しています。これは通常、システムの「RTO.Max」の値（60秒）に設定されています。
This cmsghdr structure specifies SCTP options for sendmsg() and describes SCTP header information about a received message through recvmsg(). This structure mixes the send and receive path. SCTP_SNDINFO (described in Section 5.3.4) and SCTP_RCVINFO (described in Section 5.3.5) split this information. These structures should be used, when possible, since SCTP_SNDRCV is deprecated.
このcmsghdr構造体は、（）にsendmsg用SCTPオプションを指定し、（）のrecvmsgを介して受信したメッセージについてSCTPヘッダ情報が記載されています。この構造は、送信をミックスして、パスを受けます。 （セクション5.3.4を参照）SCTP_SNDINFOとSCTP_RCVINFO（セクション5.3.5に記載）は、この情報を分割します。 SCTP_SNDRCVが推奨されていませんので、これらの構造は、可能な場合は、使用すべきです。
+--------------+-------------+------------------------+
| cmsg_level | cmsg_type | cmsg_data[] |
+--------------+-------------+------------------------+
| IPPROTO_SCTP | SCTP_SNDRCV | struct sctp_sndrcvinfo |
+--------------+-------------+------------------------+
The sctp_sndrcvinfo structure is defined below:
sctp_sndrcvinfo構造を以下のように定義されています。
struct sctp_sndrcvinfo {
uint16_t sinfo_stream;
uint16_t sinfo_ssn;
uint16_t sinfo_flags;
uint32_t sinfo_ppid;
uint32_t sinfo_context;
uint32_t sinfo_timetolive;
uint32_t sinfo_tsn;
uint32_t sinfo_cumtsn;
sctp_assoc_t sinfo_assoc_id;
};
sinfo_stream: For recvmsg(), the SCTP stack places the message's stream number in this value. For sendmsg(), this value holds the stream number to which the application wishes to send this message. If a sender specifies an invalid stream number, an error indication is returned and the call fails.
sinfo_stream：recvmsgのために（）、SCTPスタックが、この値では、メッセージのストリーム番号を配置します。 sendmsg（）のために、この値は、アプリケーションがこのメッセージを送信することを望むたストリーム番号を保持します。送信者が無効なストリーム番号を指定した場合、エラー表示が返され、コールは失敗します。
sinfo_ssn: For recvmsg(), this value contains the stream sequence number that the remote endpoint placed in the DATA chunk. For fragmented messages, this is the same number for all deliveries of the message (if more than one recvmsg() is needed to read the message). The sendmsg() call will ignore this parameter.
sinfo_ssnは：のrecvmsg（）の場合、この値は、リモートエンドポイントがデータチャンクに配置されたストリームのシーケンス番号を含みます。断片化されたメッセージの場合、これは、メッセージのすべての配達のための同じ番号（複数のrecvmsg（）がメッセージを読むために必要な場合）です。 sendmsg（）呼び出しは、このパラメータは無視されます。
sinfo_flags: This field may contain any of the following flags and is composed of a bitwise OR of these values.
sinfo_flags：このフィールドには、以下のフラグのいずれかを含むことができ、ビット単位のORこれらの値で構成されています。
recvmsg() flags:
recvmsg（）フラグ：
SCTP_UNORDERED: This flag is present when the message was sent unordered.
SCTP UNORDERED：このフラグは、メッセージが順不同送信されたときに存在しています。
sendmsg() flags:
sendmsg（）フラグ：
SCTP_UNORDERED: This flag requests the unordered delivery of the message. If this flag is clear, the datagram is considered an ordered send.
SCTP UNORDERED：このフラグは、メッセージの順不同の配送を依頼します。このフラグがクリアされている場合、データグラムは、注文送信考えられています。
SCTP_ADDR_OVER: This flag, for a one-to-many style socket, requests that the SCTP stack override the primary destination address with the address found with the sendto/ sendmsg call.
SCTP_ADDR_OVER：このフラグは、1対多のスタイルのソケットのために、SCTPスタックはのsendto / sendmsgの呼び出しで見つかったアドレスでのプライマリ送信先アドレスを上書きすることを要求します。
SCTP_ABORT: Setting this flag causes the specified association to abort by sending an ABORT message to the peer. The ABORT chunk will contain an error cause of 'User Initiated Abort' with cause code 12. The cause-specific information of this error cause is provided in msg_iov.
SCTP_ABORT：このフラグを設定すると、ピアにABORTメッセージを送信することによって中止し、指定の関連付けを引き起こします。 ABORTチャンクはmsg_iovで提供され、このエラーの原因の原因に固有の情報原因コード12で「ユーザー主導中止」のエラー原因が含まれています。
SCTP_EOF: Setting this flag invokes the SCTP graceful shutdown procedure on the specified association. Graceful shutdown assures that all data queued by both endpoints is successfully transmitted before closing the association.
SCTP_EOF：このフラグを設定するには、指定された関連付けのSCTP正常なシャットダウン手順を起動します。グレースフルシャットダウンは両方のエンドポイントによってキューに入れられた全てのデータが正常に関連を閉じる前に送信されることを保証します。
SCTP_SENDALL: This flag, if set, will cause a one-to-many style socket to send the message to all associations that are currently established on this socket. For the one-to-one style socket, this flag has no effect.
SCTP_SENDALL：このフラグは、設定されている場合、1対多のスタイルのソケットは、現在このソケットに確立されているすべての関連付けにメッセージを送信するようになります。 1対1のスタイルのソケットの場合、このフラグは効果がありません。
sinfo_ppid: This value in sendmsg() is an unsigned integer that is passed to the remote end in each user message. In recvmsg(), this value is the same information that was passed by the upper layer in the peer application. Please note that the SCTP stack performs no byte order modification of this field. For example, if the DATA chunk has to contain a given value in network byte order, the SCTP user has to perform the htonl() computation.
sinfo_ppid：sendmsgのこの値は（）は、各ユーザのメッセージでリモートエンドに渡される符号なし整数です。 recvmsg（）で、この値は、ピアアプリケーションの上位レイヤによって渡された情報と同じ情報です。 SCTPスタックは、このフィールドのないバイト順の変更を行いませんので予めご了承ください。データチャンクは、ネットワークバイト順で指定された値を含む必要がある場合、例えば、SCTPユーザはhtonl（）計算を実行しなければなりません。
sinfo_context: This value is an opaque 32-bit context datum that is used in the sendmsg() function. This value is passed back to the upper layer if an error occurs on the send of a message and is retrieved with each undelivered message.
sinfo_context：この値は、sendmsg（）関数で使用される不透明な32ビットのコンテキストデータがあります。エラーは、メッセージの送信時に発生し、各未通知メッセージで取得された場合、この値は、上位層に戻されます。
sinfo_timetolive: For the sending side, this field contains the message's time to live, in milliseconds. The sending side will expire the message within the specified time period if the message has not been sent to the peer within this time period. This value will override any default value set using any socket option. Also note that the value of 0 is special in that it indicates no timeout should occur on this message.
sinfo_timetolive：送信側の場合、このフィールドはミリ秒単位で、生きるためのメッセージの時間が含まれています。メッセージがこの期間内にピアに送信されていない場合、送信側は、指定した時間内にメッセージを期限切れになります。この値は、任意のソケットオプションを使用して設定された任意のデフォルト値を上書きします。また、それはタイムアウトがこのメッセージには発生しませんを示しているという点で、0の値が特別であることに注意してください。
sinfo_tsn: For the receiving side, this field holds a Transmission Sequence Number (TSN) that was assigned to one of the SCTP DATA chunks. For the sending side, it is ignored.
sinfo_tsnは：受信側は、このフィールドは、SCTPデータチャンクの1つに割り当てられた送信シーケンス番号（TSN）を保持します。送信側では、それは無視されます。
sinfo_cumtsn: This field will hold the current cumulative TSN as known by the underlying SCTP layer. Note that this field is ignored when sending.
sinfo_cumtsn：基礎となるSCTP層によって知られているように、このフィールドには、現在の累積TSNを開催します。送信するときに、このフィールドは無視されることに注意してください。
sinfo_assoc_id: The association handle field, sinfo_assoc_id, holds the identifier for the association announced in the SCTP_COMM_UP notification. All notifications for a given association have the same identifier. This field is ignored for one-to-one style sockets.
sinfo_assoc_id：アソシエーションハンドルフィールド、sinfo_assoc_idは、SCTP_COMM_UP通知で発表会のための識別子を保持しています。与えられたアソシエーションのすべての通知は、同じ識別子を持っています。このフィールドは、1対1のスタイルのソケットでは無視されます。
An sctp_sndrcvinfo item always corresponds to the data in msg_iov.
sctp_sndrcvinfo項目は常にmsg_iovのデータに対応します。
5.3.3. Extended SCTP Header Information Structure (SCTP_EXTRCV) - DEPRECATED
5.3.3. 拡張SCTPヘッダー情報構造（SCTP_EXTRCV） - 非推奨
This cmsghdr structure specifies SCTP options for SCTP header information about a received message via recvmsg(). Note that this structure is an extended version of SCTP_SNDRCV (see Section 5.3.2) and will only be received if the user has set the socket option SCTP_USE_EXT_RCVINFO (see Section 8.1.22) to true in addition to any event subscription needed to receive ancillary data. Note that data in the next message is not valid unless the current message is completely read, i.e., unless the MSG_EOR is set; in other words, if the application has more data to read from the current message, then no next-message information will be available.
このcmsghdr構造体）は（のrecvmsgを介して受信されたメッセージに関するSCTPヘッダ情報のためのSCTPオプションを指定します。この構造はSCTP_SNDRCVの拡張版であることに注意してください（5.3.2項を参照）、ユーザーはソケットオプションSCTP_USE_EXT_RCVINFOを設定している場合にのみ補助的に受信するために必要なすべてのイベントサブスクリプションに加えて、trueに（セクション8.1.22を参照）を受信しますデータ。 MSG_EORが設定されていない限り、すなわち、現在のメッセージが完全に読み込まれていない限り、次のメッセージ内のデータが有効でないことに留意されたいです。アプリケーションは、現在のメッセージから読み取るため、より多くのデータを有する場合、換言すれば、その後何の次のメッセージの情報が利用できません。
SCTP_NXTINFO (described in Section 5.3.6) should be used when possible, since SCTP_EXTRCV is considered deprecated.
SCTP_EXTRCVは推奨考えられるのでSCTP_NXTINFO（セクション5.3.6を参照）、可能な場合に使用されるべきです。
+--------------+-------------+------------------------+
| cmsg_level | cmsg_type | cmsg_data[] |
+--------------+-------------+------------------------+
| IPPROTO_SCTP | SCTP_EXTRCV | struct sctp_extrcvinfo |
+--------------+-------------+------------------------+
The sctp_extrcvinfo structure is defined below:
sctp_extrcvinfo構造を以下のように定義されています。
struct sctp_extrcvinfo {
uint16_t sinfo_stream;
uint16_t sinfo_ssn;
uint16_t sinfo_flags;
uint32_t sinfo_ppid;
uint32_t sinfo_context;
uint32_t sinfo_pr_value;
uint32_t sinfo_tsn;
uint32_t sinfo_cumtsn;
uint16_t serinfo_next_flags;
uint16_t serinfo_next_stream;
uint32_t serinfo_next_aid;
uint32_t serinfo_next_length;
uint32_t serinfo_next_ppid;
sctp_assoc_t sinfo_assoc_id;
};
sinfo_*: Please see Section 5.3.2 for details for these fields.
sinfo_ *：これらのフィールドの詳細については、5.3.2項を参照してください。
serinfo_next_flags: This bitmask will hold one or more of the following values:
serinfo_next_flags：このビットマスクは、次のいずれかの値以上を保持します。
SCTP_NEXT_MSG_AVAIL: This bit, when set to 1, indicates that next-message information is available; i.e., next_stream, next_aid, next_length, and next_ppid fields all have valid values. If this bit is set to 0, then these fields are not valid and should be ignored.
SCTP_NEXT_MSG_AVAIL：1に設定このビットは、次のメッセージの情報が利用可能であることを示しています。すなわち、next_stream、next_aid、next_length、およびnext_ppidフィールドはすべて、有効な値を持っています。このビットが0に設定されている場合、これらのフィールドが有効でないと無視されるべきです。
SCTP_NEXT_MSG_ISCOMPLETE: This bit, when set, indicates that the next message is completely in the receive buffer. The next_length field thus contains the entire message size. If this flag is set to 0, then the next_length field only contains part of the message size, since the message is still being received (it is being partially delivered).
SCTP_NEXT_MSG_ISCOMPLETEは：設定すると、このビットは、次のメッセージが受信バッファに完全にあることを示しています。 next_lengthフィールドは、このようにメッセージ全体のサイズが含まれています。このフラグが0に設定されている場合、メッセージがまだ受信されているので、その後next_lengthフィールドのみ（それは部分的に配信されている）、メッセージサイズの一部を含みます。
SCTP_NEXT_MSG_IS_UNORDERED: This bit, when set, indicates that the next message to be received was sent by the peer as unordered. If this bit is not set (i.e., the bit is 0) the next message to be read is an ordered message in the stream specified.
SCTP_NEXT_MSG_IS_UNORDERED：このビットは、セットは、受信される次のメッセージが順不同としてピアによって送信されたことを示しています。このビットが設定されていない場合に読み取るべき次のメッセージは、指定されたストリームに順序付けられたメッセージである（すなわち、ビットは0です）。
SCTP_NEXT_MSG_IS_NOTIFICATION: This bit, when set, indicates that the next message to be received is not a message from the peer, but instead is a MSG_NOTIFICATION from the local SCTP stack.
SCTP_NEXT_MSG_IS_NOTIFICATION：このビットは、セットは、受信される次のメッセージがピアからのメッセージではなく、ローカルSCTPスタックからMSG_NOTIFICATIONであることを示しています。
serinfo_next_stream: This value, when valid (see serinfo_next_flags), contains the next stream number that will be received on a subsequent call to one of the receive message functions.
serinfo_next_stream：この値は、ときに有効に（serinfo_next_flagsを参照）、受信メッセージ機能のいずれかの後続の呼び出しで受信される次のストリーム番号を含みます。
serinfo_next_aid: This value, when valid (see serinfo_next_flags), contains the next association identifier that will be received on a subsequent call to one of the receive message functions.
serinfo_next_aid：この値は、ときに有効に（serinfo_next_flagsを参照）、受信メッセージ機能のいずれかの後続の呼び出しで受信される次のアソシエーション識別子を含みます。
serinfo_next_length: This value, when valid (see serinfo_next_flags), contains the length of the next message that will be received on a subsequent call to one of the receive message functions. Note that this length may be a partial length, depending on the settings of next_flags.
serinfo_next_length：この値は、（serinfo_next_flagsを参照）が有効、受信メッセージ機能の一つに、後続の呼び出しで受信される次のメッセージの長さを含む場合。この長さはnext_flagsの設定に応じて、部分的な長さであってもよいことに留意されたいです。
serinfo_next_ppid: This value, when valid (see serinfo_next_flags), contains the ppid of the next message that will be received on a subsequent call to one of the receive message functions.
serinfo_next_ppid：この値は、（serinfo_next_flagsを参照）が有効、受信メッセージ機能の一つに、後続の呼び出しで受信される次のメッセージのPPIDを含む場合。
This cmsghdr structure specifies SCTP options for sendmsg().
このcmsghdr構造体は、（）にsendmsgのためのSCTPのオプションを指定します。
+--------------+--------------+---------------------+
| cmsg_level | cmsg_type | cmsg_data[] |
+--------------+--------------+---------------------+
| IPPROTO_SCTP | SCTP_SNDINFO | struct sctp_sndinfo |
+--------------+--------------+---------------------+
The sctp_sndinfo structure is defined below:
sctp_sndinfo構造を以下のように定義されています。
struct sctp_sndinfo {
uint16_t snd_sid;
uint16_t snd_flags;
uint32_t snd_ppid;
uint32_t snd_context;
sctp_assoc_t snd_assoc_id;
};
snd_sid: This value holds the stream number to which the application wishes to send this message. If a sender specifies an invalid stream number, an error indication is returned and the call fails.
snd_sid：この値は、アプリケーションがこのメッセージを送りたい先のストリーム番号を保持しています。送信者が無効なストリーム番号を指定した場合、エラー表示が返され、コールは失敗します。
snd_flags: This field may contain any of the following flags and is composed of a bitwise OR of these values.
snd_flags：このフィールドには、以下のフラグのいずれかを含むことができ、ビット単位のORこれらの値で構成されています。
SCTP_UNORDERED: This flag requests the unordered delivery of the message. If this flag is clear, the datagram is considered an ordered send.
SCTP UNORDERED：このフラグは、メッセージの順不同の配送を依頼します。このフラグがクリアされている場合、データグラムは、注文送信考えられています。
SCTP_ADDR_OVER: This flag, for a one-to-many style socket, requests that the SCTP stack override the primary destination address with the address found with the sendto()/sendmsg call.
SCTP_ADDR_OVER：このフラグは、1対多のスタイルのソケットのために、SCTPスタックはのsendto（）/にsendmsg呼び出しで見つかったアドレスでのプライマリ送信先アドレスを上書きすることを要求します。
SCTP_ABORT: Setting this flag causes the specified association to abort by sending an ABORT message to the peer. The ABORT chunk will contain an error cause of 'User Initiated Abort' with cause code 12. The cause-specific information of this error cause is provided in msg_iov.
SCTP_ABORT：このフラグを設定すると、ピアにABORTメッセージを送信することによって中止し、指定の関連付けを引き起こします。 ABORTチャンクはmsg_iovで提供され、このエラーの原因の原因に固有の情報原因コード12で「ユーザー主導中止」のエラー原因が含まれています。
SCTP_EOF: Setting this flag invokes the SCTP graceful shutdown procedures on the specified association. Graceful shutdown assures that all data queued by both endpoints is successfully transmitted before closing the association.
SCTP_EOF：このフラグを設定するには、指定された関連付けのSCTP正常なシャットダウン手順を起動します。グレースフルシャットダウンは両方のエンドポイントによってキューに入れられた全てのデータが正常に関連を閉じる前に送信されることを保証します。
SCTP_SENDALL: This flag, if set, will cause a one-to-many style socket to send the message to all associations that are currently established on this socket. For the one-to-one style socket, this flag has no effect.
SCTP_SENDALL：このフラグは、設定されている場合、1対多のスタイルのソケットは、現在このソケットに確立されているすべての関連付けにメッセージを送信するようになります。 1対1のスタイルのソケットの場合、このフラグは効果がありません。
snd_ppid: This value in sendmsg() is an unsigned integer that is passed to the remote end in each user message. Please note that the SCTP stack performs no byte order modification of this field. For example, if the DATA chunk has to contain a given value in network byte order, the SCTP user has to perform the htonl() computation.
snd_ppid：sendmsgのこの値は（）は、各ユーザのメッセージでリモートエンドに渡される符号なし整数です。 SCTPスタックは、このフィールドのないバイト順の変更を行いませんので予めご了承ください。データチャンクは、ネットワークバイト順で指定された値を含む必要がある場合、例えば、SCTPユーザはhtonl（）計算を実行しなければなりません。
snd_context: This value is an opaque 32-bit context datum that is used in the sendmsg() function. This value is passed back to the upper layer if an error occurs on the send of a message and is retrieved with each undelivered message.
snd_context：この値は、sendmsg（）関数で使用される不透明な32ビットのコンテキストデータがあります。エラーは、メッセージの送信時に発生し、各未通知メッセージで取得された場合、この値は、上位層に戻されます。
snd_assoc_id: The association handle field, sinfo_assoc_id, holds the identifier for the association announced in the SCTP_COMM_UP notification. All notifications for a given association have the same identifier. This field is ignored for one-to-one style sockets.
snd_assoc_id：アソシエーションハンドルフィールド、sinfo_assoc_idは、SCTP_COMM_UP通知で発表会のための識別子を保持しています。与えられたアソシエーションのすべての通知は、同じ識別子を持っています。このフィールドは、1対1のスタイルのソケットでは無視されます。
An sctp_sndinfo item always corresponds to the data in msg_iov.
sctp_sndinfo項目は常にmsg_iovのデータに対応します。
This cmsghdr structure describes SCTP receive information about a received message through recvmsg().
このcmsghdr構造体は、SCTP）は（のrecvmsgを介して受信したメッセージについての情報を受信記載されています。
To enable the delivery of this information, an application must use the SCTP_RECVRCVINFO socket option (see Section 8.1.29).
この情報の配信を有効にするには、SCTP_RECVRCVINFOソケットオプションを使用しなければならないアプリケーションは、（セクション8.1.29を参照してください）。
+--------------+--------------+---------------------+
| cmsg_level | cmsg_type | cmsg_data[] |
+--------------+--------------+---------------------+
| IPPROTO_SCTP | SCTP_RCVINFO | struct sctp_rcvinfo |
+--------------+--------------+---------------------+
The sctp_rcvinfo structure is defined below:
sctp_rcvinfo構造を以下のように定義されています。
struct sctp_rcvinfo {
uint16_t rcv_sid;
uint16_t rcv_ssn;
uint16_t rcv_flags;
uint32_t rcv_ppid;
uint32_t rcv_tsn;
uint32_t rcv_cumtsn;
uint32_t rcv_context;
sctp_assoc_t rcv_assoc_id;
};
rcv_sid: The SCTP stack places the message's stream number in this value.
rcv_sid：SCTPスタックが、この値では、メッセージのストリーム番号を配置します。
rcv_ssn: This value contains the stream sequence number that the remote endpoint placed in the DATA chunk. For fragmented messages, this is the same number for all deliveries of the message (if more than one recvmsg() is needed to read the message).
rcv_ssn：この値は、リモートエンドポイントがデータチャンクに配置されたストリームのシーケンス番号を含みます。断片化されたメッセージの場合、これは、メッセージのすべての配達のための同じ番号（複数のrecvmsg（）がメッセージを読むために必要な場合）です。
rcv_flags: This field may contain any of the following flags and is composed of a bitwise OR of these values.
rcv_flags：このフィールドには、以下のフラグのいずれかを含むことができ、ビット単位のORこれらの値で構成されています。
SCTP_UNORDERED: This flag is present when the message was sent unordered.
SCTP UNORDERED：このフラグは、メッセージが順不同送信されたときに存在しています。
rcv_ppid: This value is the same information that was passed by the upper layer in the peer application. Please note that the SCTP stack performs no byte order modification of this field. For example, if the DATA chunk has to contain a given value in network byte order, the SCTP user has to perform the ntohl() computation.
rcv_ppid：この値は、ピアアプリケーションに上位層によって渡されたのと同じ情報です。 SCTPスタックは、このフィールドのないバイト順の変更を行いませんので予めご了承ください。データチャンクは、ネットワークバイト順で指定された値を含む必要がある場合、例えば、SCTPユーザはntohl（）計算を実行しなければなりません。
rcv_tsn: This field holds a TSN that was assigned to one of the SCTP DATA chunks.
rcv_tsn：このフィールドは、SCTPデータチャンクの1つに割り当てられたTSNを保持しています。
rcv_cumtsn: This field will hold the current cumulative TSN as known by the underlying SCTP layer.
rcv_cumtsn：基礎となるSCTP層によって知られているように、このフィールドには、現在の累積TSNを開催します。
rcv_context: This value is an opaque 32-bit context datum that was set by the user with the SCTP_CONTEXT socket option. This value is passed back to the upper layer if an error occurs on the send of a message and is retrieved with each undelivered message.
rcv_context：この値はSCTP_CONTEXTソケットオプションでユーザによって設定された不透明な32ビットコンテクスト基準です。エラーは、メッセージの送信時に発生し、各未通知メッセージで取得された場合、この値は、上位層に戻されます。
rcv_assoc_id: The association handle field, sinfo_assoc_id, holds the identifier for the association announced in the SCTP_COMM_UP notification. All notifications for a given association have the same identifier. This field is ignored for one-to-one style sockets.
rcv_assoc_id：アソシエーションハンドルフィールド、sinfo_assoc_idは、SCTP_COMM_UP通知で発表会のための識別子を保持しています。与えられたアソシエーションのすべての通知は、同じ識別子を持っています。このフィールドは、1対1のスタイルのソケットでは無視されます。
An sctp_rcvinfo item always corresponds to the data in msg_iov.
sctp_rcvinfo項目は常にmsg_iovのデータに対応します。
This cmsghdr structure describes SCTP receive information of the next message that will be delivered through recvmsg() if this information is already available when delivering the current message.
このcmsghdr構造体は、SCTPは、現在のメッセージを配信する際にこの情報が既に利用可能である場合には（）のrecvmsgを通じて配信される次のメッセージの情報を受信記述する。
To enable the delivery of this information, an application must use the SCTP_RECVNXTINFO socket option (see Section 8.1.30).
この情報の配信を有効にするには、SCTP_RECVNXTINFOソケットオプションを使用しなければならないアプリケーションは、（セクション8.1.30を参照してください）。
+--------------+--------------+---------------------+
| cmsg_level | cmsg_type | cmsg_data[] |
+--------------+--------------+---------------------+
| IPPROTO_SCTP | SCTP_NXTINFO | struct sctp_nxtinfo |
+--------------+--------------+---------------------+
The sctp_nxtinfo structure is defined below:
sctp_nxtinfo構造を以下のように定義されています。
struct sctp_nxtinfo {
uint16_t nxt_sid;
uint16_t nxt_flags;
uint32_t nxt_ppid;
uint32_t nxt_length;
sctp_assoc_t nxt_assoc_id;
};
nxt_sid: The SCTP stack places the next message's stream number in this value.
nxt_sid：SCTPスタックが、この値に次のメッセージのストリーム番号を配置します。
nxt_flags: This field may contain any of the following flags and is composed of a bitwise OR of these values.
nxt_flags：このフィールドには、以下のフラグのいずれかを含むことができ、ビット単位のORこれらの値で構成されています。
SCTP_UNORDERED: This flag is present when the next message was sent unordered.
SCTP UNORDERED：このフラグは、次のメッセージが順不同送信されたときに存在しています。
SCTP_COMPLETE: This flag indicates that the entire message has been received and is in the socket buffer. Note that this has special implications with respect to the nxt_length field; see the description for nxt_length below.
SCTP_COMPLETE：このフラグは、メッセージ全体が受信されたことを示し、ソケットバッファです。これはnxt_length分野に関して特別な意味を持っていることに注意してください。以下nxt_lengthの説明を参照してください。
SCTP_NOTIFICATION: This flag is present when the next message is not a user message but instead is a notification.
SCTP_NOTIFICATION：次のメッセージがユーザ・メッセージではなく、代わりに通知する場合、このフラグが存在しています。
nxt_ppid: This value is the same information that was passed by the upper layer in the peer application for the next message. Please note that the SCTP stack performs no byte order modification of this field. For example, if the DATA chunk has to contain a given value in network byte order, the SCTP user has to perform the ntohl() computation.
nxt_ppid：この値は、次のメッセージをピアアプリケーションに上位層によって渡されたのと同じ情報です。 SCTPスタックは、このフィールドのないバイト順の変更を行いませんので予めご了承ください。データチャンクは、ネットワークバイト順で指定された値を含む必要がある場合、例えば、SCTPユーザはntohl（）計算を実行しなければなりません。
nxt_length: This value is the length of the message currently within the socket buffer. This might NOT be the entire length of the message, since a partial delivery may be in progress. Only if the flag SCTP_COMPLETE is set in the nxt_flags field does this field represent the size of the entire next message.
nxt_length：この値は、ソケットバッファ内の現在のメッセージの長さです。部分的な送達が進行中であってもよいので、これは、メッセージの全体の長さではないかもしれません。フラグSCTP_COMPLETEがnxt_flagsフィールドに設定されている場合にのみ、このフィールドは、全体の次のメッセージのサイズを表しありません。
nxt_assoc_id: The association handle field of the next message, nxt_assoc_id, holds the identifier for the association announced in the SCTP_COMM_UP notification. All notifications for a given association have the same identifier. This field is ignored for one-to-one style sockets.
nxt_assoc_id：次のメッセージの関連付けハンドルフィールド、nxt_assoc_idは、SCTP_COMM_UP通知で発表会のための識別子を保持しています。与えられたアソシエーションのすべての通知は、同じ識別子を持っています。このフィールドは、1対1のスタイルのソケットでは無視されます。
This cmsghdr structure specifies SCTP options for sendmsg().
このcmsghdr構造体は、（）にsendmsgのためのSCTPのオプションを指定します。
+--------------+-------------+--------------------+
| cmsg_level | cmsg_type | cmsg_data[] |
+--------------+-------------+--------------------+
| IPPROTO_SCTP | SCTP_PRINFO | struct sctp_prinfo |
+--------------+-------------+--------------------+
The sctp_prinfo structure is defined below:
sctp_prinfo構造を以下のように定義されています。
struct sctp_prinfo {
uint16_t pr_policy;
uint32_t pr_value;
};
pr_policy: This specifies which Partially Reliable SCTP (PR-SCTP) policy is used. Using SCTP_PR_SCTP_NONE results in a reliable transmission. When SCTP_PR_SCTP_TTL is used, the PR-SCTP policy "timed reliability" defined in [RFC3758] is used. In this case, the lifetime is provided in pr_value.
pr_policy：これは、部分的に信頼性の高いSCTP（PR-SCTP）ポリシーが使用されているかを指定します。信頼性の高い伝送でSCTP_PR_SCTP_NONEの結果を使用。 SCTP_PR_SCTP_TTLが使用される場合、[RFC3758]で定義されたPR-SCTPポリシー「時限信頼」が使用されます。この場合には、寿命がpr_valueに設けられています。
pr_value: The meaning of this field depends on the PR-SCTP policy specified by the pr_policy field. It is ignored when SCTP_PR_SCTP_NONE is specified. In the case of SCTP_PR_SCTP_TTL, the lifetime in milliseconds is specified.
pr_value：このフィールドの意味はpr_policyフィールドで指定されたPR-SCTPのポリシーに依存します。 SCTP_PR_SCTP_NONEが指定されている場合、それは無視されます。 SCTP_PR_SCTP_TTLの場合は、ミリ秒単位の寿命が指定されています。
An sctp_prinfo item always corresponds to the data in msg_iov.
sctp_prinfo項目は常にmsg_iovのデータに対応します。
This cmsghdr structure specifies SCTP options for sendmsg().
このcmsghdr構造体は、（）にsendmsgのためのSCTPのオプションを指定します。
+--------------+---------------+----------------------+
| cmsg_level | cmsg_type | cmsg_data[] |
+--------------+---------------+----------------------+
| IPPROTO_SCTP | SCTP_AUTHINFO | struct sctp_authinfo |
+--------------+---------------+----------------------+
The sctp_authinfo structure is defined below:
sctp_authinfo構造を以下のように定義されています。
struct sctp_authinfo {
uint16_t auth_keynumber;
};
auth_keynumber: This specifies the shared key identifier used for sending the user message.
auth_keynumber：これは、ユーザーのメッセージを送信するために使用される共有鍵の識別子を指定します。
An sctp_authinfo item always corresponds to the data in msg_iov. Please note that the SCTP implementation must not bundle user messages that need to be authenticated using different shared key identifiers.
sctp_authinfo項目は常にmsg_iovのデータに対応します。 SCTPの実装が異なる共有鍵識別子を使用して認証する必要があるユーザメッセージをバンドルしてはならないことに注意してください。
This cmsghdr structure specifies SCTP options for sendmsg().
このcmsghdr構造体は、（）にsendmsgのためのSCTPのオプションを指定します。
+--------------+----------------+----------------+
| cmsg_level | cmsg_type | cmsg_data[] |
+--------------+----------------+----------------+
| IPPROTO_SCTP | SCTP_DSTADDRV4 | struct in_addr |
+--------------+----------------+----------------+
This ancillary data can be used to provide more than one destination address to sendmsg(). It can be used to implement sctp_sendv() using sendmsg().
この補助データはSENDMSGする複数の宛先アドレスを提供するために使用することができます（）。 （）にsendmsg（）を使用sctp_sendvを実装するために使用することができます。
This cmsghdr structure specifies SCTP options for sendmsg().
このcmsghdr構造体は、（）にsendmsgのためのSCTPのオプションを指定します。
+--------------+----------------+-----------------+
| cmsg_level | cmsg_type | cmsg_data[] |
+--------------+----------------+-----------------+
| IPPROTO_SCTP | SCTP_DSTADDRV6 | struct in6_addr |
+--------------+----------------+-----------------+
This ancillary data can be used to provide more than one destination address to sendmsg(). It can be used to implement sctp_sendv() using sendmsg().
この補助データはSENDMSGする複数の宛先アドレスを提供するために使用することができます（）。 （）にsendmsg（）を使用sctp_sendvを実装するために使用することができます。
An SCTP application may need to understand and process events and errors that happen on the SCTP stack. These events include network status changes, association startups, remote operational errors, and undeliverable messages. All of these can be essential for the application.
SCTPアプリケーションはSCTPスタックに発生したイベントやエラーを理解し、プロセスが必要な場合があります。これらのイベントは、ネットワークの状態が変化し、関連のスタートアップ、遠隔操作ミス、および配信不能メッセージが含まれます。これらのすべては、アプリケーションのために不可欠であることができます。
When an SCTP application layer does a recvmsg(), the message read is normally a data message from a peer endpoint. If the application wishes to have the SCTP stack deliver notifications of non-data events, it sets the appropriate socket option for the notifications it wants. See Section 6.2 for these socket options. When a notification arrives, recvmsg() returns the notification in the application-supplied data buffer via msg_iov, and sets MSG_NOTIFICATION in msg_flags.
SCTPアプリケーション層のrecvmsg（）がない場合、読み取りメッセージは通常、ピアエンドポイントからのデータメッセージです。アプリケーションはSCTPスタックは非データイベントの通知を配信持つことを希望する場合は、それが望んでいるの通知のための適切なソケットオプションを設定します。これらのソケットオプションについては、セクション6.2を参照してください。通知が到着すると、のrecvmsg（）msg_iovを介してアプリケーションが提供するデータバッファに通知を返し、msg_flagsにMSG_NOTIFICATIONを設定します。
This section details the notification structures. Every notification structure carries some common fields that provide general information.
このセクションでは、通知の構造を詳しく説明します。すべての通知構造は一般的な情報を提供するいくつかの一般的なフィールドを運びます。
A recvmsg() call will return only one notification at a time. Just as when reading normal data, it may return part of a notification if the msg_iov buffer is not large enough. If a single read is not sufficient, msg_flags will have MSG_EOR clear. The user must finish reading the notification before subsequent data can arrive.
recvmsg（）の呼び出しでは、一度に1つの通知を返します。通常のデータを読み込むときと同じようにmsg_iovバッファが十分な大きさでない場合、それは通知の一部を返すことがあります。単一の読み取りが十分でない場合、msg_flagsはMSG_EORが明確になります。後続のデータが到着する前に、ユーザーが通知を読み終えなければなりません。
The notification structure is defined as the union of all notification types.
通知構造は、すべての通知タイプの和集合として定義されます。
union sctp_notification {
struct sctp_tlv {
uint16_t sn_type; /* Notification type. */
uint16_t sn_flags;
uint32_t sn_length;
} sn_header;
struct sctp_assoc_change sn_assoc_change;
struct sctp_paddr_change sn_paddr_change;
struct sctp_remote_error sn_remote_error;
struct sctp_send_failed sn_send_failed;
struct sctp_shutdown_event sn_shutdown_event;
struct sctp_adaptation_event sn_adaptation_event;
struct sctp_pdapi_event sn_pdapi_event;
struct sctp_authkey_event sn_auth_event;
struct sctp_sender_dry_event sn_sender_dry_event;
struct sctp_send_failed_event sn_send_failed_event;
};
sn_type: The following list describes the SCTP notification and event types for the field sn_type.
sn_type：次のリストは、フィールドsn_typeのためのSCTP通知とイベントタイプについて説明します。
SCTP_ASSOC_CHANGE: This tag indicates that an association has either been opened or closed. Refer to Section 6.1.1 for details.
SCTP_ASSOC_CHANGE：このタグは、関連付けが開閉されたかということを示しています。詳細については、セクション6.1.1を参照してください。
SCTP_PEER_ADDR_CHANGE: This tag indicates that an address that is part of an existing association has experienced a change of state (e.g., a failure or return to service of the reachability of an endpoint via a specific transport address). Please see Section 6.1.2 for data structure details.
SCTP_PEER_ADDR_CHANGE：このタグは、既存の関連付けの一部であるアドレスは、状態の変化経験（例えば、失敗するか、特定のトランスポートアドレスを介して、エンドポイントの到達可能性のサービスに復帰）したことを示します。データ構造の詳細については、セクション6.1.2を参照してください。
SCTP_REMOTE_ERROR: The attached error message is an Operation Error message received from the remote peer. It includes the complete TLV sent by the remote endpoint. See Section 6.1.3 for the detailed format.
SCTP_REMOTE_ERROR：添付のエラーメッセージは、リモートピアから受信した操作エラーメッセージです。これは、リモートエンドポイントによって送信された完全なTLVを含んでいます。詳細なフォーマットについては、セクション6.1.3を参照してください。
SCTP_SEND_FAILED_EVENT: The attached datagram could not be sent to the remote endpoint. This structure includes the original SCTP_SNDINFO that was used in sending this message; i.e., this structure uses the sctp_sndinfo per Section 6.1.11.
SCTP_SEND_FAILED_EVENT：添付データグラムがリモートエンドポイントに送信することができませんでした。この構造は、このメッセージを送信に使用した元のSCTP_SNDINFOを含みます。すなわち、この構造は、セクション6.1.11あたりsctp_sndinfoを使用しています。
SCTP_SHUTDOWN_EVENT: The peer has sent a SHUTDOWN. No further data should be sent on this socket.
SCTP_SHUTDOWN_EVENT：ピアがSHUTDOWNを送りました。これ以上のデータは、このソケットから送信されるべきではありません。
SCTP_ADAPTATION_INDICATION: This notification holds the peer's indicated adaptation layer. Please see Section 6.1.6.
SCTP_ADAPTATION_INDICATION：この通知は、ピアの指定されたアダプテーション層を保持しています。 6.1.6項を参照してください。
SCTP_PARTIAL_DELIVERY_EVENT: This notification is used to tell a receiver that the partial delivery has been aborted. This may indicate that the association is about to be aborted. Please see Section 6.1.7.
SCTP_PARTIAL_DELIVERY_EVENT：この通知は、一部の配信が中止された受信機を伝えるために使用されています。これは、関連付けが中止されようとしていることを示してもよいです。セクション6.1.7を参照してください。
SCTP_AUTHENTICATION_EVENT: This notification is used to tell a receiver that either an error occurred on authentication, or a new key was made active. See Section 6.1.8.
SCTP_AUTHENTICATION_EVENT：この通知は、いずれかのエラーが認証に発生した、または新しいキーがアクティブになったことを受信者に伝えるために使用されています。セクション6.1.8を参照してください。
SCTP_SENDER_DRY_EVENT: This notification is used to inform the application that the sender has no more user data queued for transmission or retransmission. See Section 6.1.9.
SCTP_SENDER_DRY_EVENT：この通知は、送信者がこれ以上のユーザデータが送信または再送信のためにキューに入れられなかったことをアプリケーションに通知するために使用されています。セクション6.1.9を参照してください。
sn_flags: These are notification-specific flags.
sn_flags：これらは、通知固有のフラグです。
sn_length: This is the length of the whole sctp_notification structure, including the sn_type, sn_flags, and sn_length fields.
sn_length：これはsn_type、sn_flags、およびsn_lengthフィールドを含む、全体sctp_notification構造体の長さです。
Communication notifications inform the application that an SCTP association has either begun or ended. The identifier for a new association is provided by this notification. The notification information has the following format:
通信の通知は、SCTPアソシエーションが開始または終了したいずれかのアプリケーションに通知します。新しいアソシエーションのための識別子は、この通知により提供されます。通知情報の形式は次のとおりです。
struct sctp_assoc_change {
uint16_t sac_type;
uint16_t sac_flags;
uint32_t sac_length;
uint16_t sac_state;
uint16_t sac_error;
uint16_t sac_outbound_streams;
uint16_t sac_inbound_streams;
sctp_assoc_t sac_assoc_id;
uint8_t sac_info[];
};
sac_type: This field should be set to SCTP_ASSOC_CHANGE.
sac_type：このフィールドはSCTP_ASSOC_CHANGEに設定する必要があります。
sac_flags: This field is currently unused.
sac_flags：このフィールドは現在未使用です。
sac_length: This field is the total length of the notification data, including the notification header.
sac_length：このフィールドは、通知ヘッダを含む、通知データの全長です。
sac_state: This field holds one of a number of values that communicate the event that happened to the association. These values include
sac_state：このフィールドは、協会に起こった出来事を伝える値の数の1を保持しています。これらの値は、
SCTP_COMM_UP: A new association is now ready, and data may be exchanged with this peer. When an association has been established successfully, this notification should be the first one.
SCTP_COMM_UP：新しい関連付けが今準備ができて、そしてデータは、このピアと交換することができます。アソシエーションが正常に確立された場合は、この通知は、最初の1でなければなりません。
SCTP_COMM_LOST: The association has failed. The association is now in the closed state. If SEND_FAILED notifications are turned on, an SCTP_COMM_LOST is accompanied by a series of SCTP_SEND_FAILED_EVENT events, one for each outstanding message.
SCTP_COMM_LOST：関連付けが失敗しました。協会は、閉じた状態になっています。 SEND_FAILED通知がオンになっている場合は、SCTP_COMM_LOSTはSCTP_SEND_FAILED_EVENTイベント、未処理の各メッセージに1つのシリーズを伴っています。
SCTP_RESTART: SCTP has detected that the peer has restarted.
SCTP_RESTART：SCTPは、ピアが再起動したことを検出しました。
SCTP_SHUTDOWN_COMP: The association has gracefully closed.
SCTP_SHUTDOWN_COMP：関連付けが正常終了しました。
SCTP_CANT_STR_ASSOC: The association setup failed. If non-blocking mode is set and data was sent (on a one-to-many style socket), an SCTP_CANT_STR_ASSOC is accompanied by a series of SCTP_SEND_FAILED_EVENT events, one for each outstanding message.
SCTP_CANT_STR_ASSOC：関連の設定に失敗しました。非ブロックモードに設定され、データは（1対多スタイルソケット上で）送信された場合、SCTP_CANT_STR_ASSOCはSCTP_SEND_FAILED_EVENTイベント、未処理の各メッセージに1つのシリーズを伴っています。
sac_error: If the state was reached due to an error condition (e.g., SCTP_COMM_LOST), any relevant error information is available in this field. This corresponds to the protocol error codes defined in [RFC4960].
sac_error：状態がエラー状態（例えば、SCTP_COMM_LOST）に達した場合、任意の関連するエラー情報は、この分野で利用可能です。これは[RFC4960]で定義されたプロトコルのエラーコードに対応します。
sac_outbound_streams and sac_inbound_streams: The maximum number of streams allowed in each direction is available in sac_outbound_streams and sac_inbound streams.
sac_outbound_streamsとsac_inbound_streams：各方向で許可ストリームの最大数がsac_outbound_streamsとsac_inboundストリームで利用可能です。
sac_assoc_id: The sac_assoc_id field holds the identifier for the association. All notifications for a given association have the same association identifier. For a one-to-one style socket, this field is ignored.
sac_assoc_id：sac_assoc_idフィールドが関連するための識別子を保持しています。与えられたアソシエーションのすべての通知は、同じアソシエーションIDを持っています。 1対1のスタイルのソケットの場合、このフィールドは無視されます。
sac_info: If sac_state is SCTP_COMM_LOST and an ABORT chunk was received for this association, sac_info[] contains the complete ABORT chunk as defined in Section 3.3.7 of the SCTP specification [RFC4960]. If sac_state is SCTP_COMM_UP or SCTP_RESTART, sac_info may contain an array of uint8_t describing the features that the current association supports. Features may include
sac_info：SCTP_COMM_LOSTとABORTチャンクsac_stateである場合は、SCTP仕様[RFC4960]のセクション3.3.7で定義されるように[]完全ABORTチャンクを含んsac_info、この関連付けのために受け取りました。 sac_stateがSCTP_COMM_UP又はSCTP_RESTARTある場合、sac_info現在の関連付けがサポートする特徴を記述するuint8_tの配列を含んでいてもよいです。機能が含まれて
SCTP_ASSOC_SUPPORTS_PR: Both endpoints support the protocol extension described in [RFC3758].
SCTP_ASSOC_SUPPORTS_PR：両方のエンドポイントが[RFC3758]に記載されているプロトコルの拡張をサポートします。
SCTP_ASSOC_SUPPORTS_AUTH: Both endpoints support the protocol extension described in [RFC4895].
SCTP_ASSOC_SUPPORTS_AUTH：両方のエンドポイントが[RFC4895]に記載されているプロトコルの拡張をサポートします。
SCTP_ASSOC_SUPPORTS_ASCONF: Both endpoints support the protocol extension described in [RFC5061].
SCTP_ASSOC_SUPPORTS_ASCONF：両方のエンドポイントが[RFC5061]に記載されているプロトコルの拡張をサポートします。
SCTP_ASSOC_SUPPORTS_MULTIBUF: For a one-to-many style socket, the local endpoints use separate send and/or receive buffers for each SCTP association.
SCTP_ASSOC_SUPPORTS_MULTIBUFは：1対多スタイルソケットの場合、ローカルエンドポイントは、別の送信を使用し、および/または各SCTPアソシエーションのための受信バッファ。
When a destination address of a multi-homed peer encounters a state change, a peer address change event is sent. The notification has the following format:
マルチホーム・ピアの宛先アドレスが状態変化を検出したとき、ピアアドレス変更イベントが送信されます。通知の形式は次のとおりです。
struct sctp_paddr_change {
uint16_t spc_type;
uint16_t spc_flags;
uint32_t spc_length;
struct sockaddr_storage spc_aaddr;
uint32_t spc_state;
uint32_t spc_error;
sctp_assoc_t spc_assoc_id;
}
spc_type: This field should be set to SCTP_PEER_ADDR_CHANGE.
spc_type：このフィールドはSCTP_PEER_ADDR_CHANGEに設定する必要があります。
spc_flags: This field is currently unused.
spc_flags：このフィールドは、現在使用されていません。
spc_length: This field is the total length of the notification data, including the notification header.
spc_length：このフィールドは、通知ヘッダを含む、通知データの全長です。
spc_aaddr: The affected address field holds the remote peer's address that is encountering the change of state.
spc_aaddr：影響を受けたアドレスフィールドには、状態の変化に遭遇しているリモートピアのアドレスを保持します。
spc_state: This field holds one of a number of values that communicate the event that happened to the address. They include
spc_state：このフィールドは、アドレスに起こった出来事を伝える値の数の1を保持しています。それらが含みます
SCTP_ADDR_AVAILABLE: This address is now reachable. This notification is provided whenever an address becomes reachable.
SCTP_ADDR_AVAILABLE：このアドレスは現在到達可能です。アドレスが到達可能になるたびこの通知が提供されます。
SCTP_ADDR_UNREACHABLE: The address specified can no longer be reached. Any data sent to this address is rerouted to an alternate until this address becomes reachable. This notification is provided whenever an address becomes unreachable.
SCTP_ADDR_UNREACHABLE：指定されたアドレスが、もはや到達することができます。このアドレスに送信されたデータは、このアドレスが到達可能になるまで交互に再ルーティングされます。アドレスが到達不能になった時はいつでもこの通知が提供されます。
SCTP_ADDR_REMOVED: The address is no longer part of the association.
SCTP_ADDR_REMOVED：アドレスは、協会の一部ではなくなりました。
SCTP_ADDR_ADDED: The address is now part of the association.
SCTP_ADDR_ADDED：アドレスは今協会の一部です。
SCTP_ADDR_MADE_PRIM: This address has now been made the primary destination address. This notification is provided whenever an address is made primary.
SCTP_ADDR_MADE_PRIM：このアドレスは現在、主要な宛先アドレスを作ってきました。この通知は、アドレスがプライマリ行われるたびに提供されます。
spc_error: If the state was reached due to any error condition (e.g., SCTP_ADDR_UNREACHABLE), any relevant error information is available in this field.
spc_errorは：状態が何らかのエラー状態（例えば、SCTP_ADDR_UNREACHABLE）に達した場合、任意の関連するエラー情報は、この分野で利用可能です。
spc_assoc_id: The spc_assoc_id field holds the identifier for the association. All notifications for a given association have the same association identifier. For a one-to-one style socket, this field is ignored.
spc_assoc_id：spc_assoc_idフィールドが関連するための識別子を保持しています。与えられたアソシエーションのすべての通知は、同じアソシエーションIDを持っています。 1対1のスタイルのソケットの場合、このフィールドは無視されます。
A remote peer may send an Operation Error message to its peer. This message indicates a variety of error conditions on an association. The entire ERROR chunk as it appears on the wire is included in an SCTP_REMOTE_ERROR event. Please refer to the SCTP specification [RFC4960] and any extensions for a list of possible error formats. An SCTP error notification has the following format:
リモートピアはそのピアに操作エラーメッセージを送信することができます。このメッセージは、関連のエラーの様々な条件を示しています。それはワイヤーに表示される全体ERRORチャンクがSCTP_REMOTE_ERRORイベントに含まれています。 SCTP仕様[RFC4960]、可能なエラーフォーマットのリストについては、任意の拡張子を参照してください。 SCTPエラー通知の形式は次のとおりです。
struct sctp_remote_error {
uint16_t sre_type;
uint16_t sre_flags;
uint32_t sre_length;
uint16_t sre_error;
sctp_assoc_t sre_assoc_id;
uint8_t sre_data[];
};
sre_type: This field should be set to SCTP_REMOTE_ERROR.
sre_type：このフィールドはSCTP_REMOTE_ERRORに設定する必要があります。
sre_flags: This field is currently unused.
sre_flags：このフィールドは現在未使用です。
sre_length: This field is the total length of the notification data, including the notification header and the contents of sre_data.
sre_length：このフィールドは、通知ヘッダとsre_dataの内容を含む、通知データの全長です。
sre_error: This value represents one of the Operation Error causes defined in the SCTP specification [RFC4960], in network byte order.
sre_error：この値は、ネットワークバイト順で、SCTP仕様[RFC4960]で定義された誤操作の原因のいずれかを表します。
sre_assoc_id: The sre_assoc_id field holds the identifier for the association. All notifications for a given association have the same association identifier. For a one-to-one style socket, this field is ignored.
sre_assoc_id：sre_assoc_idフィールドは、協会の識別子を保持しています。与えられたアソシエーションのすべての通知は、同じアソシエーションIDを持っています。 1対1のスタイルのソケットの場合、このフィールドは無視されます。
sre_data: This contains the ERROR chunk as defined in Section 3.3.10 of the SCTP specification [RFC4960].
sre_data：SCTP仕様[RFC4960]のセクション3.3.10で定義されたように、これはERRORチャンクが含まれています。
Please note that this notification is deprecated. Use SCTP_SEND_FAILED_EVENT instead.
この通知は廃止されることに注意してください。代わりにSCTP_SEND_FAILED_EVENTを使用してください。
If SCTP cannot deliver a message, it can return back the message as a notification if the SCTP_SEND_FAILED event is enabled. The notification has the following format:
SCTPは、メッセージを配信できない場合SCTP_SEND_FAILEDイベントが有効になっている場合、それは通知としてメッセージをバック返すことができます。通知の形式は次のとおりです。
struct sctp_send_failed {
uint16_t ssf_type;
uint16_t ssf_flags;
uint32_t ssf_length;
uint32_t ssf_error;
struct sctp_sndrcvinfo ssf_info;
sctp_assoc_t ssf_assoc_id;
uint8_t ssf_data[];
};
ssf_type: This field should be set to SCTP_SEND_FAILED.
ssf_type：このフィールドはSCTP_SEND_FAILEDに設定する必要があります。
ssf_flags: The flag value will take one of the following values:
ssf_flags：フラグ値は、次のいずれかの値をとります。
SCTP_DATA_UNSENT: This value indicates that the data was never put on the wire.
SCTP_DATA_UNSENT：この値は、データがワイヤの上に置かれなかったことを示しています。
SCTP_DATA_SENT: This value indicates that the data was put on the wire. Note that this does not necessarily mean that the data was (or was not) successfully delivered.
SCTP_DATA_SENT：この値は、データがワイヤの上に置かれたことを示しています。これは必ずしも正常に配信されたデータだった（またはしなかった）ことを意味しないことに注意してください。
ssf_length: This field is the total length of the notification data, including the notification header and the payload in ssf_data.
ssf_length：このフィールドは、通知ヘッダとssf_dataでペイロードを含む、通知データの全長です。
ssf_error: This value represents the reason why the send failed, and if set, will be an SCTP protocol error code as defined in Section 3.3.10 of [RFC4960].
ssf_error：[RFC4960]のセクション3.3.10で定義されるように、この値は、送信が失敗した理由を表し、そして設定されている場合、SCTPプロトコルエラーコードであろう。
ssf_info: This field includes the ancillary data (struct sctp_sndrcvinfo) used to send the undelivered message. Regardless of whether ancillary data is used or not, the ssf_info.sinfo_flags field indicates whether the complete message or only part of the message is returned in ssf_data. If only part of the message is returned, it means that the part that is not present has been sent successfully to the peer.
ssf_info：このフィールドは、未配信のメッセージを送信するために使用される補助データ（構造体にsctp_sndrcvinfo）を含みます。かかわらず、補助データが使用されているか否かに、ssf_info.sinfo_flagsフィールドは、完全なメッセージまたはメッセージの一部のみがssf_dataに返されるかどうかを示します。メッセージの一部のみが返された場合、それが存在しない部分がピアに正常に送信されたことを意味します。
If the complete message cannot be sent, the SCTP_DATA_NOT_FRAG flag is set in ssf_info.sinfo_flags. If the first part of the message is sent successfully, SCTP_DATA_LAST_FRAG is set. This means that the tail end of the message is returned in ssf_data.
完全なメッセージが送信できない場合は、SCTP_DATA_NOT_FRAGフラグがssf_info.sinfo_flagsに設定されています。メッセージの最初の部分が正常に送信された場合、SCTP_DATA_LAST_FRAGが設定されています。これは、メッセージの末尾がssf_dataで返されることを意味します。
ssf_assoc_id: The ssf_assoc_id field, ssf_assoc_id, holds the identifier for the association. All notifications for a given association have the same association identifier. For a one-to-one style socket, this field is ignored.
ssf_assoc_id：ssf_assoc_idフィールド、ssf_assoc_idは、協会の識別子を保持しています。与えられたアソシエーションのすべての通知は、同じアソシエーションIDを持っています。 1対1のスタイルのソケットの場合、このフィールドは無視されます。
ssf_data: The undelivered message or part of the undelivered message will be present in the ssf_data field. Note that the ssf_info.sinfo_flags field as noted above should be used to determine whether a complete message or just a piece of the message is present. Note that only user data is present in this field; any chunk headers or SCTP common headers must be removed by the SCTP stack.
ssf_data：未配信メッセージの未配信メッセージまたは一部をssf_dataフィールドに存在するであろう。上記のように述べssf_info.sinfo_flagsフィールドは、メッセージの完全なメッセージまたは単に部分が存在するかどうかを決定するために使用されるべきであることに留意されたいです。ユーザデータのみがこの分野で存在していることに注意してください。すべてのチャンクヘッダやSCTP共通ヘッダは、SCTPスタックによって除去されなければなりません。
When a peer sends a SHUTDOWN, SCTP delivers this notification to inform the application that it should cease sending data.
ピアがSHUTDOWNを送信すると、SCTPは、データ送信を中止すべきアプリケーションに通知し、この通知を提供します。
struct sctp_shutdown_event {
uint16_t sse_type;
uint16_t sse_flags;
uint32_t sse_length;
sctp_assoc_t sse_assoc_id;
};
sse_type: This field should be set to SCTP_SHUTDOWN_EVENT.
sse_type：このフィールドはSCTP_SHUTDOWN_EVENTに設定する必要があります。
sse_flags: This field is currently unused.
sse_flags：このフィールドは現在未使用です。
sse_length: This field is the total length of the notification data, including the notification header. It will generally be sizeof(struct sctp_shutdown_event).
sse_length：このフィールドは、通知ヘッダを含む、通知データの全長です。これは、一般的にはsizeof（構造体sctp_shutdown_event）となります。
sse_assoc_id: The sse_assoc_id field holds the identifier for the association. All notifications for a given association have the same association identifier. For a one-to-one style socket, this field is ignored.
sse_assoc_id：sse_assoc_idフィールドが関連するための識別子を保持しています。与えられたアソシエーションのすべての通知は、同じアソシエーションIDを持っています。 1対1のスタイルのソケットの場合、このフィールドは無視されます。
When a peer sends an Adaptation Layer Indication parameter as described in [RFC5061], SCTP delivers this notification to inform the application about the peer's adaptation layer indication.
[RFC5061]に記載されているように、ピアは、アダプテーションレイヤ表示パラメータを送信すると、SCTPは、ピアのアダプテーションレイヤ表示についてアプリケーションに通知するために、この通知を配信します。
struct sctp_adaptation_event {
uint16_t sai_type;
uint16_t sai_flags;
uint32_t sai_length;
uint32_t sai_adaptation_ind;
sctp_assoc_t sai_assoc_id;
};
sai_type: This field should be set to SCTP_ADAPTATION_INDICATION.
sai_type：このフィールドはSCTP_ADAPTATION_INDICATIONに設定する必要があります。
sai_flags: This field is currently unused.
sai_flags：このフィールドは現在未使用です。
sai_length: This field is the total length of the notification data, including the notification header. It will generally be sizeof(struct sctp_adaptation_event).
sai_length：このフィールドは、通知ヘッダを含む、通知データの全長です。これは、一般的にはsizeof（構造体sctp_adaptation_event）となります。
sai_adaptation_ind: This field holds the bit array sent by the peer in the Adaptation Layer Indication parameter.
sai_adaptation_ind：このフィールドは、アダプテーションレイヤの表示パラメータのピアによって送信されたビット列を保持しています。
sai_assoc_id: The sai_assoc_id field holds the identifier for the association. All notifications for a given association have the same association identifier. For a one-to-one style socket, this field is ignored.
sai_assoc_id：sai_assoc_idフィールドは関連の識別子を保持しています。与えられたアソシエーションのすべての通知は、同じアソシエーションIDを持っています。 1対1のスタイルのソケットの場合、このフィールドは無視されます。
When a receiver is engaged in a partial delivery of a message, this notification will be used to indicate various events.
受信機は、メッセージの部分配信に従事している場合、この通知は、様々なイベントを示すために使用されるであろう。
struct sctp_pdapi_event {
uint16_t pdapi_type;
uint16_t pdapi_flags;
uint32_t pdapi_length;
uint32_t pdapi_indication;
uint32_t pdapi_stream;
uint32_t pdapi_seq;
sctp_assoc_t pdapi_assoc_id;
};
pdapi_type: This field should be set to SCTP_PARTIAL_DELIVERY_EVENT.
pdapi_type：このフィールドはSCTP_PARTIAL_DELIVERY_EVENTに設定する必要があります。
pdapi_flags: This field is currently unused.
pdapi_flags：このフィールドは、現在使用されていません。
pdapi_length: This field is the total length of the notification data, including the notification header. It will generally be sizeof(struct sctp_pdapi_event).
pdapi_length：このフィールドは、通知ヘッダを含む、通知データの全長です。これは、一般的にはsizeof（構造体sctp_pdapi_event）となります。
pdapi_indication: This field holds the indication being sent to the application. Currently, there is only one defined value:
pdapi_indication：このフィールドは、アプリケーションに送信された表示を保持しています。現在、唯一の定義された値があります：
SCTP_PARTIAL_DELIVERY_ABORTED: This indicates that the partial delivery of a user message has been aborted. This happens, for example, if an association is aborted while a partial delivery is going on or the user message gets abandoned using PR-SCTP while the partial delivery of this message is going on.
SCTP_PARTIAL_DELIVERY_ABORTED：これは、ユーザーのメッセージの部分配信が中断されたことを示しています。部分的な送達が起こっているか、またはこのメッセージの部分的な配信が起こっている間に、ユーザメッセージがPR-SCTPを使用して放棄されますながらアソシエーションが中止されている場合、これは、例えば、起こります。
pdapi_stream: This field holds the stream on which the partial delivery event happened.
pdapi_stream：このフィールドは、部分的な配信イベントが起こったストリームを保持しています。
pdapi_seq: This field holds the stream sequence number that was being partially delivered.
pdapi_seq：このフィールドは、部分的に配信されたストリームのシーケンス番号を保持しています。
pdapi_assoc_id: The pdapi_assoc_id field holds the identifier for the association. All notifications for a given association have the same association identifier. For a one-to-one style socket, this field is ignored.
pdapi_assoc_id：pdapi_assoc_idフィールドは関連の識別子を保持しています。与えられたアソシエーションのすべての通知は、同じアソシエーションIDを持っています。 1対1のスタイルのソケットの場合、このフィールドは無視されます。
[RFC4895] defines an extension to authenticate SCTP messages. The following notification is used to report different events relating to the use of this extension.
[RFC4895]はSCTPメッセージを認証するための拡張を定義します。以下の通知は、この拡張機能の使用に関連するさまざまなイベントを報告するために使用されます。
struct sctp_authkey_event {
uint16_t auth_type;
uint16_t auth_flags;
uint32_t auth_length;
uint16_t auth_keynumber;
uint32_t auth_indication;
sctp_assoc_t auth_assoc_id;
};
auth_type: This field should be set to SCTP_AUTHENTICATION_EVENT.
AUTH_TYPE：このフィールドはSCTP_AUTHENTICATION_EVENTに設定する必要があります。
auth_flags: This field is currently unused.
auth_flags：このフィールドは現在未使用です。
auth_length: This field is the total length of the notification data, including the notification header. It will generally be sizeof(struct sctp_authkey_event).
auth_length：このフィールドは、通知ヘッダを含む、通知データの全長です。これは、一般的にはsizeof（構造体sctp_authkey_event）となります。
auth_keynumber: This field holds the key number for the affected key indicated in the event (depends on auth_indication).
auth_keynumber：このフィールドは、イベント（auth_indicationによって異なります）で示され、影響を受けたキーのキー番号を保持しています。
auth_indication: This field holds the error or indication being reported. The following values are currently defined:
auth_indication：このフィールドは、報告されたエラーまたは表示を保持しています。次の値が現在定義されています：
SCTP_AUTH_NEW_KEY: This report indicates that a new key has been made active (used for the first time by the peer) and is now the active key. The auth_keynumber field holds the user-specified key number.
SCTP_AUTH_NEW_KEY：このレポートは、新しいキーが（ピアによって初めて使用）アクティブにされたことを示し、現在アクティブなキーです。 auth_keynumberフィールドは、ユーザーが指定したキー番号を保持しています。
SCTP_AUTH_NO_AUTH: This report indicates that the peer does not support SCTP authentication as defined in [RFC4895].
SCTP_AUTH_NO_AUTH：このレポートは、[RFC4895]で定義されているピアがSCTP認証をサポートしていないことを示しています。
SCTP_AUTH_FREE_KEY: This report indicates that the SCTP implementation will no longer use the key identifier specified in auth_keynumber.
SCTP_AUTH_FREE_KEY：このレポートでは、SCTPの実装は、もはやauth_keynumberで指定したキーの識別子を使用していないことを示します。
auth_assoc_id: The auth_assoc_id field holds the identifier for the association. All notifications for a given association have the same association identifier. For a one-to-one style socket, this field is ignored.
auth_assoc_id：auth_assoc_idフィールドは、協会の識別子を保持しています。与えられたアソシエーションのすべての通知は、同じアソシエーションIDを持っています。 1対1のスタイルのソケットの場合、このフィールドは無視されます。
When the SCTP stack has no more user data to send or retransmit, this notification is given to the user. Also, at the time when a user app subscribes to this event, if there is no data to be sent or retransmit, the stack will immediately send up this notification.
SCTPスタックが送信または再送信するためにこれ以上のユーザデータを持っている場合は、この通知がユーザーに与えられています。また、送信または再送信するデータが存在しない場合は、ユーザーのアプリは、このイベントに加入する時に、スタックがすぐにこの通知を送信します。
struct sctp_sender_dry_event {
uint16_t sender_dry_type;
uint16_t sender_dry_flags;
uint32_t sender_dry_length;
sctp_assoc_t sender_dry_assoc_id;
};
sender_dry_type: This field should be set to SCTP_SENDER_DRY_EVENT.
sender_dry_type：このフィールドはSCTP_SENDER_DRY_EVENTに設定する必要があります。
sender_dry_flags: This field is currently unused.
sender_dry_flags：このフィールドは現在未使用です。
sender_dry_length: This field is the total length of the notification data, including the notification header. It will generally be sizeof(struct sctp_sender_dry_event).
sender_dry_length：このフィールドは、通知ヘッダを含む、通知データの全長です。これは、一般的にはsizeof（構造体sctp_sender_dry_event）となります。
sender_dry_assoc_id: The sender_dry_assoc_id field holds the identifier for the association. All notifications for a given association have the same association identifier. For a one-to-one style socket, this field is ignored.
sender_dry_assoc_id：sender_dry_assoc_idフィールドが関連するための識別子を保持しています。与えられたアソシエーションのすべての通知は、同じアソシエーションIDを持っています。 1対1のスタイルのソケットの場合、このフィールドは無視されます。
SCTP notifications, when subscribed to, are reliable. They are always delivered as long as there is space in the socket receive buffer. However, if an implementation experiences a notification storm, it may run out of socket buffer space. When this occurs, it may wish to disable notifications. If the implementation chooses to do this, it will append a final notification SCTP_NOTIFICATIONS_STOPPED_EVENT. This notification is a union sctp_notification, where only the sctp_tlv structure (see the union above) is used. It only contains this type in the sn_type field, the sn_length field set to the size of an sctp_tlv structure, and the sn_flags set to 0. If an application receives this notification, it will need to re-subscribe to any notifications of interest to it, except for the sctp_data_io_event (note that SCTP_EVENTS is deprecated).
契約時にSCTP通知は、信頼性があります。彼らはいつものように長いソケットの受信バッファに空きがあるとして配信されます。実装は、通知の嵐を経験する場合は、それはソケットバッファスペースが不足することがあります。これが発生すると、それは通知を無効にすることもできます。実装がこれを行うことを選択した場合、それは、最終的な通知SCTP_NOTIFICATIONS_STOPPED_EVENTを追加します。この通知は、sctp_tlv構造（上記組合を参照）を使用する組合sctp_notification、です。それが唯一のsn_typeフィールドで、このタイプ、sctp_tlv構造のサイズ、およびアプリケーションは、この通知を受けた場合は0に設定sn_flagsに設定sn_lengthフィールドが含まれている、それはそれに関心のいずれかの通知に再加入する必要があります。 、sctp_data_io_event以外（SCTP_EVENTSは廃止されることに注意してください）。
An endpoint is automatically subscribed to this event as soon as it is subscribed to any event other than data io events.
エンドポイントが自動的にすぐにそれがイベントIOデータ以外のイベントにサブスクライブされているとして、このイベントにサブスクライブされています。
If SCTP cannot deliver a message, it can return back the message as a notification if the SCTP_SEND_FAILED_EVENT event is enabled. The notification has the following format:
SCTPは、メッセージを配信できない場合SCTP_SEND_FAILED_EVENTイベントが有効になっている場合、それは通知としてメッセージをバック返すことができます。通知の形式は次のとおりです。
struct sctp_send_failed_event {
uint16_t ssfe_type;
uint16_t ssfe_flags;
uint32_t ssfe_length;
uint32_t ssfe_error;
struct sctp_sndinfo ssfe_info;
sctp_assoc_t ssfe_assoc_id;
uint8_t ssfe_data[];
};
ssfe_type: This field should be set to SCTP_SEND_FAILED_EVENT.
ssfe_type：このフィールドはSCTP_SEND_FAILED_EVENTに設定する必要があります。
ssfe_flags: The flag value will take one of the following values:
ssfe_flags：フラグ値は、次のいずれかの値をとります。
SCTP_DATA_UNSENT: This value indicates that the data was never put on the wire.
SCTP_DATA_UNSENT：この値は、データがワイヤの上に置かれなかったことを示しています。
SCTP_DATA_SENT: This value indicates that the data was put on the wire. Note that this does not necessarily mean that the data was (or was not) successfully delivered.
SCTP_DATA_SENT：この値は、データがワイヤの上に置かれたことを示しています。これは必ずしも正常に配信されたデータだった（またはしなかった）ことを意味しないことに注意してください。
ssfe_length: This field is the total length of the notification data, including the notification header and the payload in ssf_data.
ssfe_length：このフィールドは、通知ヘッダとssf_dataでペイロードを含む、通知データの全長です。
ssfe_error: This value represents the reason why the send failed, and if set, will be an SCTP protocol error code as defined in Section 3.3.10 of [RFC4960].
ssfe_error：[RFC4960]のセクション3.3.10で定義されるように、この値は、送信が失敗した理由を表し、そして設定されている場合、SCTPプロトコルエラーコードであろう。
ssfe_info: This field includes the ancillary data (struct sctp_sndinfo) used to send the undelivered message. Regardless of whether ancillary data is used or not, the ssfe_info.sinfo_flags field indicates whether the complete message or only part of the message is returned in ssf_data. If only part of the message is returned, it means that the part that is not present has been sent successfully to the peer.
ssfe_info：このフィールドは、未配信のメッセージを送信するために使用される補助データ（構造体sctp_sndinfo）を含みます。かかわらず、補助データが使用されているか否かに、ssfe_info.sinfo_flagsフィールドは、完全なメッセージまたはメッセージの一部のみがssf_dataに返されるかどうかを示します。メッセージの一部のみが返された場合、それが存在しない部分がピアに正常に送信されたことを意味します。
If the complete message cannot be sent, the SCTP_DATA_NOT_FRAG flag is set in ssfe_info.sinfo_flags. If the first part of the message is sent successfully, SCTP_DATA_LAST_FRAG is set. This means that the tail end of the message is returned in ssf_data.
完全なメッセージが送信できない場合は、SCTP_DATA_NOT_FRAGフラグがssfe_info.sinfo_flagsに設定されています。メッセージの最初の部分が正常に送信された場合、SCTP_DATA_LAST_FRAGが設定されています。これは、メッセージの末尾がssf_dataで返されることを意味します。
ssfe_assoc_id: The ssfe_assoc_id field, ssf_assoc_id, holds the identifier for the association. All notifications for a given association have the same association identifier. For a one-to-one style socket, this field is ignored.
ssfe_assoc_id：ssfe_assoc_idフィールド、ssf_assoc_idは、協会の識別子を保持しています。与えられたアソシエーションのすべての通知は、同じアソシエーションIDを持っています。 1対1のスタイルのソケットの場合、このフィールドは無視されます。
ssfe_data: The undelivered message or part of the undelivered message will be present in the ssf_data field. Note that the ssf_info.sinfo_flags field as noted above should be used to determine whether a complete message or just a piece of the message is present. Note that only user data is present in this field; any chunk headers or SCTP common headers must be removed by the SCTP stack.
ssfe_data：未配信メッセージの未配信メッセージまたは一部をssf_dataフィールドに存在するであろう。上記のように述べssf_info.sinfo_flagsフィールドは、メッセージの完全なメッセージまたは単に部分が存在するかどうかを決定するために使用されるべきであることに留意されたいです。ユーザデータのみがこの分野で存在していることに注意してください。すべてのチャンクヘッダやSCTP共通ヘッダは、SCTPスタックによって除去されなければなりません。
Please note that this option is deprecated. Use the SCTP_EVENT option described in Section 6.2.2 instead.
このオプションは推奨されませんのでご注意ください。代わりに、6.2.2項で説明SCTP_EVENTオプションを使用します。
To receive SCTP event notifications, an application registers its interest by setting the SCTP_EVENTS socket option. The application then uses recvmsg() to retrieve notifications. A notification is stored in the data part (msg_iov) of the msghdr structure. The socket option uses the following structure:
SCTPのイベント通知を受信するには、アプリケーションがSCTP_EVENTSソケットオプションを設定することにより、その関心を登録します。次に、アプリケーションは、通知を取得するためのrecvmsg（）を使用しています。通知は、msghdr構造体のデータ部分（msg_iov）に格納されています。ソケットオプションには、次の構造を使用しています：
struct sctp_event_subscribe {
uint8_t sctp_data_io_event;
uint8_t sctp_association_event;
uint8_t sctp_address_event;
uint8_t sctp_send_failure_event;
uint8_t sctp_peer_error_event;
uint8_t sctp_shutdown_event;
uint8_t sctp_partial_delivery_event;
uint8_t sctp_adaptation_layer_event;
uint8_t sctp_authentication_event;
uint8_t sctp_sender_dry_event;
};
sctp_data_io_event: Setting this flag to 1 will cause the reception of SCTP_SNDRCV information on a per-message basis. The application will need to use the recvmsg() interface so that it can receive the event information contained in the msg_control field. Setting the flag to 0 will disable the reception of the message control information. Note that this flag is not really a notification and is stored in the ancillary data (msg_control), not in the data part (msg_iov).
sctp_data_io_event：このフラグを1に設定すると、メッセージごとにSCTP_SNDRCV情報の受信が発生します。アプリケーションは、それがmsg_controlフィールドに含まれるイベント情報を受け取ることができるようにのrecvmsg（）インタフェースを使用する必要があります。 0にフラグを設定すると、メッセージ制御情報の受信を無効にします。このフラグは、実際の通知でないとしないデータ部分（msg_iov）において、補助データ（msg_control）に格納されていることに留意されたいです。
sctp_association_event: Setting this flag to 1 will enable the reception of association event notifications. Setting the flag to 0 will disable association event notifications.
sctp_association_event：このフラグを1に設定すると、関連イベントの通知の受信を可能にします。 0にフラグを設定すると、関連イベントの通知を無効にします。
sctp_address_event: Setting this flag to 1 will enable the reception of address event notifications. Setting the flag to 0 will disable address event notifications.
sctp_address_event：このフラグを1に設定すると、アドレスのイベント通知の受信を可能にします。 0にフラグを設定すると、アドレスのイベント通知を無効にします。
sctp_send_failure_event: Setting this flag to 1 will enable the reception of send failure event notifications. Setting the flag to 0 will disable send failure event notifications.
sctp_send_failure_event：このフラグを1に設定すると、送信失敗イベント通知の受信を可能にします。 0にフラグを設定すると、障害イベント通知を送信できなくなります。
sctp_peer_error_event: Setting this flag to 1 will enable the reception of peer error event notifications. Setting the flag to 0 will disable peer error event notifications.
sctp_peer_error_event：1まで、このフラグを設定すると、ピア・エラー・イベント通知の受信を有効にするであろう。 0にフラグを設定すると、ピア・エラー・イベント通知を無効にします。
sctp_shutdown_event: Setting this flag to 1 will enable the reception of shutdown event notifications. Setting the flag to 0 will disable shutdown event notifications.
sctp_shutdown_event：このフラグを1に設定すると、シャットダウンイベントの通知の受信を可能にします。 0にフラグを設定すると、シャットダウンイベントの通知を無効にします。
sctp_partial_delivery_event: Setting this flag to 1 will enable the reception of partial delivery event notifications. Setting the flag to 0 will disable partial delivery event notifications.
sctp_partial_delivery_event：このフラグを1に設定すると、部分的な配信イベント通知の受信を可能にします。 0にフラグを設定すると、一部の配信イベントの通知を無効にします。
sctp_adaptation_layer_event: Setting this flag to 1 will enable the reception of adaptation layer event notifications. Setting the flag to 0 will disable adaptation layer event notifications.
sctp_adaptation_layer_event：このフラグを1に設定すると、アダプテーション層イベント通知の受信を可能にします。 0にフラグを設定すると、アダプテーション層イベント通知を無効にします。
sctp_authentication_event: Setting this flag to 1 will enable the reception of authentication layer event notifications. Setting the flag to 0 will disable authentication layer event notifications.
sctp_authentication_event：このフラグを1に設定すると、認証層イベント通知の受信を可能にします。 0にフラグを設定すると、認証レイヤイベント通知を無効にします。
sctp_sender_dry_event: Setting this flag to 1 will enable the reception of sender dry event notifications. Setting the flag to 0 will disable sender dry event notifications.
sctp_sender_dry_event：このフラグを1に設定すると、送信者のドライイベント通知の受信を可能にします。 0にフラグを設定すると、送信者のドライイベント通知を無効にします。
An example where an application would like to receive data_io_events and association_events but no others would be as follows:
次のようにアプリケーションがdata_io_eventsとassociation_eventsなくない他の人を受信したいの例は次のようになります。
{ struct sctp_event_subscribe events;
{構造体イベントをsctp_event_subscribe。
memset(&events, 0, sizeof(events));
memset（＆イベント、0、はsizeof（イベント））。
events.sctp_data_io_event = 1;
events.sctp_association_event = 1;
setsockopt(sd, IPPROTO_SCTP, SCTP_EVENTS, &events, sizeof(events)); }
setsockopt（SD、IPPROTO_SCTP、SCTP_EVENTS、＆イベント、のsizeof（イベント））。 }
Note that for one-to-many style SCTP sockets, the caller of recvmsg() receives ancillary data and notifications for all associations bound to the file descriptor. For one-to-one style SCTP sockets, the caller receives ancillary data and notifications only for the single association bound to the file descriptor.
一対多スタイルのSCTPソケットのために、のrecvmsg（）の呼び出し元がファイルディスクリプタにバインドされたすべての関連付けのための補助的なデータや通知を受け取ることに注意してください。 1対1スタイルのSCTPソケットの場合、呼び出し側は、専用のファイル記述子にバインドされた単一の関連付けのための補助的なデータと通知を受け取ります。
By default, both the one-to-one style and the one-to-many style socket do not subscribe to any notification.
デフォルトでは、一対一のスタイルと1対多のスタイルのソケットの両方が任意の通知に加入していません。
The SCTP_EVENTS socket option has one issue for future compatibility. As new features are added, the structure (sctp_event_subscribe) must be expanded. This can cause an application binary interface (ABI) issue unless an implementation has added padding at the end of the structure. To avoid this problem, SCTP_EVENTS has been deprecated and a new socket option SCTP_EVENT has taken its place. The option is used with the following structure:
SCTP_EVENTSソケットオプションは、将来の互換性のための1つの問題があります。新機能が追加されると、構造（sctp_event_subscribe）が展開されている必要があります。実装構造の終わりにパディングが追加されていない限り、これは、アプリケーションバイナリインタフェース（ABI）問題を引き起こす可能性があります。この問題を回避するには、SCTP_EVENTSは廃止され、新しいソケットオプションSCTP_EVENTは、その場所をとっています。オプションは次の構造で使用されます。
struct sctp_event {
sctp_assoc_t se_assoc_id;
uint16_t se_type;
uint8_t se_on;
};
se_assoc_id: The se_assoc_id field is ignored for one-to-one style sockets. For one-to-many style sockets, this field can be a particular association identifier or SCTP_{FUTURE|CURRENT| ALL}_ASSOC.
se_assoc_id：se_assoc_idフィールドは1対1スタイルソケットでは無視されます。 CURRENT |一対多スタイルのソケットでは、このフィールドは、特定のアソシエーション識別子またはSCTP_ {FUTUREことができます| ALL} _ASSOC。
se_type: The se_type field can be filled with any value that would show up in the respective sn_type field (in the sctp_tlv structure of the notification).
se_type：se_typeフィールドは、（通知のsctp_tlv構造で）各sn_typeフィールドに現れることになる任意の値で充填することができます。
se_on: The se_on field is set to 1 to turn on an event and set to 0 to turn off an event.
se_on：se_onフィールドがイベントをオンにするために1に設定し、イベントをオフにするには0に設定されています。
To use this option, the user fills in this structure and then calls setsockopt() to turn on or off an individual event. The following is an example use of this option:
このオプションを使用するには、ユーザーがオンまたは個々のイベントオフにするのsetsockopt（）を呼び出して、この構造体に充填して。以下は、このオプションの使用例です：
{ struct sctp_event event;
{構造体sctp_eventイベント。
memset(&event, 0, sizeof(event));
memset（＆イベント、0、はsizeof（イベント））。
event.se_assoc_id = SCTP_FUTURE_ASSOC;
event.se_type = SCTP_SENDER_DRY_EVENT;
event.se_on = 1;
setsockopt(sd, IPPROTO_SCTP, SCTP_EVENT, &event, sizeof(event));
}
By default, both the one-to-one style and the one-to-many style socket do not subscribe to any notification.
デフォルトでは、一対一のスタイルと1対多のスタイルのソケットの両方が任意の通知に加入していません。
Applications can use send() and sendto() to transmit data to the peer of an SCTP endpoint. recv() and recvfrom() can be used to receive data from the peer.
アプリケーションは、SCTPエンドポイントのピアにデータを送信するために送信（）とのsendto（）を使用することができます。 RECV（）とのrecvfrom（）は、ピアからデータを受信するために使用することができます。
The function prototypes are
関数プロトタイプは、
ssize_t send(int sd, const void *msg, size_t len, int flags);
ssize_tの（フラグをint型、int型のSD、CONSTのvoid *のMSG、size_tのLEN）を送ります。
ssize_t sendto(int sd, const void *msg, size_t len, int flags, const struct sockaddr *to, socklen_t tolen);
ssize_tのはsendto（int型SD、CONSTのvoid *のMSG、size_tのLEN、int型のフラグ、へのconstのsockaddr構造体の*、のsocklen_tのtolenの）;
ssize_t recv(int sd, void *buf, size_t len, int flags);
ssize_tのRECV（int型SD、無効* bufは、size_tのlenは、フラグをint型）;
ssize_t recvfrom(int sd, void *buf, size_t len, int flags, struct sockaddr *from, socklen_t *fromlen);
ssize_tののrecvfrom（fromlen *のsocklen_t、SD、無効* bufは、size_tのLEN、フラグをint型、構造体のsockaddr *からint型）;
and the arguments are
そして、引数は、
sd: The socket descriptor of an SCTP endpoint.
SD：SCTP終点のソケット記述子。
msg: The message to be sent.
MSG：メッセージを送信します。
len: The size of the message or the size of the buffer.
LEN：メッセージのサイズまたはバッファのサイズ。
to: One of the peer addresses of the association to be used to send the message.
：関連のピア・アドレスの1つのメッセージを送信するために使用されます。
tolen: The size of the address.
tolenの：アドレスのサイズ。
buf: The buffer to store a received message.
BUF：受信したメッセージを格納するバッファ。
from: The buffer to store the peer address used to send the received message.
From：受信したメッセージを送信するために使用されるピア・アドレスを格納するバッファ。
fromlen: The size of the from address.
fromlen：アドレスからのサイズ。
flags: (described below).
フラグ（後述）。
These calls give access to only basic SCTP protocol features. If either peer in the association uses multiple streams, or sends unordered data, these calls will usually be inadequate and may deliver the data in unpredictable ways.
これらの呼び出しは、基本的なSCTPプロトコルの機能へのアクセスを与えます。関連していずれかのピアが複数のストリームを使用して、または順序付けられていないデータを送信する場合、これらのコールは、通常不十分となり、予測不可能な方法でデータを配信してもよいです。
SCTP has the concept of multiple streams in one association. The above calls do not allow the caller to specify on which stream a message should be sent. The system uses stream 0 as the default stream for send() and sendto(). recv() and recvfrom() return data from any stream, but the caller cannot distinguish the different streams. This may result in data seeming to arrive out of order. Similarly, if a DATA chunk is sent unordered, recv() and recvfrom() provide no indication.
SCTPは、1つの団体で複数のストリームの概念があります。メッセージが送信されるべきストリームた上で上記の呼び出しは、呼び出し側が指定することはできません。システムは、送信（）とのsendtoのデフォルトのストリームとしてストリーム0を使用しています（）。 RECV（）とのrecvfrom（）戻り値の任意のストリームからのデータが、発信者は、異なるストリームを区別することができません。これは、順不同で到着する見せかけのデータをもたらすことができます。同様に、データチャンクが順不同送信される場合、RECV（）とのrecvfrom（）兆候を提供しません。
SCTP is message based. The msg buffer above in send() and sendto() is considered to be a single message. This means that if the caller wants to send a message that is composed by several buffers, the caller needs to combine them before calling send() or sendto(). Alternately, the caller can use sendmsg() to do that without combining them. Sending a message using send() or sendto() is atomic unless explicit EOR marking is enabled on the socket specified by sd. Using sendto() on a non-connected one-to-one style socket for implicit connection setup may or may not work, depending on the SCTP implementation. recv() and recvfrom() cannot distinguish message boundaries (i.e., there is no way to observe the MSG_EOR flag to detect partial delivery).
SCTPは、メッセージベースです。 MSGの送信における上記バッファ（）とのsendto（）は、単一のメッセージであると考えられます。これは、呼び出し側が複数のバッファにより構成されたメッセージを送信したい場合は、呼び出し側が送信（）またはのsendto（）を呼び出す前に、それらを結合する必要があることを意味します。代わりに、呼び出し側は、それらを組み合わせずにそれを行うには、sendmsg（）を使用することができます。マーキング明示EORをSDによって指定されたソケットで有効になっていない場合）（（送信用いメッセージ）またはのsendtoを送信する原子です。暗黙の接続設定のための非接続1対1のスタイルのソケット上のsendto（）を使用すると、またはSCTPの実装に依存し、動作しない場合があります。 RECV（）とのrecvfrom（）（すなわち、部分的な送達を検出するMSG_EORフラグを観察する方法はありません）メッセージの境界を区別することができません。
When receiving, if the buffer supplied is not large enough to hold a complete message, the receive call acts like a stream socket and returns as much data as will fit in the buffer.
提供されたバッファは、完全なメッセージを保持するのに十分でない場合、受信した場合に、ストリームソケットのようなコール行為を受け取り、バッファに収まる限り多くのデータを返します。
Note that the send() and recv() calls may not be used for a one-to-many style socket.
センド（）およびRECV（）呼び出しは1対多のスタイルのソケットに使用することはできませんので注意してください。
Note that if an application calls a send() or sendto() function with no user data, the SCTP implementation should reject the request with an appropriate error message. An implementation is not allowed to send a DATA chunk with no user data [RFC4960].
アプリケーションがユーザデータとともに送信（）またはのsendto（）関数を呼び出す場合、SCTPの実装は、適切なエラーメッセージで要求を拒否すべきであることに留意されたいです。実装は、ユーザデータ[RFC4960]とデータチャンクを送信することは許されません。
Applications use setsockopt() and getsockopt() to set or retrieve socket options. Socket options are used to change the default behavior of socket calls. They are described in Section 8.
アプリケーションは、ソケットオプションを設定または取得するためのsetsockopt（）とはgetsockopt（）を使用します。ソケットオプションはソケット呼び出しのデフォルトの動作を変更するために使用されています。彼らは、セクション8に記載されています。
The function prototypes are
関数プロトタイプは、
int getsockopt(int sd, int level, int optname, void *optval, socklen_t *optlen);
int型のgetsockopt（int型SD、int型のレベル、int型のOPTNAME、無効*はoptval、socklen_tを* optlen）;
and
そして
int setsockopt(int sd, int level, int optname, const void *optval, socklen_t optlen);
int型のsetsockopt（int型SD、int型のレベル、int型のOPTNAME、CONST void *型はoptval、socklen_tをoptlen）;
and the arguments are
そして、引数は、
sd: The socket descriptor.
SD：ソケット記述子。
level: Set to IPPROTO_SCTP for all SCTP options.
レベル：すべてのSCTPオプションについてIPPROTO_SCTPに設定してください。
optname: The option name.
OPTNAME：オプション名。
optval: The buffer to store the value of the option.
optval：オプションの値を格納するためのバッファ。
optlen: The size of the buffer (or the length of the option returned).
optlen：バッファのサイズ（またはオプションの長さが返されます）。
These functions return 0 on success and -1 in case of an error.
これらの関数は、エラーの場合には成功時に0と-1を返します。
All socket options set on a one-to-one style listening socket also apply to all future accepted sockets. For one-to-many style sockets, often a socket option will pass a structure that includes an assoc_id field. This field can be filled with the association identifier of a particular association and unless otherwise specified can be filled with one of the following constants:
1対1スタイルのリスニングソケットに設定されたすべてのソケットオプションは、すべての将来受け入れられたソケットに適用されます。 1対多スタイルソケットの場合、多くの場合、ソケットオプションはassoc_idフィールドを含む構造を渡します。このフィールドは、特定のアソシエーションのアソシエーション識別子で充填することができ、そうでなければ、次の定数のいずれかを充填することができる指定されない限り。
SCTP_FUTURE_ASSOC: Specifies that only future associations created after this socket option will be affected by this call.
SCTP_FUTURE_ASSOC：このソケットオプションの後に作成されただけで、将来の団体は、この呼び出しによって影響されることを指定します。
SCTP_CURRENT_ASSOC: Specifies that only currently existing associations will be affected by this call, and future associations will still receive the previous default value.
SCTP_CURRENT_ASSOC：唯一現存する団体は、この呼び出しによって影響されることを指定し、将来の団体は、まだ以前のデフォルト値を受け取ります。
SCTP_ALL_ASSOC: Specifies that all current and future associations will be affected by this call.
SCTP_ALL_ASSOC：現在および将来のすべての団体が、この呼び出しによって影響されることを指定します。
Applications can use read() and write() to receive and send data from and to a peer. They have the same semantics as recv() and send(), except that the flags parameter cannot be used.
アプリケーションは、ピアからとにデータを送受信するように）読んで（）と（書き込み使用することができます。彼らは、flagsパラメータを使用することができないことを除いて、）（（RECVと同じ意味を持っている）し、送信してください。
Applications use getsockname() to retrieve the locally bound socket address of the specified socket. This is especially useful if the caller let SCTP choose a local port. This call is for single-homed endpoints. It does not work well with multi-homed endpoints. See Section 9.5 for a multi-homed version of the call.
アプリケーションは、指定されたソケットのローカルにバインドされたソケットアドレスを取得するためにgetsockname（）を使用します。呼び出し側はSCTPがローカルポートを選択できた場合に特に便利です。この呼び出しは、シングルホームエンドポイントです。これは、マルチホームのエンドポイントでうまく動作しません。コールのマルチホームのバージョンの9.5節を参照してください。
The function prototype is
関数プロトタイプは、
int getsockname(int sd, struct sockaddr *address, socklen_t *len);
int型のgetsockname（int型SD、sockaddr構造体の*アドレス、のsocklen_t * LEN）;
and the arguments are
そして、引数は、
sd: The socket descriptor to be queried.
SD：照会するソケット記述子。
address: On return, one locally bound address (chosen by the SCTP stack) is stored in this buffer. If the socket is an IPv4 socket, the address will be IPv4. If the socket is an IPv6 socket, the address will be either an IPv6 or IPv4 address.
アドレス：戻ったとき、（SCTPスタックによって選択された）を一度ローカルに結合アドレスがこのバッファに格納されます。ソケットはIPv4ソケットである場合、アドレスは、IPv4となります。ソケットはIPv6ソケットである場合、アドレスは、IPv6またはIPv4アドレスのどちらかになります。
len: The caller should set the length of the address here. On return, this is set to the length of the returned address.
LEN：呼び出し側は、ここではアドレスの長さを設定する必要があります。リターンでは、これは、返されたアドレスの長さに設定されています。
getsockname() returns 0 on success and -1 in case of an error.
getsockname（）が成功すると0を返し、-1エラーの場合には。
If the actual length of the address is greater than the length of the supplied sockaddr structure, the stored address will be truncated.
アドレスの実際の長さは、供給されたsockaddr構造体の長さよりも大きい場合には、格納されたアドレスが切り捨てられます。
If the socket has not been bound to a local name, the value stored in the object pointed to by address is unspecified.
ソケットはローカル名にバインドされていない場合は、オブジェクトに格納された値が指定されていないアドレスで指されます。
The application can begin sending and receiving data using the sendmsg()/recvmsg() or sendto()/recvfrom() calls, without going through any explicit association setup procedures (i.e., no connect() calls required).
アプリケーション（すなわち、）（無接続が必要な呼び出していない）明示的な関連付け設定手順を経ることなく（）を呼び出し、にsendmsg（）/のrecvmsg（）またはのsendto（）/のrecvfromを使用してデータの送受信を開始することができます。
Whenever sendmsg() or sendto() is called and the SCTP stack at the sender finds that no association exists between the sender and the intended receiver (identified by the address passed either in the msg_name field of the msghdr structure in the sendmsg() call or the dest_addr field in the sendto() call), the SCTP stack will automatically set up an association to the intended receiver.
sendmsgの（）またはのsendto（）が呼び出され、送信側のSCTPスタックは全く関連のいずれかmsghdr構造体のはmsg_nameフィールド内にsendmsg（）呼び出しに渡されたアドレスによって識別される送信者と意図する受信機（の間に存在しないことが検出されたときまたはのsendto（）呼び出しでdest_addrはフィールド）は、SCTPスタックが自動的に意図された受信機への関連付けを設定します。
Upon successful association setup, an SCTP_COMM_UP notification will be dispatched to the socket at both the sender and receiver side. This notification can be read by the recvmsg() system call (see Section 3.1.4).
成功したアソシエーションのセットアップ時に、SCTP_COMM_UP通知が送信者と受信者側の両方でソケットにディスパッチされます。この通知はのrecvmsg（）システムコールで読み取ることができます（3.1.4項を参照してください）。
Note that if the SCTP stack at the sender side supports bundling, the first user message may be bundled with the COOKIE ECHO message [RFC4960].
送信側におけるSCTPスタックはバンドルをサポートしている場合、最初のユーザメッセージはCOOKIE ECHOメッセージ[RFC4960]にバンドルされてもよいことに留意されたいです。
When the SCTP stack sets up a new association implicitly, the SCTP_INIT type ancillary data may also be passed along (see Section 5.3.1 for details of the data structures) to change some parameters used in setting up a new association.
SCTPスタックが暗黙のうちに新しい関連付けを設定すると、SCTP_INITタイプの補助データは、新しい関連付けを設定する際に使用されるいくつかのパラメータを変更する（データ構造の詳細については、5.3.1項を参照）に沿って渡すことができます。
If this information is not present in the sendmsg() call, or if the implicit association setup is triggered by a sendto() call, the default association initialization parameters will be used. These default association parameters may be set with respective setsockopt() calls or be left to the system defaults.
この情報は、sendmsgの中に存在しない場合（）を呼び出す、または暗黙的な関連付けの設定がのsendto（）呼び出しによってトリガされた場合、デフォルトの関連の初期化パラメータが使用されます。これらのデフォルトの関連パラメータは、コールまたはシステムデフォルトに残される）（それぞれのsetsockoptで設定されてもよいです。
Implicit association setup cannot be initiated by send() calls.
暗黙の関連付けの設定は、send（）の呼び出しによって開始することができません。
The following subsection describes various SCTP-level socket options that are common to both styles. SCTP associations can be multi-homed. Therefore, certain option parameters include a sockaddr_storage structure to select to which peer address the option should be applied.
以下のサブセクションでは、両方のスタイルに共通している様々なSCTPレベルのソケットオプションを説明しています。 SCTPアソシエーションは、マルチホームすることができます。したがって、特定のオプションのパラメータが適用されるべきオプションに対処ピアれる選択するSOCKADDR_STORAGE構造を含みます。
For the one-to-many style sockets, an sctp_assoc_t (association identifier) parameter is used to identify the association instance that the operation affects. So it must be set when using this style.
1対多スタイルソケットの場合、sctp_assoc_t（関連識別子）パラメータは、操作によって影響を受けることがアソシエーション・インスタンスを識別するために使用されます。このスタイルを使用したときに、それを設定する必要があります。
For the one-to-one style sockets and branched-off one-to-many style sockets (see Section 9.2), this association ID parameter is ignored.
一対一の様式ソケットおよび分岐オフ一対多スタイルのソケット（セクション9.2を参照）、この関連IDパラメータは無視されます。
Note that socket- or IP-level options are set or retrieved per socket. This means that for one-to-many style sockets, the options will be applied to all associations (similar to using SCTP_ALL_ASSOC as the association identifier) belonging to the socket. For the one-to-one style, these options will be applied to all peer addresses of the association controlled by the socket. Applications should be careful in setting those options.
socket-またはIPレベルのオプションは、ソケットごとに設定または取得していることに注意してください。これは、1対多スタイルソケットに、オプションがソケットに属する（アソシエーション識別子としてSCTP_ALL_ASSOCを使用と同様に）すべての関連付けに適用されることを意味します。一対一のスタイルのために、これらのオプションは、ソケットによって制御関連のすべてのピアアドレスに適用されます。アプリケーションは、これらのオプションを設定する際に注意しなければなりません。
For some IP stacks, getsockopt() is read-only, so a new interface will be needed when information must be passed both into and out of the SCTP stack. The syntax for sctp_opt_info() is
一部のIPスタックの場合、のgetsockopt（）は読み取り専用されている情報は、にし、SCTPスタックのうち、両方渡さなければならないときに、その新しいインターフェイスが必要になります。 sctp_opt_infoの構文は（）であります
int sctp_opt_info(int sd, sctp_assoc_t id, int opt, void *arg, socklen_t *size);
int型と、sctp_opt_info（int型SD、sctp_assoc_t ID、int型のオプト、void *型のarg、のsocklen_t *サイズ）。
The sctp_opt_info() call is a replacement for getsockopt() only and will not set any options associated with the specified socket. A setsockopt() call must be used to set any writable option.
sctp_opt_info（）の呼び出しはgetsockoptのための代替（）のみで、指定されたソケットに関連付けられているすべてのオプションを設定しないであろう。 setsockopt（）の呼び出しは、任意の書き込み可能なオプションを設定するために使用する必要があります。
For one-to-many style sockets, id specifies the association to query. For one-to-one style sockets, id is ignored. For one-to-many style sockets, any association identifier in the structure provided as arg is ignored, and id takes precedence.
1対多のスタイルのソケットの場合、idが照会する関連付けを指定します。 1対1スタイルソケットの場合、idは無視されます。 1対多スタイルソケットの場合、引数として提供構造内の任意の関連識別子は無視され、IDが優先されます。
Note that SCTP_CURRENT_ASSOC and SCTP_ALL_ASSOC cannot be used with sctp_opt_info() or in getsockopt() calls. Using them will result in an error (returning -1 and errno set to EINVAL). SCTP_FUTURE_ASSOC can be used to query information for future associations.
SCTP_CURRENT_ASSOCとSCTP_ALL_ASSOCがと、sctp_opt_info（）またはgetsockoptの中（）呼び出しで使用することができないことに留意されたいです。それらを使用すると、（EINVALに設定し-1を返し、errnoに）エラーになります。 SCTP_FUTURE_ASSOCは将来の団体のための情報を照会するために使用することができます。
The field opt specifies which SCTP socket option to get. It can get any socket option currently supported that requests information (either read/write options or read-only) such as
フィールドoptは取得するにはどのSCTPソケットオプションを指定します。それは、次のような情報を要求し、現在サポートされている任意のソケットオプションを（/書き込みオプションを読み取りまたは読み取り専用のいずれか）を取得することができます
SCTP_RTOINFO
SCTP_RTOINFO
SCTP_ASSOCINFO
SCTP_ASSOCINFO
SCTP_PRIMARY_ADDR
SCTP_PRIMARY_ADDR
SCTP_PEER_ADDR_PARAMS
SCTP_PEER_ADDR_PARAMS
SCTP_DEFAULT_SEND_PARAM
SCTP_DEFAULT_SEND_PARAM
SCTP_MAX_SEG
SCTP_MAX_SEG
SCTP_AUTH_ACTIVE_KEY
SCTP_AUTH_ACTIVE_KEY
SCTP_DELAYED_SACK
SCTP_DELAYED_SACK
SCTP_MAX_BURST
SCTP_MAX_BURST
SCTP_CONTEXT
SCTP_CONTEXT
SCTP_EVENT
SCTP_EVENT
SCTP_DEFAULT_SNDINFO
SCTP_DEFAULT_SNDINFO
SCTP_DEFAULT_PRINFO
SCTP_DEFAULT_PRINFO
SCTP_STATUS
SCTP_STATUS
SCTP_GET_PEER_ADDR_INFO
SCTP_GET_PEER_ADDR_INFO
SCTP_PEER_AUTH_CHUNKS
SCTP_PEER_AUTH_CHUNKS
SCTP_LOCAL_AUTH_CHUNKS
SCTP_LOCAL_AUTH_CHUNKS
The arg field is an option-specific structure buffer provided by the caller. See the rest of this section for more information on these options and option-specific structures.
引数フィールドは、発信者によって提供オプション固有の構造バッファです。これらのオプションおよびオプション固有の構造の詳細については、このセクションの残りの部分を参照してください。
sctp_opt_info() returns 0 on success, or on failure returns -1 and sets errno to the appropriate error code.
sctp_opt_info（）が成功した、または失敗戻り0を-1を返し、適切なエラーコードをerrnoに設定します。
The protocol parameters used to initialize and limit the retransmission timeout (RTO) are tunable. See [RFC4960] for more information on how these parameters are used in RTO calculation.
再送タイムアウト（RTO）を初期化し、制限するために使用されるプロトコルパラメータが調整可能です。これらのパラメータはRTOの計算に使用されている方法の詳細については、[RFC4960]を参照してください。
The following structure is used to access and modify these parameters:
以下の構造は、これらのパラメータにアクセスして変更するために使用されます。
struct sctp_rtoinfo {
sctp_assoc_t srto_assoc_id;
uint32_t srto_initial;
uint32_t srto_max;
uint32_t srto_min;
};
srto_assoc_id: This parameter is ignored for one-to-one style sockets. For one-to-many style sockets, the application may fill in an association identifier or SCTP_FUTURE_ASSOC. It is an error to use SCTP_{CURRENT|ALL}_ASSOC in srto_assoc_id.
srto_assoc_id：このパラメータは、1対1スタイルソケットでは無視されます。 1対多スタイルソケットの場合、アプリケーションは、関連識別子またはSCTP_FUTURE_ASSOCに充填することができます。 srto_assoc_idで_ASSOC | SCTP_ {ALL CURRENT}を使用するとエラーになります。
srto_initial: This parameter contains the initial RTO value.
srto_initial：このパラメータは初期RTO値が含まれています。
srto_max and srto_min: These parameters contain the maximum and minimum bounds for all RTOs.
srto_maxとsrto_min：これらのパラメータは、すべてのRTOの最大値と最小値の境界が含まれています。
All times are given in milliseconds. A value of 0, when modifying the parameters, indicates that the current value should not be changed.
すべての時間はミリ秒単位で与えられています。 0の値は、パラメータを変更する場合、現在の値が変更されるべきでないことを示しています。
To access or modify these parameters, the application should call getsockopt() or setsockopt(), respectively, with the option name SCTP_RTOINFO.
アクセスしたり、これらのパラメータを変更するには、アプリケーションは、オプション名SCTP_RTOINFOで、それぞれ、）（）またはのsetsockopt（getsockoptのを呼び出す必要があります。
This option is used to both examine and set various association and endpoint parameters. See [RFC4960] for more information on how these parameters are used.
このオプションは、検査し、設定した各種団体とエンドポイントのパラメータの両方に使用されています。これらのパラメータの使用方法の詳細については、[RFC4960]を参照してください。
The following structure is used to access and modify these parameters:
以下の構造は、これらのパラメータにアクセスして変更するために使用されます。
struct sctp_assocparams {
sctp_assoc_t sasoc_assoc_id;
uint16_t sasoc_asocmaxrxt;
uint16_t sasoc_number_peer_destinations;
uint32_t sasoc_peer_rwnd;
uint32_t sasoc_local_rwnd;
uint32_t sasoc_cookie_life;
};
sasoc_assoc_id: This parameter is ignored for one-to-one style sockets. For one-to-many style sockets, the application may fill in an association identifier or SCTP_FUTURE_ASSOC. It is an error to use SCTP_{CURRENT|ALL}_ASSOC in sasoc_assoc_id.
sasoc_assoc_id：このパラメータは、1対1スタイルソケットでは無視されます。 1対多スタイルソケットの場合、アプリケーションは、関連識別子またはSCTP_FUTURE_ASSOCに充填することができます。 sasoc_assoc_idで_ASSOC | SCTP_ {ALL CURRENT}を使用するとエラーになります。
sasoc_asocmaxrxt: This parameter contains the maximum retransmission attempts to make for the association.
sasoc_asocmaxrxt：このパラメータは、協会のために作るための最大再送信試行が含まれています。
sasoc_number_peer_destinations: This parameter is the number of destination addresses that the peer has.
sasoc_number_peer_destinations：このパラメータは、ピアが持つ宛先アドレスの数です。
sasoc_peer_rwnd: This parameter holds the current value of the peer's rwnd (reported in the last selective acknowledgment (SACK)) minus any outstanding data (i.e., data in flight).
sasoc_peer_rwnd：このパラメータは、ピアのRWNDの電流値（最後の選択的確認応答（SACK）で報告された）マイナス未処理のデータ（飛行中、すなわち、データ）を保持しています。
sasoc_local_rwnd: This parameter holds the last reported rwnd that was sent to the peer.
sasoc_local_rwnd：このパラメータは、ピアに送信された最後の報告RWNDを保持しています。
sasoc_cookie_life: This parameter is the association's cookie life value used when issuing cookies.
sasoc_cookie_life：このパラメータは、クッキーを発行する際に使用関連のCookie寿命値です。
The value of sasoc_peer_rwnd is meaningless when examining endpoint information (i.e., it is only valid when examining information on a specific association).
エンドポイント情報（特定関連情報を検査するとき、すなわち、それだけ有効である）を調べるときsasoc_peer_rwndの値は無意味です。
All time values are given in milliseconds. A value of 0, when modifying the parameters, indicates that the current value should not be changed.
すべての時間の値はミリ秒単位で与えられています。 0の値は、パラメータを変更する場合、現在の値が変更されるべきでないことを示しています。
The values of sasoc_asocmaxrxt and sasoc_cookie_life may be set on either an endpoint or association basis. The rwnd and destination counts (sasoc_number_peer_destinations, sasoc_peer_rwnd, sasoc_local_rwnd) are not settable, and any value placed in these is ignored.
sasoc_asocmaxrxtとsasoc_cookie_lifeの値は、エンドポイントまたは関連基準のいずれかに設定することができます。 RWND及び宛先カウント（sasoc_number_peer_destinations、sasoc_peer_rwnd、sasoc_local_rwnd）が設定可能でない、及びこれらに置かれた値は無視されます。
To access or modify these parameters, the application should call getsockopt() or setsockopt(), respectively, with the option name SCTP_ASSOCINFO.
アクセスしたり、これらのパラメータを変更するには、アプリケーションは、オプション名SCTP_ASSOCINFOで、それぞれ、）（）またはのsetsockopt（getsockoptのを呼び出す必要があります。
The maximum number of retransmissions before an address is considered unreachable is also tunable, but is address-specific, so it is covered in a separate option. If an application attempts to set the value of the association's maximum retransmission parameter to more than the sum of all maximum retransmission parameters, setsockopt() may return an error. The reason for this, from Section 8.2 of [RFC4960], is as follows:
アドレスが到達不能と見なされる前に、再送信の最大数も調整可能ですが、アドレス固有のものであるため、それは別のオプションで覆われています。アプリケーションがすべての最大再送パラメータの和以上に協会の最大再送信パラメータの値を設定しようとすると、のsetsockopt（）はエラーを返してもよいです。次のように[RFC4960]のセクション8.2から、この理由は、次のとおりです。
Note: When configuring the SCTP endpoint, the user should avoid having the value of 'Association.Max.Retrans' (sasoc_maxrxt in this option) larger than the summation of the 'Path.Max.Retrans' (see spp_pathmaxrxt in Section 8.1.12) of all of the destination addresses for the remote endpoint. Otherwise, all of the destination addresses may become inactive while the endpoint still considers the peer endpoint reachable.
注意：SCTP終点を設定する場合、ユーザーが「Path.Max.Retrans」の合計よりも多い（このオプションではsasoc_maxrxt「）Association.Max.Retrans」の値を持つ避けるべきである（セクション8.1.12でspp_pathmaxrxtを見ます）リモートエンドポイントの宛先アドレスのすべての。エンドポイントがまだ到達可能なピア・エンドポイントを考慮しながら、それ以外の場合は、宛先アドレスの全てが非アクティブになることがあります。
Applications can specify protocol parameters for the default association initialization. The structure used to access and modify these parameters is defined in Section 5.3.1. The option name argument to setsockopt() and getsockopt() is SCTP_INITMSG.
アプリケーションは、デフォルトの関連の初期化のためのプロトコルパラメータを指定することができます。これらのパラメータにアクセスして変更するのに使用される構造は、5.3.1項で定義されています。オプション名のsetsockopt（）の引数とはgetsockopt（）がSCTP_INITMSGです。
Setting initialization parameters is effective only on an unconnected socket (for one-to-many style sockets, only future associations are affected by the change).
初期化パラメータを設定すると、（1対多スタイルソケットのために、唯一の将来のアソシエーションは変更によって影響を受ける）のみ接続されていないソケットに効果的です。
An application can use this option to perform the SCTP ABORT primitive. This option affects all associations related to the socket.
アプリケーションは、プリミティブABORT SCTPを実行するには、このオプションを使用することができます。このオプションは、ソケットに関連するすべての関連付けに影響を与えます。
The linger option structure is
リンガオプション構造であります
struct linger {
int l_onoff; /* option on/off */
int l_linger; /* linger time */
};
To enable the option, set l_onoff to 1. If the l_linger value is set to 0, calling close() is the same as the ABORT primitive. If the value is set to a negative value, the setsockopt() call will return an error. If the value is set to a positive value linger_time, the close() can be blocked for at most linger_time. Please note that the time unit is in seconds, according to POSIX, but might be different on specific platforms. If the graceful shutdown phase does not finish during this period, close() will return, but the graceful shutdown phase will continue in the system.
）（closeを呼び出し、l_linger値が0に設定されている場合は1にはl_onoff設定オプションを有効にするには、プリミティブABORTと同じです。値が負の値に設定されている場合、のsetsockopt（）の呼び出しはエラーを返します。値が正の値のlinger_timeに設定されている場合は、クローズ（）は、ほとんどのlinger_timeでのためにブロックすることができます。時間単位は、POSIXによると、数秒であるが、特定のプラットフォーム上で異なる場合がございますのでご了承ください。正常なシャットダウンフェーズは、この期間中に完了しない場合は、近くに（）を返しますが、正常なシャットダウン・フェーズでは、システムに継続されます。
Note that this is a socket-level option, not an SCTP-level option. When using this option, an application must specify a level of SOL_SOCKET in the call.
これはソケットレベルのオプションではなく、SCTPレベルのオプションであることに注意してください。このオプションを使用すると、アプリケーションがコールにSOL_SOCKETのレベルを指定する必要があります。
This option turns on/off any Nagle-like algorithm. This means that packets are generally sent as soon as possible, and no unnecessary delays are introduced, at the cost of more packets in the network. In particular, not using any Nagle-like algorithm might reduce the bundling of small user messages in cases where this would require an additional delay.
このオプションは、任意のネーグルのようなアルゴリズムをオン/オフします。これは、パケットは、一般的に、できるだけ早く送信され、不要な遅延は、ネットワーク内のより多くのパケットのコストで、導入されないことを意味します。具体的には、任意のネーグルのようなアルゴリズムを使用していないことは、これは追加の遅延を必要とする場合は、小さなユーザメッセージのバンドルを減らすかもしれません。
Turning this option on disables any Nagle-like algorithm.
任意のネーグルのようなアルゴリズムが無効このオプションをオンに。
This option expects an integer boolean flag, where a non-zero value turns on the option, and a zero value turns off the option.
このオプションは、非ゼロ値がオプションをオン整数ブール・フラグを、期待、およびゼロ値がオプションをオフにします。
This option sets the receive buffer size in octets. For SCTP one-to-one style sockets, this option controls the receiver window size. For one-to-many style sockets, the meaning is implementation dependent. It might control the receive buffer for each association bound to the socket descriptor, or it might control the receive buffer for the whole socket. This option expects an integer.
このオプションは、オクテットで受信バッファのサイズを設定します。 SCTP 1対1スタイルソケットの場合、このオプションは、受信ウィンドウのサイズを制御します。 1対多のスタイルのソケットの場合、意味は実装依存です。これは、ソケット記述子にバインドされた各団体のための受信バッファを制御したり、それが全体のソケットの受信バッファを制御することがあります。このオプションは、整数を期待しています。
Note that this is a socket-level option, not an SCTP-level option. When using this option, an application must specify a level of SOL_SOCKET in the call.
これはソケットレベルのオプションではなく、SCTPレベルのオプションであることに注意してください。このオプションを使用すると、アプリケーションがコールにSOL_SOCKETのレベルを指定する必要があります。
This option sets the send buffer size. For SCTP one-to-one style sockets, this option controls the amount of data SCTP may have waiting in internal buffers to be sent. This option therefore bounds the maximum size of data that can be sent in a single send call. For one-to-many style sockets, the effect is the same, except that it applies to one or all associations (see Section 3.3) bound to the socket descriptor used in the setsockopt() or getsockopt() call. The option applies to each association's window size separately. This option expects an integer.
このオプションは、送信バッファサイズを設定します。 SCTP 1対1スタイルソケットの場合、このオプションが送信されるように内部バッファで待っていてデータSCTPの量を制御します。このオプションは、それゆえ、単一の送信呼び出しで送信できるデータの最大サイズを境界。 1対多のスタイルのソケットの場合、効果はそれはのsetsockopt（）やはgetsockopt（）の呼び出しで使用されるソケット記述子に結合した1つのまたはすべての関連付け（3.3節を参照）に適用されること以外は、同じです。オプションは、個別に各協会のウィンドウサイズに適用されます。このオプションは、整数を期待しています。
Note that this is a socket-level option, not an SCTP-level option. When using this option, an application must specify a level of SOL_SOCKET in the call.
これはソケットレベルのオプションではなく、SCTPレベルのオプションであることに注意してください。このオプションを使用すると、アプリケーションがコールにSOL_SOCKETのレベルを指定する必要があります。
This socket option is applicable to the one-to-many style socket only. When set, it will cause associations that are idle for more than the specified number of seconds to automatically close using the graceful shutdown procedure. An idle association is defined as an association that has not sent or received user data. The special value of '0' indicates that no automatic close of any association should be performed; this is the default value. This option expects an integer defining the number of seconds of idle time before an association is closed.
このソケットオプションは、1対多のスタイルのソケットのみ適用されます。設定した場合、それは指定された秒数よりも多くのためにアイドル状態になっている団体が自動的に閉じ正常なシャットダウン手順を使用します。アイドル状態の関連付けは、ユーザデータを送信または受信していないアソシエーションとして定義されます。 「0」の特別な値は、任意の関連のない自動クローズが行われないことを示しています。これはデフォルト値です。このオプションは、協会が閉じられるまでのアイドル時間の秒数を定義する整数を期待しています。
An application using this option should enable the ability to receive the association change notification. This is the only mechanism by which an application is informed about the closing of an association. After an association is closed, the association identifier assigned to it can be reused. An application should be aware of this to avoid the possible problem of sending data to an incorrect peer endpoint.
このオプションを使用するアプリケーションは、関連変更通知を受信する機能を有効にする必要があります。これは、アプリケーションが関連の閉鎖について通知される唯一のメカニズムです。アソシエーションが閉じられた後、それに割り当てられた関連識別子を再利用することができます。アプリケーションは、間違ったピア・エンドポイントにデータを送信する可能性の問題を回避するために、このことを認識する必要があります。
This option requests that the local SCTP stack uses the enclosed peer address as the association's primary. The enclosed address must be one of the association peer's addresses.
このオプションは、ローカルのSCTPスタックが協会のプライマリとして囲まれたピアアドレスを使用することを要求します。囲まれたアドレスは、関連付けピアのアドレスのいずれかでなければなりません。
The following structure is used to make a set peer primary request:
以下の構造は、主の要求をピアのセットを作るために使用されます。
struct sctp_setprim {
sctp_assoc_t ssp_assoc_id;
struct sockaddr_storage ssp_addr;
};
ssp_assoc_id: This parameter is ignored for one-to-one style sockets. For one-to-many style sockets, it identifies the association for this request. Note that the special sctp_assoc_t SCTP_{FUTURE|ALL|CURRENT}_ASSOC are not allowed.
ssp_assoc_id：このパラメータは、1対1スタイルソケットでは無視されます。 1対多のスタイルのソケットの場合、それはこの要求の関連付けを識別します。 _ASSOC許可されていない特殊なsctp_assoc_tのSCTP_ {| | ALL CURRENT FUTURE}があることに注意してください。
ssp_addr: This parameter is the address to set as primary. No wildcard address is allowed.
ssp_addr：このパラメータは、プライマリとして設定するためのアドレスです。ワイルドカードアドレスは許可されません。
This option requests that the local endpoint set the specified Adaptation Layer Indication parameter for all future INIT and INIT-ACK exchanges.
このオプションは、ローカルエンドポイントは、将来のすべてのINITとINIT-ACK交換のために指定アダプテーションレイヤ表示パラメータを設定することを要求します。
The following structure is used to access and modify this parameter:
次のような構造は、アクセスして、このパラメータを変更するために使用されます。
struct sctp_setadaptation {
uint32_t ssb_adaptation_ind;
};
ssb_adaptation_ind: The adaptation layer indicator that will be included in any outgoing Adaptation Layer Indication parameter.
ssb_adaptation_ind：任意の送信アダプテーションレイヤ表示パラメータに含まれるアダプテーション層インジケーター。
This option is an on/off flag and is passed as an integer, where a non-zero is on and a zero is off. If enabled, no SCTP message fragmentation will be performed. The effect of enabling this option is that if a message being sent exceeds the current Path MTU (PMTU) size, the message will not be sent and instead an error will be indicated to the user. If this option is disabled (the default), then a message exceeding the size of the PMTU will be fragmented and reassembled by the peer.
このオプションは、オン/オフのフラグであり、非ゼロであり、ゼロがオフである整数、として渡されます。有効にした場合、何のSCTPメッセージの断片化は行われません。このオプションを有効にする効果は、送信されるメッセージは、現在のパスMTU（PMTU）サイズを超えた場合、メッセージが送信されず、代わりにエラーがユーザに示されることです。このオプションが無効（デフォルト）の場合は、PMTUのサイズを超えるメッセージは、ピアによって断片化と再組み立てされます。
Applications can enable or disable heartbeats for any peer address of an association, modify an address's heartbeat interval, force a heartbeat to be sent immediately, and adjust the address's maximum number of retransmissions sent before an address is considered unreachable.
アプリケーションは、有効化または無効化団体のいずれかのピアアドレスのためのハートビートを、アドレスのハートビート間隔を変更し、すぐに送信されるハートビートを強制し、アドレスが到達不能と見なされる前に送られた再送信のアドレスの最大数を調整することができます。
The following structure is used to access and modify an address's parameters:
次のような構造は、アドレスのパラメータにアクセスし、修正するために使用されます。
struct sctp_paddrparams {
sctp_assoc_t spp_assoc_id;
struct sockaddr_storage spp_address;
uint32_t spp_hbinterval;
uint16_t spp_pathmaxrxt;
uint32_t spp_pathmtu;
uint32_t spp_flags;
uint32_t spp_ipv6_flowlabel;
uint8_t spp_dscp;
};
spp_assoc_id: This parameter is ignored for one-to-one style sockets. For one-to-many style sockets, the application may fill in an association identifier or SCTP_FUTURE_ASSOC for this query. It is an error to use SCTP_{CURRENT|ALL}_ASSOC in spp_assoc_id.
spp_assoc_id：このパラメータは、1対1スタイルソケットでは無視されます。 1対多のスタイルのソケットの場合、アプリケーションはこのクエリのアソシエーション識別子やSCTP_FUTURE_ASSOCに記入します。 spp_assoc_idで_ASSOC | SCTP_ {ALL CURRENT}を使用するとエラーになります。
spp_address: This specifies which address is of interest. If a wildcard address is provided, it applies to all current and future paths.
spp_address：これは、関心のあるアドレスを指定します。ワイルドカードアドレスが提供されている場合、それは現在および将来のすべてのパスに適用されます。
spp_hbinterval: This contains the value of the heartbeat interval, in milliseconds (HB.Interval in [RFC4960]). Note that unless the spp_flags field is set to SPP_HB_ENABLE, the value of this field is ignored. Note also that a value of zero indicates that the current setting should be left unchanged. To set an actual value of zero, the SPP_HB_TIME_IS_ZERO flag should be used. Even when it is set to 0, it does not mean that SCTP will continuously send out heartbeats, since the actual interval also includes the current RTO and jitter (see Section 8.3 of [RFC4960]).
spp_hbinterval：これは、ミリ秒（[RFC4960]でHB.Interval）において、ハートビート間隔の値を含みます。 spp_flagsフィールドがSPP_HB_ENABLEに設定されていない限り、このフィールドの値は無視されることに注意してください。ゼロの値は、現在の設定が変更されないままされるべきであることを示すことにも留意されたいです。ゼロの実際の値を設定し、SPP_HB_TIME_IS_ZEROフラグが使用されるべきです。それが0に設定されている場合でも、実際の間隔は、現在のRTOおよびジッタ（[RFC4960]のセクション8.3を参照）を備えているのでSCTPは、連続的にハートビートを送信することを意味するものではありません。
spp_pathmaxrxt: This contains the maximum number of retransmissions before this address shall be considered unreachable. Note that a value of zero indicates that the current setting should be left unchanged.
spp_pathmaxrxt：このアドレスは到達不可能とみなされる前に、これは、再送信の最大数が含まれています。ゼロの値が現在の設定が変更されないままする必要があることを示していることに注意してください。
spp_pathmtu: This field contains the current Path MTU of the peer address. It is the number of bytes available in an SCTP packet for chunks. Providing a value of 0 does not change the current setting. If a positive value is provided and SPP_PMTUD_DISABLE is set in the spp_flags field, the given value is used as the Path MTU. If SPP_PMTUD_ENABLE is set in the spp_flags field, the spp_pathmtu field is ignored.
spp_pathmtu：このフィールドは、ピアアドレスの現在のパスMTUが含まれています。これは、チャンクのためのSCTPパケットで利用可能なバイト数です。 0の値を提供することは、現在の設定を変更しません。正の値が提供され、SPP_PMTUD_DISABLEがspp_flagsフィールドに設定されている場合、所定の値は、パスMTUとして使用されます。 SPP_PMTUD_ENABLEがspp_flagsフィールドに設定されている場合は、spp_pathmtuフィールドは無視されます。
spp_flags: These flags are used to control various features on an association. The flag field is a bitmask that may contain zero or more of the following options:
spp_flags：これらのフラグは、協会にさまざまな機能を制御するために使用されています。フラグフィールドは、以下のオプションのゼロまたはそれ以上を含有することができるビットマスクです。
SPP_HB_ENABLE: This field enables heartbeats on the specified address.
SPP_HB_ENABLE：このフィールドは、指定されたアドレスにハートビートを有効にします。
SPP_HB_DISABLE: This field disables heartbeats on the specified address. Note that SPP_HB_ENABLE and SPP_HB_DISABLE are mutually exclusive; only one of these two should be specified. Enabling both fields will yield undetermined results.
SPP_HB_DISABLE：このフィールドは、指定されたアドレスにハートビートを無効にします。 SPP_HB_ENABLEとSPP_HB_DISABLEは相互に排他的であることに注意してください。のみこれらの二つのうちの一つを指定する必要があります。両方のフィールドを有効にすると、未決定の結果が得られます。
SPP_HB_DEMAND: This field requests that a user-initiated heartbeat be made immediately. This must not be used in conjunction with a wildcard address.
SPP_HB_DEMAND：ユーザーが開始したハートビートが即時に行われ、このフィールドを要求。これは、ワイルドカードアドレスと一緒に使用することはできません。
SPP_HB_TIME_IS_ZERO: This field specifies that the time for heartbeat delay is to be set to 0 milliseconds.
SPP_HB_TIME_IS_ZERO：このフィールドは、ハートビート遅延時間は0ミリ秒に設定することを指定します。
SPP_PMTUD_ENABLE: This field will enable PMTU discovery on the specified address.
SPP_PMTUD_ENABLE：このフィールドは、指定されたアドレスのPMTU検出を可能にします。
SPP_PMTUD_DISABLE: This field will disable PMTU discovery on the specified address. Note that if the address field is empty, then all addresses on the association are affected. Note also that SPP_PMTUD_ENABLE and SPP_PMTUD_DISABLE are mutually exclusive. Enabling both fields will yield undetermined results.
SPP_PMTUD_DISABLE：このフィールドは、指定されたアドレスのPMTU検出を無効にします。アドレスフィールドが空の場合は、その後、関連のすべてのアドレスが影響を受けていることに注意してください。 SPP_PMTUD_ENABLEとSPP_PMTUD_DISABLEは相互に排他的であることにも注意してください。両方のフィールドを有効にすると、未決定の結果が得られます。
SPP_IPV6_FLOWLABEL: Setting this flag enables the setting of the IPV6 flow label value. The value is contained in the spp_ipv6_flowlabel field.
SPP_IPV6_FLOWLABEL：このフラグを設定するには、IPv6フローラベル値の設定を可能にします。値がspp_ipv6_flowlabelフィールドに含まれています。
Upon retrieval, this flag will be set to indicate that the spp_ipv6_flowlabel field has a valid value returned. If a specific destination address is set (in the spp_address field), then the value returned is that of the address. If just an association is specified (and no address), then the association's default flow label is returned. If neither an association nor a destination is specified, then the socket's default flow label is returned. For non-IPv6 sockets, this flag will be left cleared.
検索時には、このフラグはspp_ipv6_flowlabelフィールドが有効な値が返されたことを示すために設定されます。特定の宛先アドレスが（spp_addressフィールドに）設定されている場合、返される値は、アドレスのことです。ちょうど協会が指定されていない（そしてアドレス）されている場合は、協会のデフォルトのフローラベルが返されます。協会も先も指定されている場合は、ソケットのデフォルトのフローラベルが返されます。非IPv6ソケットの場合、このフラグはクリアのままになります。
SPP_DSCP: Setting this flag enables the setting of the Differentiated Services Code Point (DSCP) value associated with either the association or a specific address. The value is obtained in the spp_dscp field.
SPP_DSCP：このフラグを設定すると、関連又は特定のアドレスのいずれかに関連付けられた差別化サービスコードポイント（DSCP）値の設定を可能にします。値がspp_dscpフィールドで得られます。
Upon retrieval, this flag will be set to indicate that the spp_dscp field has a valid value returned. If a specific destination address is set when called (in the spp_address field), then that specific destination address's DSCP value is returned. If just an association is specified, then the association's default DSCP is returned. If neither an association nor a destination is specified, then the socket's default DSCP is returned.
検索時には、このフラグはspp_dscpフィールドが有効な値が返されたことを示すために設定されます。 （spp_addressフィールドに）呼び出されたときに、特定の宛先アドレスが設定されている場合は、その特定の宛先アドレスのDSCP値が返されます。ちょうど協会が指定されている場合は、協会のデフォルトDSCPが返されます。協会も先も指定されている場合は、ソケットのデフォルトDSCPが返されます。
spp_ipv6_flowlabel: This field is used in conjunction with the SPP_IPV6_FLOWLABEL flag and contains the IPv6 flow label. The 20 least significant bits are used for the flow label. This setting has precedence over any IPv6-layer setting.
spp_ipv6_flowlabel：このフィールドはSPP_IPV6_FLOWLABELフラグと一緒に使用するとIPv6フローラベルが含まれています。 20の最下位ビットは、フローラベルに使用されます。この設定は、任意のIPv6のレイヤの設定よりも優先されます。
spp_dscp: This field is used in conjunction with the SPP_DSCP flag and contains the DSCP. The 6 most significant bits are used for the DSCP. This setting has precedence over any IPv4- or IPv6- layer setting.
spp_dscp：このフィールドはSPP_DSCPフラグと一緒に使用してDSCPを含んでいます。 6つの最上位ビットがDSCPのために使用されています。この設定は、任意のIPv4-またはIPv6-層の設定よりも優先されます。
Please note that changing the flow label or DSCP value will affect all packets sent by the SCTP stack after setting these parameters. The flow label might also be set via the sin6_flowinfo field of the sockaddr_in6 structure.
フローラベルまたはDSCP値を変更すると、これらのパラメータを設定した後、SCTPスタックによって送信されるすべてのパケットに影響しますのでご注意ください。フローラベルはまた、sockaddr_in6構造体のsin6_flowinfoフィールドを経由して設定されることがあります。
8.1.13. Set Default Send Parameters (SCTP_DEFAULT_SEND_PARAM) - DEPRECATED
8.1.13. 既定値に設定はパラメータ（SCTP_DEFAULT_SEND_PARAM）を送信 - 非推奨します
Please note that this option is deprecated. SCTP_DEFAULT_SNDINFO (Section 8.1.31) should be used instead.
このオプションは推奨されませんのでご注意ください。 SCTP_DEFAULT_SNDINFO（セクション8.1.31）が代わりに使用する必要があります。
Applications that wish to use the sendto() system call may wish to specify a default set of parameters that would normally be supplied through the inclusion of ancillary data. This socket option allows such an application to set the default sctp_sndrcvinfo structure. The application that wishes to use this socket option simply passes the sctp_sndrcvinfo structure (defined in Section 5.3.2) to this call. The input parameters accepted by this call include sinfo_stream, sinfo_flags, sinfo_ppid, sinfo_context, and sinfo_timetolive. The sinfo_flags field is composed of a bitwise OR of SCTP_UNORDERED, SCTP_EOF, and SCTP_SENDALL. The sinfo_assoc_id field specifies the association to which to apply the parameters. For a one-to-many style socket, any of the predefined constants are also allowed in this field. The field is ignored for one-to-one style sockets.
たいことはsendto（）システムコールを使用するアプリケーションは、通常、補助データを含めることによって供給されることとなるパラメータのデフォルトセットを指定します。このソケットオプションはデフォルトにsctp_sndrcvinfo構造を設定するには、このような適用を可能にします。このソケットオプションを使用したいアプリケーションは、単にこの呼び出しに（セクション5.3.2で定義されている）にsctp_sndrcvinfo構造を通過します。このコールが受け付けた入力パラメータはsinfo_stream、sinfo_flags、sinfo_ppid、sinfo_context、及びsinfo_timetoliveが挙げられます。 sinfo_flagsフィールドは、ビット単位のOR SCTP_UNORDERED、SCTP_EOF、およびSCTP_SENDALLで構成されています。 sinfo_assoc_idフィールドには、パラメータを適用する関連付けを指定します。 1対多スタイルソケットの場合は、事前に定義された定数のいずれも、この分野では許可されています。フィールドは、1対1のスタイルのソケットでは無視されます。
8.1.14. Set Notification and Ancillary Events (SCTP_EVENTS) - DEPRECATED
8.1.14. 設定された通知及び補助イベント（SCTP_EVENTS） - 非推奨
This socket option is used to specify various notifications and ancillary data the user wishes to receive. Please see Section 6.2.1 for a full description of this option and its usage. Note that this option is considered deprecated and is present for backward compatibility. New applications should use the SCTP_EVENT option. See Section 6.2.2 for a full description of that option as well.
このソケットオプションは、さまざまな通知やユーザーが受信したい補助データを指定するために使用されます。このオプションとその使用方法の詳細については、セクション6.2.1を参照してください。このオプションは非推奨とみなされ、後方互換性のために存在していることに注意してください。新しいアプリケーションでは、SCTP_EVENTオプションを使用する必要があります。同様にそのオプションの詳細については、セクション6.2.2を参照してください。
This socket option is a boolean flag that turns on or off the mapping of IPv4 addresses. If this option is turned on, then IPv4 addresses will be mapped to IPv6 representation. If this option is turned off, then no mapping will be done of IPv4 addresses, and a user will receive both PF_INET6 and PF_INET type addresses on the socket. See [RFC3542] for more details on mapped IPv6 addresses.
このソケットオプションは、IPv4アドレスのマッピングをオンまたはオフになりブールフラグです。このオプションがオンになっている場合は、IPv4アドレスは、IPv6の表現にマッピングされます。このオプションがオフになっている場合には、何のマッピングは、IPv4アドレスの検査は行われません、ユーザーはソケットにPF_INET6とPF_INET両方のタイプのアドレスを受信します。マップされたIPv6アドレスの詳細については、[RFC3542]を参照してください。
If this socket option is used on a socket of type PF_INET, an error is returned.
このソケットオプションはタイプPF_INETのソケットで使用されている場合は、エラーが返されます。
By default, this option is turned off and expects an integer to be passed where a non-zero value turns on the option and a zero value turns off the option.
デフォルトでは、このオプションがオフになって、非ゼロ値がオプションをオンにし、ゼロ値がオプションをオフにする場合整数渡されることを期待されています。
This option will get or set the maximum size to put in any outgoing SCTP DATA chunk. If a message is larger than this maximum size, it will be fragmented by SCTP into the specified size. Note that the underlying SCTP implementation may fragment into smaller sized chunks when the PMTU of the underlying association is smaller than the value set by the user. The default value for this option is '0', which indicates that the user is not limiting fragmentation and only the PMTU will affect SCTP's choice of DATA chunk size. Note also that values set larger than the maximum size of an IP datagram will effectively let SCTP control fragmentation (i.e., the same as setting this option to 0).
このオプションは、任意の発信SCTPデータチャンクに入れて最大サイズを取得または設定します。メッセージがこの最大サイズよりも大きい場合には、指定されたサイズにSCTPによって断片化されるであろう。基礎となる関連のPMTUは、ユーザが設定した値より小さい場合、基礎となるSCTP実装がより小さなサイズのチャンクに断片化してもよいことに留意されたいです。このオプションのデフォルト値は、ユーザーがDATAチャンクサイズのSCTPの選択に影響する断片化とだけPMTUを制限されていないことを示し、「0」です。音符値が有効SCTP制御フラグメンテーションをできるようになるIPデータグラム（このオプションを0に設定するよう、すなわち、同じ）の最大サイズよりも大きく設定もあります。
The following structure is used to access and modify this parameter:
次のような構造は、アクセスして、このパラメータを変更するために使用されます。
struct sctp_assoc_value {
sctp_assoc_t assoc_id;
uint32_t assoc_value;
};
assoc_id: This parameter is ignored for one-to-one style sockets. For one-to-many style sockets, this parameter indicates upon which association the user is performing an action. It is an error to use SCTP_{CURRENT|ALL}_ASSOC in assoc_id.
assoc_id：このパラメータは、1対1スタイルソケットでは無視されます。 1対多スタイルソケットの場合、このパラメータは、ユーザーがアクションを実行している際にアソシエーション示します。 assoc_idで_ASSOC | SCTP_ {ALL CURRENT}を使用するとエラーになります。
assoc_value: This parameter specifies the maximum size in bytes.
assoc_value：このパラメータは、最大サイズをバイト単位で指定します。
8.1.17. Get or Set the List of Supported HMAC Identifiers (SCTP_HMAC_IDENT)
8.1.17. サポートされているHMAC識別子（SCTP_HMAC_IDENT）の一覧を取得または設定します
This option gets or sets the list of Hashed Message Authentication Code (HMAC) algorithms that the local endpoint requires the peer to use.
このオプションは、ローカルエンドポイントが使用するピアが必要であることをハッシュメッセージ認証コード（HMAC）アルゴリズムのリストを取得または設定します。
The following structure is used to get or set these identifiers:
以下の構造は、これらの識別子を取得または設定するために使用されます。
struct sctp_hmacalgo {
uint32_t shmac_number_of_idents;
uint16_t shmac_idents[];
};
shmac_number_of_idents: This field gives the number of elements present in the array shmac_idents.
shmac_number_of_idents：このフィールドは、配列shmac_identsに存在する要素の数を示します。
shmac_idents: This parameter contains an array of HMAC identifiers that the local endpoint is requesting the peer to use, in priority order. The following identifiers are valid:
shmac_idents：このパラメータは、ローカルエンドポイントが優先度順に、使用するピアを要求しているHMAC識別子のアレイを含みます。次の識別子が有効です。
* SCTP_AUTH_HMAC_ID_SHA1
* SCTP_AUTH_HMAC_ID_SHA1
* SCTP_AUTH_HMAC_ID_SHA256
* SCTP_AUTH_HMAC_ID_SHA256
Note that the list supplied must include SCTP_AUTH_HMAC_ID_SHA1 and may include any of the other values in its preferred order (lowest list position has the highest preference in algorithm selection).
そしてSCTP_AUTH_HMAC_ID_SHA1を含まなければならない供給リストが好ましいために、他の値（最低のリスト位置は、アルゴリズムの選択において最も高い優先順位を有している）のいずれかを含むことができることに留意されたいです。
Note also that the lack of SCTP_AUTH_HMAC_ID_SHA1, or the inclusion of an unknown HMAC identifier (including optional identifiers unknown to the implementation), will cause the set option to fail and return an error.
SCTP_AUTH_HMAC_ID_SHA1の欠如、または（実装に未知のオプションの識別子を含む）、未知のHMAC識別子を含めることが、失敗し、エラーを返すように設定オプションを引き起こすことにも注意してください。
This option will get or set the active shared key to be used to build the association shared key.
このオプションは、取得したり、関連付けを構築するために使用される活性共有キーを設定し、キーを共有します。
The following structure is used to access and modify these parameters:
以下の構造は、これらのパラメータにアクセスして変更するために使用されます。
struct sctp_authkeyid {
sctp_assoc_t scact_assoc_id;
uint16_t scact_keynumber;
};
scact_assoc_id: This parameter sets the active key of the specified association. The special SCTP_{FUTURE|CURRENT|ALL}_ASSOC can be used. For one-to-one style sockets, this parameter is ignored. Note, however, that this option will set the active key on the association if the socket is connected; otherwise, this option will set the default active key for the endpoint.
scact_assoc_id：このパラメータは、指定された協会のアクティブなキーを設定します。特別SCTP_ {FUTURE | CURRENT | ALL} _ASSOCを使用することができます。 1対1スタイルソケットの場合、このパラメータは無視されます。ソケットが接続されている場合は、このオプションは、協会のアクティブなキーを設定すること、しかし、注意してください。そうでない場合は、このオプションは、エンドポイントのデフォルトのアクティブキーを設定します。
scact_keynumber: This parameter is the shared key identifier that the application is requesting to become the active shared key to be used for sending authenticated chunks. The key identifier must correspond to an existing shared key. Note that shared key identifier '0' defaults to a null key.
scact_keynumber：このパラメータは、アプリケーションが認証されたチャンクを送信するために使用される活性共有鍵になることを要求している共有鍵識別子です。キー識別子は、既存の共有鍵に対応しなければなりません。ヌルキーにキー識別子「0」のデフォルトを共有ノート。
When used with setsockopt(), the SCTP implementation must use the indicated shared key identifier for all messages being given to an SCTP implementation via a send call after the setsockopt() call, until changed again. Therefore, the SCTP implementation must not bundle user messages that should be authenticated using different shared key identifiers.
setsockopt（）とともに使用すると、SCTP実装が再び変更されるまですべてのメッセージは、のsetsockopt（）呼び出し後に送信呼び出しを介して、SCTP実装に与えられるために示されている共有鍵識別子を使用しなければなりません。したがって、SCTPの実装は異なる共有鍵識別子を使用して認証する必要があるユーザーメッセージをバンドルしてはなりません。
Initially, the key with key identifier 0 is the active key.
最初は、キー識別子が0のキーがアクティブなキーです。
This option will affect the way delayed SACKs are performed. This option allows the application to get or set the delayed SACK time, in milliseconds. It also allows changing the delayed SACK frequency. Changing the frequency to 1 disables the delayed SACK algorithm. Note that if sack_delay or sack_freq is 0 when setting this option, the current values will remain unchanged.
このオプションは、遅れ袋が実行される方法に影響します。このオプションは、ミリ秒単位で、アプリケーションが遅延SACK時間を取得または設定することができます。また、遅れSACK周波数を変更することができます。 1に周波数を変更すると、遅れたSACKアルゴリズムを無効にします。このオプションを設定するときsack_delayまたはsack_freqが0であれば、電流値が変わらないことに注意してください。
The following structure is used to access and modify these parameters:
以下の構造は、これらのパラメータにアクセスして変更するために使用されます。
struct sctp_sack_info {
sctp_assoc_t sack_assoc_id;
uint32_t sack_delay;
uint32_t sack_freq;
};
sack_assoc_id: This parameter is ignored for one-to-one style sockets. For one-to-many style sockets, this parameter indicates upon which association the user is performing an action. The special SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used.
sack_assoc_id：このパラメータは、1対1スタイルソケットでは無視されます。 1対多スタイルソケットの場合、このパラメータは、ユーザーがアクションを実行している際にアソシエーション示します。特別SCTP_ {FUTURE | CURRENT | ALL} _ASSOCも使用することができます。
sack_delay: This parameter contains the number of milliseconds the user is requesting that the delayed SACK timer be set to. Note that this value is defined in [RFC4960] to be between 200 and 500 milliseconds.
sack_delay：このパラメータには、ユーザーが遅れSACKタイマーに設定されることを要求されたミリ秒数が含まれています。この値が200と500ミリ秒の間になるように[RFC4960]で定義されていることに留意されたいです。
sack_freq: This parameter contains the number of packets that must be received before a SACK is sent without waiting for the delay timer to expire. The default value is 2; setting this value to 1 will disable the delayed SACK algorithm.
sack_freq：このパラメータは、SACKが満了するの遅延タイマーを待たずに送信される前に受信されなければならないパケット数が含まれています。デフォルト値は2です。この値を1に設定すると、遅れたSACKアルゴリズムを無効にします。
Fragmented interleave controls how the presentation of messages occurs for the message receiver. There are three levels of fragment interleave defined. Two of the levels affect one-to-one style sockets, while one-to-many style sockets are affected by all three levels.
断片化されたインターリーブは、メッセージのプレゼンテーションはメッセージ受信のためにどのように発生するかを制御します。定義されたフラグメントのインターリーブの3つのレベルがあります。 1対多のスタイルのソケットはすべての3つのレベルの影響を受けている間にレベルの二つは、1対1のスタイルのソケットに影響を与えます。
This option takes an integer value. It can be set to a value of 0, 1, or 2. Attempting to set this level to other values will return an error.
このオプションは、整数値をとります。これは、0,1、または2でエラーが返される他の値にこのレベルを設定しようとする値に設定することができます。
Setting the three levels provides the following receiver interactions:
三つのレベルを設定すると、次の受信機の相互作用を提供します。
level 0: Prevents the interleaving of any messages. This means that when a partial delivery begins, no other messages will be received except the message being partially delivered. If another message arrives on a different stream (or association) that could be delivered, it will be blocked waiting for the user to read all of the partially delivered message.
レベル0：すべてのメッセージのインタリーブを禁止します。これは、部分的な配信が開始したときに、メッセージの一部が配信さを除いて、他のメッセージが受信されないことを意味します。別のメッセージを配信することができ、異なるストリーム（または関連付け）に到達した場合、ユーザは、部分的に配信されるメッセージのすべてを読むのを待ってブロックされます。
level 1: Allows interleaving of messages that are from different associations. For one-to-one style sockets, level 0 and level 1 thus have the same meaning, since a one-to-one style socket always receives messages from the same association. Note that setting a one-to-many style socket to this level may cause multiple partial deliveries from different associations, but for any given association, only one message will be delivered until all parts of a message have been delivered. This means that one large message, being read with an association identifier of "X", will block other messages from association "X" from being delivered.
レベル1：別の団体からあるメッセージのインターリーブを可能にします。 1対1のスタイルのソケットは常に同じ協会からメッセージを受信するので、1対1スタイルソケット、レベル0とレベル1の場合はこのように、同じ意味を持ちます。この設定レベルへの1対多のスタイルのソケットが異なる団体からの複数の部分納入を引き起こす可能性がありますが、メッセージのすべての部分が配信されるまで、任意団体のために、1つのメッセージのみが配信されることに注意してください。これは、「X」の関連識別子と読み出されて一つの大きなメッセージが、配信され協会「X」からの他のメッセージをブロックすることを意味します。
level 2: Allows complete interleaving of messages. This level requires that the sender not only carefully observe the peer association identifier (or address) but also pay careful attention to the stream number. With this option enabled, a partially delivered message may begin being delivered for association "X" stream "Y", and the next subsequent receive may return a message from association "X" stream "Z". Note that no other messages would be delivered for association "X" stream "Y" until all of stream "Y"'s partially delivered message was read. Note that this option also affects one-to-one style sockets. Also note that for one-to-many style sockets, not only another stream's message from the same association may be delivered upon the next receive, but some other association's message may also be delivered upon the next receive.
レベル2：メッセージの完全なインターリーブを可能にします。このレベルでは、送信者が慎重にピアアソシエーション識別子（またはアドレス）を観察するだけでなく、ストリーム番号に細心の注意を払っていないことだけです。有効このオプションで、部分的に配信されたメッセージは、関連付け「X」ストリーム「Y」のために配信され始めてもよいし、次以降の受信アソシエーション「X」ストリーム「Z」からメッセージを返すことができます。他のメッセージは、ストリームのすべての「Y」の部分的に配信されたメッセージが読まれるまで協会「X」ストリーム「Y」のために配信されないであろうことに注意してください。このオプションはまた、1対1のスタイルのソケットに影響することに注意してください。また、1対多のスタイルのソケットのためだけではなく、同じ団体から別のストリームのメッセージは次の受信時に送達することができるが、いくつかの他の協会のメッセージはまた、次の受信時に送出されてもよいことに注意してください。
An implementation should default one-to-many style sockets to level 1, because otherwise, it is possible that a peer could begin sending a partial message and thus block all other peers from sending data. However, a setting of level 2 requires that the application not only be aware of the association (via the association identifier or peer's address) but also the stream number. The stream number is not present unless the user has subscribed to the sctp_data_io_event (see Section 6.2), which is deprecated, or has enabled the SCTP_RECVRCVINFO socket option (see Section 8.1.29). This is also why we recommend that one-to-one style sockets be defaulted to level 0 (level 1 for one-to-one style sockets has no effect). Note that an implementation should return an error if an application attempts to set the level to 2 and has not subscribed to the sctp_data_io_event event, which is deprecated, or has enabled the SCTP_RECVRCVINFO socket option.
そうでなければ、ピアが部分的メッセージの送信を開始し、従ってデータを送信し、他のすべてのピアをブロックすることが可能であるため、実装は、レベル1に一対多スタイルソケットをデフォルトすべきです。しかし、レベル2の設定は、アプリケーションだけでなく（アソシエーション識別子またはピアのアドレスを介して）関連だけでなく、ストリーム番号を認識することを必要とします。ユーザが廃止され、又はSCTP_RECVRCVINFOソケットオプション（セクション8.1.29を参照）を有効にしているsctp_data_io_event（セクション6.2を参照）に加入していない限り、ストリーム番号は存在しません。我々は1対1スタイルソケットはレベル0（1対1スタイルソケットのためのレベル1は効果がありません）にデフォルト設定することをお勧め理由でもあります。アプリケーションは、2レベルを設定しようと廃止され、又はSCTP_RECVRCVINFOソケットオプションを有効にしているsctp_data_io_eventイベントにサブスクライブしていない場合、実装は、エラーを返すべきであることに留意されたいです。
For applications that have subscribed to events, those events appear in the normal socket buffer data stream. This means that unless the user has set the fragmentation interleave level to 0, notifications may also be interleaved with partially delivered messages.
イベントにサブスクライブしているアプリケーションでは、これらのイベントは、通常のソケットバッファのデータ・ストリームに表示されます。これにより、ユーザは0にフラグメンテーションインターリーブレベルを設定していない限り、通知はまた、部分的に配信されたメッセージとインタリーブされてもよいことを意味します。
8.1.21. Set or Get the SCTP Partial Delivery Point (SCTP_PARTIAL_DELIVERY_POINT)
8.1.21. 設定またはSCTP部分的な配信ポイントを取得します（SCTP_PARTIAL_DELIVERY_POINT）
This option will set or get the SCTP partial delivery point. This point is the size of a message where the partial delivery API will be invoked to help free up rwnd space for the peer. Setting this to a lower value will cause partial deliveries to happen more often. This option expects an integer that sets or gets the partial delivery point in bytes. Note also that the call will fail if the user attempts to set this value larger than the socket receive buffer size.
このオプションは、SCTP部分配信ポイントを設定または取得します。この点は、部分配信APIは、ピアのRWND領域を解放を助けるために呼び出されるメッセージのサイズです。低い値に設定すると、一部の納入がより頻繁に起こるようになります。このオプションは、バイト単位の部分配信ポイントを設定または取得する整数を期待します。ユーザはソケットよりも大きい。この値は、バッファサイズを受信設定しようとした場合、コールは失敗することにも留意されたいです。
Note that any single message having a length smaller than or equal to the SCTP partial delivery point will be delivered in a single read call as long as the user-provided buffer is large enough to hold the message.
任意の単一のメッセージがあれば、ユーザ提供バッファはメッセージを保持するのに十分な大きさであるように、単一の読み出しコールで配信されるSCTP部分配信ポイントまでの長さより小さいか等しい有することに留意されたいです。
8.1.22. Set or Get the Use of Extended Receive Info (SCTP_USE_EXT_RCVINFO) - DEPRECATED
8.1.22. 非推奨 - 拡張情報（SCTP_USE_EXT_RCVINFO）を受け取るの使用を設定または取得
This option will enable or disable the use of the extended version of the sctp_sndrcvinfo structure. If this option is disabled, then the normal sctp_sndrcvinfo structure is returned in all receive message calls. If this option is enabled, then the sctp_extrcvinfo structure is returned in all receive message calls. The default is off.
このオプションは、にsctp_sndrcvinfo構造の拡張版の使用を有効または無効にします。このオプションを無効にする場合は、通常にsctp_sndrcvinfo構造は、すべてに戻されるメッセージ・コールを受信。このオプションを有効にすると、sctp_extrcvinfo構造はすべてで返されたメッセージは、呼び出しを受けます。デフォルトはオフです。
Note that the sctp_extrcvinfo structure is never used in any send call.
sctp_extrcvinfo構造は、任意の送信呼び出しに使用されていないことに注意してください。
This option is present for compatibility with older applications and is deprecated. Future applications should use SCTP_NXTINFO to retrieve this same information via ancillary data.
このオプションは、古いアプリケーションとの互換性のために存在し、推奨されていません。将来のアプリケーションは、補助的なデータを介して、これと同じ情報を取得するためにSCTP_NXTINFOを使用する必要があります。
This option will enable or disable the use of the automatic generation of ASCONF chunks to add and delete addresses to an existing association. Note that this option has two caveats, namely a) it only affects sockets that are bound to all addresses available to the SCTP stack, and b) the system administrator may have an overriding control that turns the ASCONF feature off no matter what setting the socket option may have.
このオプションでは、既存の関連付けにアドレスを追加および削除するASCONFチャンクの自動生成の使用を有効または無効にします。すなわち、a）は、それが唯一のSCTPスタックが利用可能なすべてのアドレスにバインドされているソケットに影響を与え、そしてb）システム管理者がどのようなソケット設定に関係なく、ASCONF機能をオフにオーバーライド制御を有していなくてもよい、このオプションは2つの注意点があることに注意してくださいオプションは持っていることがあります。
This option expects an integer boolean flag, where a non-zero value turns on the option, and a zero value turns off the option.
このオプションは、非ゼロ値がオプションをオン整数ブール・フラグを、期待、およびゼロ値がオプションをオフにします。
This option will allow a user to change the maximum burst of packets that can be emitted by this association. Note that the default value is 4, and some implementations may restrict this setting so that it can only be lowered to positive values.
このオプションでは、ユーザは、この会合によって放出することができるパケットの最大バーストを変更することを可能にします。デフォルト値は4であることに注意し、それが唯一の正の値まで低下させることができるように、いくつかの実装では、この設定を制限することができます。
To set or get this option, the user fills in the following structure:
このオプションを設定または取得するには、ユーザーは次の構造を記入します：
struct sctp_assoc_value {
sctp_assoc_t assoc_id;
uint32_t assoc_value;
};
assoc_id: This parameter is ignored for one-to-one style sockets. For one-to-many style sockets, this parameter indicates upon which association the user is performing an action. The special SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used.
assoc_id：このパラメータは、1対1スタイルソケットでは無視されます。 1対多スタイルソケットの場合、このパラメータは、ユーザーがアクションを実行している際にアソシエーション示します。特別SCTP_ {FUTURE | CURRENT | ALL} _ASSOCも使用することができます。
assoc_value: This parameter contains the maximum burst. Setting the value to 0 disables burst mitigation.
assoc_value：このパラメータは、最大バーストが含まれています。値を0に設定すると、バースト緩和を無効にします。
The context field in the sctp_sndrcvinfo structure is normally only used when a failed message is retrieved holding the value that was sent down on the actual send call. This option allows the setting, on an association basis, of a default context that will be received on reading messages from the peer. This is especially helpful for an application when using one-to-many style sockets to keep some reference to an internal state machine that is processing messages on the association. Note that the setting of this value only affects received messages from the peer and does not affect the value that is saved with outbound messages.
失敗したメッセージは、実際の送信コールで下された値を保持して取得されたときにsctp_sndrcvinfo構造のコンテキストフィールドは、通常のみ使用されます。このオプションは、ピアからのメッセージを読んだ上で受信されるデフォルトのコンテキストで、関連ごとに、設定することができます。これは、協会にメッセージを処理している内部ステートマシンにいくつかの参照を保持するために1対多のスタイルのソケットを使用するアプリケーションのために特に有用です。この値の設定は唯一のピアから受信したメッセージに影響を与え、送信メッセージと一緒に保存されている値には影響しないことに注意してください。
To set or get this option, the user fills in the following structure:
このオプションを設定または取得するには、ユーザーは次の構造を記入します：
struct sctp_assoc_value {
sctp_assoc_t assoc_id;
uint32_t assoc_value;
};
assoc_id: This parameter is ignored for one-to-one style sockets. For one-to-many style sockets, this parameter indicates upon which association the user is performing an action. The special SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used.
assoc_id：このパラメータは、1対1スタイルソケットでは無視されます。 1対多スタイルソケットの場合、このパラメータは、ユーザーがアクションを実行している際にアソシエーション示します。特別SCTP_ {FUTURE | CURRENT | ALL} _ASSOCも使用することができます。
assoc_value: This parameter contains the context.
assoc_value：このパラメータは、コンテキストが含まれています。
This boolean flag is used to enable or disable explicit end of record (EOR) marking. When this option is enabled, a user may make multiple send system calls to send a record and must indicate that they are finished sending a particular record by including the SCTP_EOR flag. If this boolean flag is disabled, then each individual send system call is considered to have an SCTP_EOR indicator set on it implicitly without the user having to explicitly add this flag. The default is off.
このブールフラグは、レコードの明示的な端（EOR）マーキングを有効または無効にするために使用されます。このオプションを有効にすると、ユーザーは複数の送信システムがレコードを送信するために呼び出し、彼らはSCTP_EORフラグを含めることによって、特定のレコードの送信を完了していることを示さなければならないことがあります。このブールフラグが無効になっている場合には、個々の送信システムコールは、明示的にこのフラグを追加したユーザーせずに暗黙的に設定されたSCTP_EORインジケータを有すると考えられます。デフォルトはオフです。
This option expects an integer boolean flag, where a non-zero value turns on the option, and a zero value turns off the option.
このオプションは、非ゼロ値がオプションをオン整数ブール・フラグを、期待、およびゼロ値がオプションをオフにします。
This option only supports one-to-one style SCTP sockets. If used on a one-to-many style SCTP socket, an error is indicated.
このオプションは、1対1スタイルのSCTPソケットをサポートしています。一対多スタイルのSCTPソケットで使用した場合、エラーが表示されます。
This option expects an integer boolean flag, where a non-zero value turns on the option, and a zero value turns off the option.
このオプションは、非ゼロ値がオプションをオン整数ブール・フラグを、期待、およびゼロ値がオプションをオフにします。
This socket option must not be used after calling bind() or sctp_bindx() for a one-to-one style SCTP socket. If using bind() or sctp_bindx() on a socket with the SCTP_REUSE_PORT option, all other SCTP sockets bound to the same port must have set the SCTP_REUSE_PORT option. Calling bind() or sctp_bindx() for a socket without having set the SCTP_REUSE_PORT option will fail if there are other sockets bound to the same port. At most one socket being bound to the same port may be listening.
このソケットオプションは、1対1スタイルのSCTPソケットのバインド（）またはと、sctp_bindx（）を呼び出した後使用することはできません。 SCTP_REUSE_PORTオプション付きソケットにバインド（）またはと、sctp_bindx（）を使用している場合は、同じポートにバインドされた他のすべてのSCTPソケットはSCTP_REUSE_PORTオプションを設定しておく必要があります。同じポートにバインドされた他のソケットがある場合SCTP_REUSE_PORTオプションを設定せずにバインド（）またはソケットのためと、sctp_bindx（）を呼び出すと失敗します。せいぜい同じポートにバインドされた1つのソケットがリスニングすることができます。
It should be noted that the behavior of the socket-level socket option to reuse ports and/or addresses for SCTP sockets is unspecified.
SCTPソケット用のポートおよび/またはアドレスを再利用するソケットレベルのソケットオプションの動作が指定されていないことに留意すべきです。
This socket option is used to set a specific notification option. Please see Section 6.2.2 for a full description of this option and its usage.
このソケットオプションは、特定の通知オプションを設定するために使用されます。このオプションとその使用方法の詳細については、セクション6.2.2を参照してください。
8.1.29. Enable or Disable the Delivery of SCTP_RCVINFO as Ancillary Data (SCTP_RECVRCVINFO)
8.1.29. 補助データ（SCTP_RECVRCVINFO）としてSCTP_RCVINFOの配信を有効または無効にします
Setting this option specifies that SCTP_RCVINFO (defined in Section 5.3.5) is returned as ancillary data by recvmsg().
SCTP_RCVINFOは（セクション5.3.5で定義されている）のrecvmsgによって補助データとして返されることは、このオプションを指定する設定（）。
This option expects an integer boolean flag, where a non-zero value turns on the option, and a zero value turns off the option.
このオプションは、非ゼロ値がオプションをオン整数ブール・フラグを、期待、およびゼロ値がオプションをオフにします。
8.1.30. Enable or Disable the Delivery of SCTP_NXTINFO as Ancillary Data (SCTP_RECVNXTINFO)
8.1.30. 補助データ（SCTP_RECVNXTINFO）としてSCTP_NXTINFOの配信を有効または無効にします
Setting this option specifies that SCTP_NXTINFO (defined in Section 5.3.6) is returned as ancillary data by recvmsg().
SCTP_NXTINFOは、（5.3.6項で定義される）のrecvmsgによって補助データとして返されることは、このオプションを指定する設定（）。
This option expects an integer boolean flag, where a non-zero value turns on the option, and a zero value turns off the option.
このオプションは、非ゼロ値がオプションをオン整数ブール・フラグを、期待、およびゼロ値がオプションをオフにします。
Applications that wish to use the sendto() system call may wish to specify a default set of parameters that would normally be supplied through the inclusion of ancillary data. This socket option allows such an application to set the default sctp_sndinfo structure. The application that wishes to use this socket option simply passes the sctp_sndinfo structure (defined in Section 5.3.4) to this call. The input parameters accepted by this call include snd_sid, snd_flags, snd_ppid, and snd_context. The snd_flags parameter is composed of a bitwise OR of SCTP_UNORDERED, SCTP_EOF, and SCTP_SENDALL. The snd_assoc_id field specifies the association to which to apply the parameters. For a one-to-many style socket, any of the predefined constants are also allowed in this field. The field is ignored for one-to-one style sockets.
たいことはsendto（）システムコールを使用するアプリケーションは、通常、補助データを含めることによって供給されることとなるパラメータのデフォルトセットを指定します。このソケットオプションは、デフォルトのsctp_sndinfo構造を設定するには、このような適用を可能にします。このソケットオプションを使用したいアプリケーションは、単にこの呼び出しにsctp_sndinfo構造（セクション5.3.4で定義されている）を通過させます。このコールが受け付けた入力パラメータはsnd_sid、snd_flags、snd_ppid、及びsnd_contextが挙げられます。 snd_flagsパラメータは、ビット単位のOR SCTP_UNORDERED、SCTP_EOF、およびSCTP_SENDALLで構成されています。 snd_assoc_idフィールドには、パラメータを適用する関連付けを指定します。 1対多スタイルソケットの場合は、事前に定義された定数のいずれも、この分野では許可されています。フィールドは、1対1のスタイルのソケットでは無視されます。
This option sets and gets the default parameters for PR-SCTP. They can be overwritten by specific information provided in send calls.
このオプションセットとPR-SCTPのためのデフォルトパラメータを取得します。彼らは、送信呼び出しで提供された特定の情報で上書きすることができます。
The following structure is used to access and modify these parameters:
以下の構造は、これらのパラメータにアクセスして変更するために使用されます。
struct sctp_default_prinfo {
uint16_t pr_policy;
uint32_t pr_value;
sctp_assoc_t pr_assoc_id;
};
pr_policy: This field is the same as that described in Section 5.3.7.
pr_policy：このフィールドは、5.3.7項で述べたものと同じです。
pr_value: This field is the same as that described in Section 5.3.7.
pr_value：このフィールドは、5.3.7項で述べたものと同じです。
pr_assoc_id: This field is ignored for one-to-one style sockets. For one-to-many style sockets, pr_assoc_id can be a particular association identifier or SCTP_{FUTURE|CURRENT|ALL}_ASSOC.
pr_assoc_id：このフィールドは、1対1スタイルソケットでは無視されます。 {| CURRENT |将来のすべて} _ASSOC 1対多スタイルソケットの場合、pr_assoc_idは、特定のアソシエーション識別子またはSCTP_ことができます。
The options defined in this subsection are read-only. Using this option in a setsockopt() call will result in an error indicating EOPNOTSUPP.
このサブセクションで定義されたオプションは読み取り専用です。 setsockopt（）の呼び出しでは、このオプションを使用するとEOPNOTSUPPを示すエラーになります。
Applications can retrieve current status information about an association, including association state, peer receiver window size, number of unacknowledged DATA chunks, and number of DATA chunks pending receipt. This information is read-only.
アプリケーションは、会合状態、ピアの受信ウィンドウサイズ、未確認DATAチャンクの数、及び受信保留データチャンクの数を含むアソシエーションに関する現在のステータス情報を取得することができます。この情報は読み取り専用です。
The following structure is used to access this information:
以下の構造は、この情報にアクセスするために使用されます。
struct sctp_status {
sctp_assoc_t sstat_assoc_id;
int32_t sstat_state;
uint32_t sstat_rwnd;
uint16_t sstat_unackdata;
uint16_t sstat_penddata;
uint16_t sstat_instrms;
uint16_t sstat_outstrms;
uint32_t sstat_fragmentation_point;
struct sctp_paddrinfo sstat_primary;
};
sstat_assoc_id: This parameter is ignored for one-to-one style sockets. For one-to-many style sockets, it holds the identifier for the association. All notifications for a given association have the same association identifier. The special SCTP_{FUTURE| CURRENT|ALL}_ASSOC cannot be used.
sstat_assoc_id：このパラメータは、1対1スタイルソケットでは無視されます。 1対多のスタイルのソケットの場合、それは協会の識別子を保持しています。与えられたアソシエーションのすべての通知は、同じアソシエーションIDを持っています。特別SCTP_ {FUTURE | CURRENT | ALL} _ASSOCを使用することはできません。
sstat_state: This contains the association's current state, i.e., one of the following values:
sstat_state：これは、すなわち関連の現在の状態は、次のいずれかの値が含まれています。
* SCTP_CLOSED
* SCTP_CLOSED
* SCTP_BOUND
* SCTP_BOUND
* SCTP_LISTEN
* SCTP_LISTEN
* SCTP_COOKIE_WAIT
* SCTP_COOKIE_WAIT
* SCTP_COOKIE_ECHOED
* SCTP_COOKIE_ECHOED
* SCTP_ESTABLISHED
* SCTPを設立します
* SCTP_SHUTDOWN_PENDING
* SCTP_SHUTDOWN_PENDING
* SCTP_SHUTDOWN_SENT
* SCTP_SHUTDOWN_SENT
* SCTP_SHUTDOWN_RECEIVED
* SCTP_SHUTDOWN_RECEIVED
* SCTP_SHUTDOWN_ACK_SENT
* SCTP_SHUTDOWN_ACK_SENT
sstat_rwnd: This contains the association peer's current receiver window size.
sstat_rwnd：これは、関連付けピアの現在の受信ウィンドウサイズが含まれています。
sstat_unackdata: This is the number of unacknowledged DATA chunks.
sstat_unackdata：これは未確認のDATAチャンクの数です。
sstat_penddata: This is the number of DATA chunks pending receipt.
sstat_penddata：これは、領収書を保留中のDATAチャンクの数です。
sstat_instrms: This is the number of streams that the peer will be using outbound.
sstat_instrms：これは、ピアがアウトバウンドを使用することをストリームの数です。
sstat_outstrms: This is the number of outbound streams that the endpoint is allowed to use.
sstat_outstrms：これは、エンドポイントが使用を許可されていることを発信ストリームの数です。
sstat_fragmentation_point: This is the size at which SCTP fragmentation will occur.
sstat_fragmentation_point：これは、SCTPの断片化が発生するときのサイズです。
sstat_primary: This is information on the current primary peer address.
sstat_primary：これは、現在のプライマリピアのアドレスに関する情報です。
To access these status values, the application calls getsockopt() with the option name SCTP_STATUS.
これらのステータス値にアクセスするには、アプリケーションは、オプション名SCTP_STATUSとのgetsockopt（）を呼び出します。
Applications can retrieve information about a specific peer address of an association, including its reachability state, congestion window, and retransmission timer values. This information is read-only.
アプリケーションは、その到達可能性状態、輻輳ウィンドウ、および再送タイマ値を含む、関連の特定のピアアドレスに関する情報を取得することができます。この情報は読み取り専用です。
The following structure is used to access this information:
以下の構造は、この情報にアクセスするために使用されます。
struct sctp_paddrinfo {
sctp_assoc_t spinfo_assoc_id;
struct sockaddr_storage spinfo_address;
int32_t spinfo_state;
uint32_t spinfo_cwnd;
uint32_t spinfo_srtt;
uint32_t spinfo_rto;
uint32_t spinfo_mtu;
};
spinfo_assoc_id: This parameter is ignored for one-to-one style sockets.
spinfo_assoc_id：このパラメータは、1対1スタイルソケットでは無視されます。
For one-to-many style sockets, this field may be filled by the application, and if so, this field will have priority in looking up the association instead of using the address specified in spinfo_address. Note that if the address does not belong to the association specified, then this call will fail. If the application does not fill in the spinfo_assoc_id, then the address will be used to look up the association, and on return, this field will have the valid association identifier. In other words, this call can be used to translate an address into an association identifier. Note that the predefined constants are not allowed for this option.
1対多のスタイルのソケットの場合、このフィールドは、アプリケーションによって充填することができる、そうであれば、このフィールドは関連を調べる代わりにspinfo_addressで指定されたアドレスを使用して優先順位を持つことになります。アドレスが指定された協会に属していない場合は、この呼び出しが失敗することに注意してください。アプリケーションがspinfo_assoc_idに記入していない場合、アドレスは関連を調べるために使用され、戻り時に、このフィールドには、有効なアソシエーション識別子を持つことになります。言い換えれば、この呼び出しは、アソシエーション識別子にアドレスを変換するために使用することができます。事前に定義された定数は、このオプションのために許可されていないことに注意してください。
spinfo_address: This is filled by the application and contains the peer address of interest.
spinfo_address：これは、アプリケーションによって満たされ、関心のピアアドレスが含まれています。
spinfo_state: This contains the peer address's state:
spinfo_state：これは、ピアアドレスの状態が含まれています。
SCTP_UNCONFIRMED: This is the initial state of a peer address.
SCTP_UNCONFIRMED：これは、ピアアドレスの初期状態です。
SCTP_ACTIVE: This state is entered the first time after path verification. It can also be entered if the state is SCTP_INACTIVE and the path supervision detects that the peer address is reachable again.
SCTP_ACTIVE：この状態はパス検証の後の最初の時間を入力します。状態がSCTP_INACTIVEあり、パス監視ピアアドレスが再び到達可能であることを検出した場合にも入力することができます。
SCTP_INACTIVE: This state is entered whenever a path failure is detected.
SCTP_INACTIVE：パス障害が検出されるたびに、この状態が入力されます。
spinfo_cwnd: This contains the peer address's current congestion window.
spinfo_cwnd：これは、ピアアドレスの現在の輻輳ウィンドウが含まれています。
spinfo_srtt: This contains the peer address's current smoothed round-trip time calculation in milliseconds.
spinfo_srtt：これは、ミリ秒単位のピアアドレスの現在の平滑化往復時間の計算が含まれています。
spinfo_rto: This contains the peer address's current retransmission timeout value in milliseconds.
spinfo_rto：これは、ミリ秒単位でピアアドレスの現在の再送タイムアウト値が含まれています。
spinfo_mtu: This is the current Path MTU of the peer address. It is the number of bytes available in an SCTP packet for chunks.
spinfo_mtu：これは、ピアアドレスの現在のパスMTUです。これは、チャンクのためのSCTPパケットで利用可能なバイト数です。
8.2.3. Get the List of Chunks the Peer Requires to Be Authenticated (SCTP_PEER_AUTH_CHUNKS)
8.2.3. 取得ピアを認証する必要がチャンクのリスト（SCTP_PEER_AUTH_CHUNKS）
This option gets a list of chunk types (see [RFC4960]) for a specified association that the peer requires to be received authenticated only.
このオプションは、ピアが認証のみ受信されることが必要と指定された関連付けのチャンクタイプ（参照[RFC4960]）のリストを取得します。
The following structure is used to access these parameters:
以下の構造は、これらのパラメータにアクセスするために使用されます。
struct sctp_authchunks {
sctp_assoc_t gauth_assoc_id;
uint32_t gauth_number_of_chunks
uint8_t gauth_chunks[];
};
gauth_assoc_id: This parameter indicates for which association the user is requesting the list of peer-authenticated chunks. For one-to-one style sockets, this parameter is ignored. Note that the predefined constants are not allowed with this option.
gauth_assoc_id：このパラメータには、ユーザーがピア認証チャンクのリストを要求しているアソシエーションのために示しています。 1対1スタイルソケットの場合、このパラメータは無視されます。定義済み定数がこのオプションで許可されていないことに注意してください。
gauth_number_of_chunks: This parameter gives the number of elements in the array gauth_chunks.
gauth_number_of_chunks：このパラメータは、配列gauth_chunks内の要素の数を示します。
gauth_chunks: This parameter contains an array of chunk types that the peer is requesting to be authenticated. If the passed-in buffer size is not large enough to hold the list of chunk types, ENOBUFS is returned.
gauth_chunks：このパラメータは、ピアが認証されることを要求されたチャンク・タイプの配列を含んでいます。渡されたバッファサイズがチャンクタイプのリストを保持するのに十分でない場合には、ENOBUFSが返されます。
8.2.4. Get the List of Chunks the Local Endpoint Requires to Be Authenticated (SCTP_LOCAL_AUTH_CHUNKS)
8.2.4. 取得ローカルエンドポイントを認証する必要がチャンクのリスト（SCTP_LOCAL_AUTH_CHUNKS）
This option gets a list of chunk types (see [RFC4960]) for a specified association that the local endpoint requires to be received authenticated only.
このオプションは、ローカルエンドポイントのみが認証された受信することが必要と指定された関連付け（[RFC4960]を参照）のチャンクタイプのリストを取得します。
The following structure is used to access these parameters:
以下の構造は、これらのパラメータにアクセスするために使用されます。
struct sctp_authchunks {
sctp_assoc_t gauth_assoc_id;
uint32_t gauth_number_of_chunks;
uint8_t gauth_chunks[];
};
gauth_assoc_id: This parameter is ignored for one-to-one style sockets. For one-to-many style sockets, the application may fill in an association identifier or SCTP_FUTURE_ASSOC. It is an error to use SCTP_{CURRENT|ALL}_ASSOC in gauth_assoc_id.
gauth_assoc_id：このパラメータは、1対1スタイルソケットでは無視されます。 1対多スタイルソケットの場合、アプリケーションは、関連識別子またはSCTP_FUTURE_ASSOCに充填することができます。 gauth_assoc_idで_ASSOC | SCTP_ {ALL CURRENT}を使用するとエラーになります。
gauth_number_of_chunks: This parameter gives the number of elements in the array gauth_chunks.
gauth_number_of_chunks：このパラメータは、配列gauth_chunks内の要素の数を示します。
gauth_chunks: This parameter contains an array of chunk types that the local endpoint is requesting to be authenticated. If the passed-in buffer is not large enough to hold the list of chunk types, ENOBUFS is returned.
gauth_chunks：このパラメータは、ローカルエンドポイントが認証されるように要求しているチャンクタイプの配列が含まれています。渡されたバッファがチャンクタイプのリストを保持するのに十分でない場合には、ENOBUFSが返されます。
This option gets the current number of associations that are attached to a one-to-many style socket. The option value is an uint32_t. Note that this number is only a snapshot. This means that the number of associations may have changed when the caller gets back the option result.
このオプションでは、1対多のスタイルのソケットに接続されている団体の現在の数を取得します。オプション値はのuint32_tです。この数はスナップショットのみであることに注意してください。これは、発信者がオプション結果を取り戻すとき、関連付けの数が変わっている可能性があることを意味します。
For a one-to-one style socket, this socket option results in an error.
1対1のスタイルのソケットの場合は、このソケットオプションは、エラーになります。
8.2.6. Get the Current Identifiers of Associations (SCTP_GET_ASSOC_ID_LIST)
8.2.6. 協会の現在の識別子を取得します（SCTP_GET_ASSOC_ID_LIST）
This option gets the current list of SCTP association identifiers of the SCTP associations handled by a one-to-many style socket.
このオプションでは、1対多のスタイルのソケットで扱うSCTPアソシエーションのSCTPアソシエーション識別子の現在のリストを取得します。
The option value has the structure
オプションの値は、構造を有しています
struct sctp_assoc_ids {
uint32_t gaids_number_of_ids;
sctp_assoc_t gaids_assoc_id[];
};
The caller must provide a large enough buffer to hold all association identifiers. If the buffer is too small, an error must be returned. The user can use the SCTP_GET_ASSOC_NUMBER socket option to get an idea of how large the buffer has to be. gaids_number_of_ids gives the number of elements in the array gaids_assoc_id. Note also that some or all of sctp_assoc_t returned in the array may become invalid by the time the caller gets back the result.
呼び出し側は、すべての関連識別子を保持するのに十分な大きさのバッファを提供しなければなりません。バッファが小さすぎる場合は、エラーが返されなければなりません。ユーザーは、バッファがなければならないか、大のアイデアを得るためにSCTP_GET_ASSOC_NUMBERソケットオプションを使用することができます。 gaids_number_of_idsは、配列gaids_assoc_id内の要素の数を与えます。注また、配列で返さsctp_assoc_tの一部または全部が、呼び出し元が結果を取り戻す時間で無効になることがあります。
For a one-to-one style socket, this socket option results in an error.
1対1のスタイルのソケットの場合は、このソケットオプションは、エラーになります。
The options defined in this subsection are write-only. Using this option in a getsockopt() or sctp_opt_info() call will result in an error indicating EOPNOTSUPP.
このサブセクションで定義されたオプションは書き込み専用です。 getsockopt（）またはと、sctp_opt_info（）呼び出しでは、このオプションを使用するとEOPNOTSUPPを示すエラーをもたらすであろう。
This call requests that the peer mark the enclosed address as the association primary (see [RFC5061]). The enclosed address must be one of the association's locally bound addresses.
ピアが会合プライマリとして封入されたアドレスをマークし、この呼要求（[RFC5061]を参照）。囲まれたアドレスには、協会のローカルにバインドアドレスのいずれかでなければなりません。
The following structure is used to make a set peer primary request:
以下の構造は、主の要求をピアのセットを作るために使用されます。
struct sctp_setpeerprim {
sctp_assoc_t sspp_assoc_id;
struct sockaddr_storage sspp_addr;
};
sspp_assoc_id: This parameter is ignored for one-to-one style sockets. For one-to-many style sockets, it identifies the association for this request. Note that the predefined constants are not allowed for this option.
sspp_assoc_id：このパラメータは、1対1スタイルソケットでは無視されます。 1対多のスタイルのソケットの場合、それはこの要求の関連付けを識別します。事前に定義された定数は、このオプションのために許可されていないことに注意してください。
sspp_addr: The address to set as primary.
sspp_addr：アドレスはプライマリとして設定します。
This set option adds a chunk type that the user is requesting to be received only in an authenticated way. Changes to the list of chunks will only affect future associations on the socket.
このセットオプションは、ユーザーが認証された方法でのみ受信するように要求しているチャンクタイプを追加します。チャンクのリストへの変更は、ソケット上で、将来の団体に影響を与えます。
The following structure is used to add a chunk:
次のような構造は、チャンクを追加するために使用されます。
struct sctp_authchunk {
uint8_t sauth_chunk;
};
sauth_chunk: This parameter contains a chunk type that the user is requesting to be authenticated.
sauth_chunk：このパラメータには、ユーザーが認証されるように要求しているチャンクタイプが含まれています。
The chunk types for INIT, INIT-ACK, SHUTDOWN-COMPLETE, and AUTH chunks must not be used. If they are used, an error must be returned. The usage of this option enables SCTP AUTH in cases where it is not required by other means (for example, the use of dynamic address reconfiguration).
INIT、INIT-ACK、SHUTDOWN-COMPLETE、およびAUTHチャンクのためのチャンクタイプを使用することはできません。それらが使用されている場合は、エラーが返されなければなりません。このオプションの使用は、それが他の手段（例えば、動的アドレス再構成を使用する）によって必要とされない場合にはSCTPのAUTHを可能にします。
This option will set a shared secret key that is used to build an association shared key.
このオプションは、キーを共有の関連付けを構築するために使用される共有秘密鍵を設定します。
The following structure is used to access and modify these
parameters: struct sctp_authkey {
sctp_assoc_t sca_assoc_id;
uint16_t sca_keynumber;
uint16_t sca_keylength;
uint8_t sca_key[];
};
sca_assoc_id: This parameter indicates on what association the shared key is being set. The special SCTP_{FUTURE|CURRENT| ALL}_ASSOC can be used. For one-to-one style sockets, this parameter is ignored. Note, however, that on one-to-one style sockets, this option will set a key on the association if the socket is connected; otherwise, this option will set a key on the endpoint.
sca_assoc_id：このパラメータは、共有キーが設定されている内容の関連に示します。特別SCTP_ {FUTURE | CURRENT | ALL} _ASSOCを使用することができます。 1対1スタイルソケットの場合、このパラメータは無視されます。ソケットが接続されている場合、1対1スタイルソケットで、このオプションは協会にキーを設定すること、しかし、注意してください。そうでない場合は、このオプションは、エンドポイント上のキーを設定します。
sca_keynumber: This parameter is the shared key identifier by which the application will refer to this shared key. If a key of the specified index already exists, then this new key will replace the old existing key. Note that shared key identifier '0' defaults to a null key.
sca_keynumber：このパラメータは、アプリケーションがこの共有キーを参照することにより、その共有鍵識別子です。指定したインデックスのキーがすでに存在する場合、この新しいキーは、古い既存のキーを置き換えます。ヌルキーにキー識別子「0」のデフォルトを共有ノート。
sca_keylength: This parameter is the length of the array sca_key.
sca_keylength：このパラメータは、配列sca_keyの長さです。
sca_key: This parameter contains an array of bytes that is to be used by the endpoint (or association) as the shared secret key. Note that if the length of this field is zero, a null key is set.
sca_key：このパラメータは、共有秘密鍵として、エンドポイント（または関連）によって使用されるバイトの配列を含んでいます。このフィールドの長さがゼロの場合、ヌルキーが設定されていることに注意してください。
This set option indicates that the application will no longer send user messages using the indicated key identifier.
このセットオプションは、アプリケーションがもはや示されたキー識別子を使用して、ユーザーのメッセージを送信しないことを示します。
struct sctp_authkeyid {
sctp_assoc_t scact_assoc_id;
uint16_t scact_keynumber;
};
scact_assoc_id: This parameter indicates from which association the shared key identifier is being deleted. The special SCTP_{FUTURE| CURRENT|ALL}_ASSOC can be used. For one-to-one style sockets, this parameter is ignored. Note, however, that this option will deactivate the key from the association if the socket is connected; otherwise, this option will deactivate the key from the endpoint.
scact_assoc_id：このパラメータは、共有鍵識別子が削除されている関連付けから示しています。特別SCTP_ {FUTURE | CURRENT | ALL} _ASSOCを使用することができます。 1対1スタイルソケットの場合、このパラメータは無視されます。ソケットが接続されている場合、このオプションは協会からキーを無効にすること、しかし、注意してください。そうでない場合は、このオプションは、エンドポイントからのキーを無効にします。
scact_keynumber: This parameter is the shared key identifier that the application is requesting to be deactivated. The key identifier must correspond to an existing shared key. Note that if this parameter is zero, use of the null key identifier '0' is deactivated on the endpoint and/or association.
scact_keynumber：このパラメータは、アプリケーションが非アクティブ化されるように要求している共有鍵識別子です。キー識別子は、既存の共有鍵に対応しなければなりません。このパラメータがゼロの場合、ヌルキー識別子「0」の使用は、エンドポイントおよび/または関連に不活性化されることに留意されたいです。
The currently active key cannot be deactivated.
現在アクティブなキーを無効にすることはできません。
This set option will delete an SCTP association's shared secret key that has been deactivated.
このセットオプションが無効になっているSCTPアソシエーションの共有秘密鍵を削除します。
struct sctp_authkeyid {
sctp_assoc_t scact_assoc_id;
uint16_t scact_keynumber;
};
scact_assoc_id: This parameter indicates from which association the shared key identifier is being deleted. The special SCTP_{FUTURE| CURRENT|ALL}_ASSOC can be used. For one-to-one style sockets, this parameter is ignored. Note, however, that this option will delete the key from the association if the socket is connected; otherwise, this option will delete the key from the endpoint.
scact_assoc_id：このパラメータは、共有鍵識別子が削除されている関連付けから示しています。特別SCTP_ {FUTURE | CURRENT | ALL} _ASSOCを使用することができます。 1対1スタイルソケットの場合、このパラメータは無視されます。ソケットが接続されている場合、このオプションは協会からキーを削除すること、しかし、注意してください。そうでない場合は、このオプションは、エンドポイントからキーを削除します。
scact_keynumber: This parameter is the shared key identifier that the application is requesting to be deleted. The key identifier must correspond to an existing shared key and must not be in use for any packet being sent by the SCTP implementation. This means, in particular, that it must be deactivated first. Note that if this parameter is zero, use of the null key identifier '0' is deleted from the endpoint and/or association.
scact_keynumber：このパラメータは、アプリケーションが削除されるように要求している共有鍵識別子です。キー識別子は、既存の共有鍵に対応しなければならず、SCTP実装によって送信されるすべてのパケットのために使用中であってはなりません。これは、最初に無効化されなければならないことを、具体的には、意味します。このパラメータがゼロの場合、ヌルキー識別子「0」の使用は、エンドポイントおよび/または関連から削除されることに留意されたいです。
Only deactivated keys that are no longer used by an association can be deleted.
もはやアソシエーションによって使用されている唯一の非アクティブ化キーを削除することができます。
Depending on the system, the following interface can be implemented as a system call or library function.
システムに応じて、次のインタフェースは、システムコールやライブラリ関数として実装することができます。
This function allows the user to bind a specific subset of addresses or, if the SCTP extension described in [RFC5061] is supported, add or delete specific addresses.
この機能は、ユーザがアドレスの特定のサブセットに結合することができ、または、[RFC5061]に記載のSCTP拡張がサポートされている場合、特定のアドレスを追加または削除します。
The function prototype is
関数プロトタイプは、
int sctp_bindx(int sd, struct sockaddr *addrs, int addrcnt, int flags);
int型と、sctp_bindx（int型SD、*アドレスが使われるsockaddr構造体、int型のaddrcnt、フラグをint型）;
If sd is an IPv4 socket, the addresses passed must be IPv4 addresses. If the sd is an IPv6 socket, the addresses passed can either be IPv4 or IPv6 addresses.
SDはIPv4ソケットである場合には、渡されたアドレスは、IPv4アドレスである必要があります。 SDはIPv6ソケットである場合は、渡されたアドレスは、IPv4またはIPv6のアドレスをすることができます。
A single address may be specified as INADDR_ANY for an IPv4 address, or as IN6ADDR_ANY_INIT or in6addr_any for an IPv6 address; see Section 3.1.2 for this usage.
単一のアドレスは、IPv4アドレスのために、またはIPv6アドレスのIN6ADDR_ANY_INIT又はIN6ADDR_ANYとしてINADDR_ANYとして指定することができます。この使用方法については、セクション3.1.2を参照してください。
addrs is a pointer to an array of one or more socket addresses. Each address is contained in its appropriate structure. For an IPv6 socket, an array of sockaddr_in6 is used. For an IPv4 socket, an array of sockaddr_in is used. The caller specifies the number of addresses in the array with addrcnt. Note that the wildcard addresses cannot be used in combination with non-wildcard addresses on a socket with this function; doing so will result in an error.
アドレスが使われる一つまたはそれ以上のソケットアドレスの配列へのポインタです。各アドレスは、その適切な構造に含まれています。 IPv6ソケットのために、SOCKADDR_IN6のアレイが使用されます。 IPv4ソケットため、sockaddr_in構造体のアレイが使用されます。呼び出し側はaddrcntと、アレイ内のアドレスの数を指定します。ワイルドカードアドレスがこの機能を備えたソケットの非ワイルドカードアドレスと組み合わせて使用することができないことに留意されたいです。そうすると、エラーになります。
On success, sctp_bindx() returns 0. On failure, sctp_bindx() returns -1 and sets errno to the appropriate error code.
成功した、と、sctp_bindx（））（と、sctp_bindx、失敗した場合0を返す-1を返し、適切なエラーコードをerrnoに設定します。
For SCTP, the port given in each socket address must be the same, or sctp_bindx() will fail, setting errno to EINVAL.
SCTPのために、各ソケットアドレスで指定されたポートが同じでなければならない、あるいはと、sctp_bindx（）EINVALをerrnoに設定し、失敗します。
The flags parameter is formed from the bitwise OR of zero or more of the following currently defined flags:
flagsパラメータは、ビット単位のOR以下現在定義されたフラグのゼロ以上で形成されています。
o SCTP_BINDX_ADD_ADDR
O SCTP_BINDX_ADD_ADDR
o SCTP_BINDX_REM_ADDR
O SCTP_BINDX_REM_ADDR
SCTP_BINDX_ADD_ADDR directs SCTP to add the given addresses to the socket (i.e., endpoint), and SCTP_BINDX_REM_ADDR directs SCTP to remove the given addresses from the socket. The two flags are mutually exclusive; if both are given, sctp_bindx() will fail with EINVAL. A caller may not remove all addresses from a socket; sctp_bindx() will reject such an attempt with EINVAL.
SCTP_BINDX_ADD_ADDRソケット（すなわち、エンドポイント）に与えられたアドレスを追加するために、SCTPを指示し、そしてSCTP_BINDX_REM_ADDRがソケットから所定のアドレスを削除するSCTPを指示します。 2つのフラグが相互に排他的です。両方が指定された場合、sctp_bindx（）はEINVALで失敗します。呼び出し側は、ソケットからすべてのアドレスを削除することはできません。 sctp_bindx（）はEINVALを持つような試みを拒否します。
An application can use sctp_bindx(SCTP_BINDX_ADD_ADDR) to associate additional addresses with an endpoint after calling bind(). Or, an application can use sctp_bindx(SCTP_BINDX_REM_ADDR) to remove some addresses with which a listening socket is associated, so that no new association accepted will be associated with these addresses. If the endpoint supports dynamic address reconfiguration, an SCTP_BINDX_REM_ADDR or SCTP_BINDX_ADD_ADDR may cause an endpoint to send the appropriate message to its peers to change the peers' address lists.
アプリケーションがバインドを呼び出した後にエンドポイントと追加のアドレスを関連付けすると、sctp_bindx（SCTP_BINDX_ADD_ADDR）を使用することができます（）。または、アプリケーションが受け入れられる新たな関連付けは、これらのアドレスに関連付けされないように、リスニングソケットが関連付けられているいくつかのアドレスを削除すると、sctp_bindx（SCTP_BINDX_REM_ADDR）を使用することができます。エンドポイントが動的アドレスの再構成をサポートしている場合、SCTP_BINDX_REM_ADDRまたはSCTP_BINDX_ADD_ADDRは、ピアのアドレスリストを変更するには、そのピアに適切なメッセージを送信するためにエンドポイントが発生することがあります。
Adding and removing addresses from established associations is an optional functionality. Implementations that do not support this functionality should return -1 and set errno to EOPNOTSUPP.
確立されたアソシエーションからアドレスを追加および削除するオプションの機能です。この機能をサポートしていない実装は-1を返しEOPNOTSUPPをerrnoに設定する必要があります。
sctp_bindx() can be called on an already bound socket or on an unbound socket. If the socket is unbound and the first port number in the addrs parameter is zero, the kernel will choose a port number. All port numbers after the first one being 0 must also be zero. If the first port number is not zero, the following port numbers must be zero or have the same value as the first one. For an already bound socket, all port numbers provided must be the bound one or 0.
sctp_bindx（）は、すでにバインドされたソケットにバインドされていないか、ソケット上で呼び出すことができます。ソケットがバインドされていないとaddrsパラメータの最初のポート番号がゼロの場合、カーネルは、ポート番号を選択します。 0は最初の1の後にすべてのポート番号もゼロでなければなりません。第1のポート数がゼロでない場合、次のポート番号はゼロであるか、または最初のものと同じ値を有していなければなりません。すでにバインドされたソケットの場合は、提供されたすべてのポート番号は、1または0をバインドする必要があります。
sctp_bindx() is an atomic operation. Therefore, the binding will either succeed on all addresses or fail on all addresses. If multiple addresses are provided and the sctp_bindx() call fails, there is no indication of which address is responsible for the failure. The only way to identify the specific error indication is to call sctp_bindx() sequentially with only one address per call.
sctp_bindx（）はアトミック操作です。したがって、結合はすべてのアドレスに成功するか、すべてのアドレスに失敗しますか。複数のアドレスを提供するとと、sctp_bindx（）呼び出しが失敗している場合は、失敗の責任がどのアドレスの兆候はありません。特定のエラー表示を識別するための唯一の方法は、呼び出しごとに1つのアドレスを持つと、sctp_bindx（）連続して呼び出すことです。
After an association is established on a one-to-many style socket, the application may wish to branch off the association into a separate socket/file descriptor.
関連付けは1対多のスタイルのソケットに確立された後、アプリケーションは別のソケット/ファイルディスクリプタに関連付けを分岐することもできます。
This is particularly desirable when, for instance, the application wishes to have a number of sporadic message senders/receivers remain under the original one-to-many style socket but branch off these associations carrying high-volume data traffic into their own separate socket descriptors.
例えば、アプリケーションは、送信者/受信機が元の1対多スタイルソケットの下に残っているが、独自の別個のソケット記述子に大量のデータトラフィックを運ぶこれらの関連付けを分岐散発的なメッセージの数を有することを望む場合、これは特に望ましいです。
The application uses the sctp_peeloff() call to branch off an association into a separate socket. (Note that the semantics are somewhat changed from the traditional one-to-one style accept() call.) Note also that the new socket is a one-to-one style socket. Thus, it will be confined to operations allowed for a one-to-one style socket.
アプリケーションは、別個のソケットに関連付けを分岐するsctp_peeloff（）コールを使用します。 （セマンティクスが多少伝統的な一対一のスタイル受け入れる（）の呼び出しから変更されていることに注意してください。）注も新しいソケットは1対1のスタイルのソケットであること。したがって、1対1のスタイルのソケットのために許可された操作に限定されます。
The function prototype is
関数プロトタイプは、
int sctp_peeloff(int sd, sctp_assoc_t assoc_id);
int型sctp_peeloff（int型SD、sctp_assoc_t assoc_id）。
and the arguments are
そして、引数は、
sd: The original one-to-many style socket descriptor returned from the socket() system call (see Section 3.1.1).
SD：ソケット（）システムコールから返された元一対多スタイルのソケット記述子（3.1.1項を参照してください）。
assoc_id: The specified identifier of the association that is to be branched off to a separate file descriptor. (Note that in a traditional one-to-one style accept() call, this would be an out parameter, but for the one-to-many style call, this is an in parameter.)
assoc_id：別のファイル記述子に分岐する関連の指定された識別子。 （従来の1対1のスタイルで（）の呼び出しを受け入れることに注意してください、これはアウトパラメータになるが、1対多のスタイルの呼び出しのために、これはパラメータです。）
The function returns a non-negative file descriptor representing the branched-off association, or -1 if an error occurred. The variable errno is then set appropriately.
関数は、分岐さアソシエーションを表す非負のファイル記述子を返し、エラーが起きた場合は-1。変数errnoが、その後適切に設定されています。
sctp_getpaddrs() returns all peer addresses in an association.
sctp_getpaddrs（）関連してすべてのピアのアドレスを返します。
The function prototype is
関数プロトタイプは、
int sctp_getpaddrs(int sd, sctp_assoc_t id, struct sockaddr **addrs);
int型のsctp_getpaddrs（int型SD、sctp_assoc_t ID、sockaddr構造体**アドレスが使われます）。
On return, addrs will point to a dynamically allocated array of sockaddr structures of the appropriate type for the socket type. The caller should use sctp_freepaddrs() to free the memory. Note that the in/out parameter addrs must not be NULL.
リターン時に、アドレスが使われるソケットのタイプに適したタイプののsockaddr構造の動的に割り当てられた配列を指します。呼び出し側は（）メモリを解放するためにsctp_freepaddrsを使用する必要があります。 /出力パラメータのアドレスが使われるがNULLであってはならないことに注意してください。
If sd is an IPv4 socket, the addresses returned will be all IPv4 addresses. If sd is an IPv6 socket, the addresses returned can be a mix of IPv4 or IPv6 addresses, with IPv4 addresses returned according to the SCTP_I_WANT_MAPPED_V4_ADDR option setting.
SDはIPv4ソケットである場合、返されるアドレスは、すべてのIPv4アドレスとなります。 SDはIPv6ソケットである場合、返されるアドレスはSCTP_I_WANT_MAPPED_V4_ADDRオプションの設定に応じて返されたIPv4アドレスを、IPv4またはIPv6アドレスが混在することができます。
For one-to-many style sockets, id specifies the association to query. For one-to-one style sockets, id is ignored.
1対多のスタイルのソケットの場合、idが照会する関連付けを指定します。 1対1スタイルソケットの場合、idは無視されます。
On success, sctp_getpaddrs() returns the number of peer addresses in the association. If there is no association on this socket, sctp_getpaddrs() returns 0, and the value of *addrs is undefined. If an error occurs, sctp_getpaddrs() returns -1, and the value of *addrs is undefined.
成功した場合、のsctp_getpaddrs（）は、関連付け内のピアアドレスの数を返します。このソケットには関連がない場合、のsctp_getpaddrs（）は0を返し、* addrsの値は未定義です。エラーが発生した場合、のsctp_getpaddrs（）-1を返し、* addrsの値は未定義です。
sctp_freepaddrs() frees all resources allocated by sctp_getpaddrs().
sctp_freepaddrs（））（のsctp_getpaddrsによって割り当てられたすべてのリソースを解放します。
The function prototype is
関数プロトタイプは、
void sctp_freepaddrs(struct sockaddr *addrs);
空sctp_freepaddrs（sockaddr構造体の*アドレス）;
and addrs is the array of peer addresses returned by sctp_getpaddrs().
そしてアドレスが使われるのsctp_getpaddrsによって返されたピアアドレスの配列（）です。
sctp_getladdrs() returns all locally bound addresses on a socket.
sctp_getladdrs（）ソケット上のすべてのローカルにバインドされたアドレスを返します。
The function prototype is
関数プロトタイプは、
int sctp_getladdrs(int sd, sctp_assoc_t id, struct sockaddr **addrs);
int型のsctp_getladdrs（int型SD、sctp_assoc_t ID、sockaddr構造体**アドレスが使われます）。
On return, addrs will point to a dynamically allocated array of sockaddr structures of the appropriate type for the socket type. The caller should use sctp_freeladdrs() to free the memory. Note that the in/out parameter addrs must not be NULL.
リターン時に、アドレスが使われるソケットのタイプに適したタイプののsockaddr構造の動的に割り当てられた配列を指します。呼び出し側は（）メモリを解放するためにsctp_freeladdrsを使用する必要があります。 /出力パラメータのアドレスが使われるがNULLであってはならないことに注意してください。
If sd is an IPv4 socket, the addresses returned will be all IPv4 addresses. If sd is an IPv6 socket, the addresses returned can be a mix of IPv4 or IPv6 addresses, with IPv4 addresses returned according to the SCTP_I_WANT_MAPPED_V4_ADDR option setting.
SDはIPv4ソケットである場合、返されるアドレスは、すべてのIPv4アドレスとなります。 SDはIPv6ソケットである場合、返されるアドレスはSCTP_I_WANT_MAPPED_V4_ADDRオプションの設定に応じて返されたIPv4アドレスを、IPv4またはIPv6アドレスが混在することができます。
For one-to-many style sockets, id specifies the association to query. For one-to-one style sockets, id is ignored.
1対多のスタイルのソケットの場合、idが照会する関連付けを指定します。 1対1スタイルソケットの場合、idは無視されます。
If the id field is set to the value '0', then the locally bound addresses are returned without regard to any particular association.
idフィールドが値「0」に設定されている場合は、ローカルにバインドされたアドレスは、特定の団体に関係なく返されます。
On success, sctp_getladdrs() returns the number of local addresses bound to the socket. If the socket is unbound, sctp_getladdrs() returns 0, and the value of *addrs is undefined. If an error occurs, sctp_getladdrs() returns -1, and the value of *addrs is undefined.
成功した場合、のsctp_getladdrs（）はソケットにバインドされたローカルアドレスの数を返します。ソケットがバインドされていない場合、のsctp_getladdrs（）0を返し、* addrsの値は未定義です。エラーが発生した場合、のsctp_getladdrs（）-1を返し、* addrsの値は未定義です。
sctp_freeladdrs() frees all resources allocated by sctp_getladdrs().
sctp_freeladdrs（））（のsctp_getladdrsによって割り当てられたすべてのリソースを解放します。
The function prototype is
関数プロトタイプは、
void sctp_freeladdrs(struct sockaddr *addrs);
空sctp_freeladdrs（sockaddr構造体の*アドレス）;
and addrs is the array of local addresses returned by sctp_getladdrs().
そしてアドレスが使われるのsctp_getladdrsによって返されるローカルアドレス（）の配列です。
This function is deprecated; sctp_sendv() (see Section 9.12) should be used instead.
この関数は廃止されました。 sctp_sendv（）の代わりに使用する必要があります（項9.12を参照してください）。
An implementation may provide a library function (or possibly system call) to assist the user with the advanced features of SCTP.
実装は、SCTPの高度な機能を持つユーザーを支援するためのライブラリ関数（あるいはシステムコール）を提供することができます。
The function prototype is
関数プロトタイプは、
ssize_t sctp_sendmsg(int sd, const void *msg, size_t len, const struct sockaddr *to, socklen_t tolen, uint32_t ppid, uint32_t flags, uint16_t stream_no, uint32_t timetolive, uint32_t context);
ssize_tのsctp_sendmsg（のsocklen_t tolenの、のuint32_t PPID、のuint32_tフラグ、uint16_t stream_no、のuint32_t TimeToLiveの、のuint32_tコンテキストにSD、CONSTのvoid *のMSG、size_tのLEN、constのsockaddr構造体*をint型）;
and the arguments are
そして、引数は、
sd: The socket descriptor.
SD：ソケット記述子。
msg: The message to be sent.
MSG：メッセージを送信します。
len: The length of the message.
LEN：メッセージの長さ。
to: The destination address of the message.
To：メッセージの送信先アドレス。
tolen: The length of the destination address.
tolenの：宛先アドレスの長さ。
ppid: The same as sinfo_ppid (see Section 5.3.2).
PPID：sinfo_ppidと同じ（5.3.2項を参照してください）。
flags: The same as sinfo_flags (see Section 5.3.2).
フラグ：sinfo_flags（5.3.2項を参照）と同じ。
stream_no: The same as sinfo_stream (see Section 5.3.2).
stream_no：sinfo_streamと同じ（5.3.2項を参照してください）。
timetolive: The same as sinfo_timetolive (see Section 5.3.2).
TimeToLiveの：sinfo_timetoliveと同じ（5.3.2項を参照してください）。
context: The same as sinfo_context (see Section 5.3.2).
コンテキスト：sinfo_contextと同じ（5.3.2項を参照してください）。
The call returns the number of characters sent, or -1 if an error occurred. The variable errno is then set appropriately.
コールは、送信された文字数を返し、エラーが発生した場合は-1。変数errnoが、その後適切に設定されています。
Sending a message using sctp_sendmsg() is atomic (unless explicit EOR marking is enabled on the socket specified by sd).
（マーキング明示EORをSDによって指定されたソケットで有効になっていない場合））（sctp_sendmsgを使用してメッセージを送信する原子です。
Using sctp_sendmsg() on a non-connected one-to-one style socket for implicit connection setup may or may not work, depending on the SCTP implementation.
暗黙の接続設定のための非接続1対1のスタイルのソケットにsctp_sendmsg（）を使用すると、またはSCTPの実装に依存し、動作しない場合があります。
This function is deprecated; sctp_recvv() (see Section 9.13) should be used instead.
この関数は廃止されました。 sctp_recvv（）の代わりに使用する必要があります（項9.13を参照してください）。
An implementation may provide a library function (or possibly system call) to assist the user with the advanced features of SCTP. Note that in order for the sctp_sndrcvinfo structure to be filled in by sctp_recvmsg(), the caller must enable the sctp_data_io_event with the SCTP_EVENTS option. Note that the setting of the SCTP_USE_EXT_RCVINFO will affect this function as well, causing the sctp_sndrcvinfo information to be extended.
実装は、SCTPの高度な機能を持つユーザーを支援するためのライブラリ関数（あるいはシステムコール）を提供することができます。 ）にsctp_sndrcvinfo構造のためにsctp_recvmsg（によって充填されることに注意し、発信者はSCTP_EVENTSオプションとsctp_data_io_eventを有効にする必要があります。 SCTP_USE_EXT_RCVINFOの設定はにsctp_sndrcvinfo情報を拡張する原因だけでなく、この機能に影響することに注意してください。
The function prototype is
関数プロトタイプは、
ssize_t sctp_recvmsg(int sd, void *msg, size_t len, struct sockaddr *from, socklen_t *fromlen struct sctp_sndrcvinfo *sinfo int *msg_flags);
ssize_tのsctp_recvmsg（int型* msg_flags SINFO * fromlen構造体にsctp_sndrcvinfo *のsocklen_t、MSG、size_tのLEN、sockaddr構造体の*から*無効、SDをINT）;
and the arguments are
そして、引数は、
sd: The socket descriptor.
SD：ソケット記述子。
msg: The message buffer to be filled.
MSG：メッセージバッファが充填されます。
len: The length of the message buffer.
LEN：メッセージバッファの長さ。
from: A pointer to an address to be filled with the address of the sender of this message.
From：このメッセージの送信者のアドレスで充填するアドレスへのポインタ。
fromlen: An in/out parameter describing the from length.
fromlen：長さから説明IN /出力パラメータ。
sinfo: A pointer to an sctp_sndrcvinfo structure to be filled upon receipt of the message.
SINFO：メッセージの受信時に充填するにsctp_sndrcvinfo構造体へのポインタ。
msg_flags: A pointer to an integer to be filled with any message flags (e.g., MSG_NOTIFICATION). Note that this field is an in-out field. Options for the receive may also be passed into the value (e.g., MSG_PEEK). On return from the call, the msg_flags value will be different than what was sent in to the call. If implemented via a recvmsg() call, the msg_flags parameter should only contain the value of the flags from the recvmsg() call.
msg_flags：任意のメッセージフラグで充填される整数へのポインタ（例えば、MSG_NOTIFICATION）。このフィールドは、インアウトフィールドであることに注意してください。受信するためのオプションも値（例えば、MSG_PEEK）に渡されてもよいです。呼び出しからの戻りで、msg_flags値は、コールに送信されたものとは異なるものになります。 recvmsg（）呼び出しを介して実装されていれば、msg_flagsパラメータはのみのrecvmsg（）呼び出しからのフラグの値が含まれている必要があります。
The call returns the number of bytes received, or -1 if an error occurred. The variable errno is then set appropriately.
呼が受信されたバイト数を返し、エラーが起きた場合は-1。変数errnoが、その後適切に設定されています。
An implementation may provide a library function (or possibly system call) to assist the user with associating to an endpoint that is multi-homed. Much like sctp_bindx(), this call allows a caller to specify multiple addresses at which a peer can be reached. The way the SCTP stack uses the list of addresses to set up the association is implementation dependent. This function only specifies that the stack will try to make use of all of the addresses in the list when needed.
実装は、マルチホームであるエンドポイントに関連付けることで、ユーザを支援するライブラリ関数（あるいはシステムコール）を提供することができます。 sctp_bindx（）のような多く、この呼び出しは、呼び出し側は、ピアに到達可能な複数のアドレスを指定することができます。 SCTPスタックは関連付けを設定するアドレスのリストを使用する方法は実装依存です。この機能は、スタックが必要なときに、リスト内のアドレスのすべてを利用するようにしようとすることを指定します。
Note that the list of addresses passed in is only used for setting up the association. It does not necessarily equal the set of addresses the peer uses for the resulting association. If the caller wants to find out the set of peer addresses, it must use sctp_getpaddrs() to retrieve them after the association has been set up.
渡されたアドレスのリストのみ関連付けを設定するために使用されることに注意してください。必ずしもピアが得られたアソシエーションのために使用するアドレスのセットと等しくありません。呼び出し側がピア・アドレスのセットを見つけるしたい場合は、関連付けが設定された後にそれらを取得するために（）のsctp_getpaddrsを使用する必要があります。
The function prototype is
関数プロトタイプは、
int sctp_connectx(int sd, struct sockaddr *addrs, int addrcnt, sctp_assoc_t *id);
INT sctp_connectx（INT SD、構造体のsockaddr *アドレスが使われる、int型addrcnt、sctp_assoc_tの* ID）と、
and the arguments are
そして、引数は、
sd: The socket descriptor.
SD：ソケット記述子。
addrs: An array of addresses.
アドレスが使われる：アドレスの配列。
addrcnt: The number of addresses in the array.
addrcnt：配列内のアドレスの数。
id: An output parameter that, if passed in as non-NULL, will return the association identifier for the newly created association (if successful).
ID：（成功した場合）、非NULLに渡された場合、新たに作成された関連付けのための関連識別子を返します出力パラメータ。
The call returns 0 on success or -1 if an error occurred. The variable errno is then set appropriately.
呼び出しが成功すると0を返すか、-1エラーが発生した場合。変数errnoが、その後適切に設定されています。
This function is deprecated; sctp_sendv() should be used instead.
この関数は廃止されました。 sctp_sendvは（）の代わりに使用する必要があります。
An implementation may provide another alternative function or system call to assist an application with the sending of data without the use of the cmsghdr structures.
実装はのcmsghdr構造体を使用せずにデータの送信を使用してアプリケーションを支援するために、別の代替機能やシステムコールを提供することができます。
The function prototype is
関数プロトタイプは、
ssize_t sctp_send(int sd, const void *msg, size_t len, const struct sctp_sndrcvinfo *sinfo, int flags);
ssize_tのsctp_send（int型のSD、CONSTのvoid *のMSG、size_tのLEN、constの構造体にsctp_sndrcvinfo * SINFO、フラグINT）;
and the arguments are
そして、引数は、
sd: The socket descriptor.
SD：ソケット記述子。
msg: The message to be sent.
MSG：メッセージを送信します。
len: The length of the message.
LEN：メッセージの長さ。
sinfo: A pointer to an sctp_sndrcvinfo structure used as described in Section 5.3.2 for a sendmsg() call.
SINFO：にsendmsg（）呼び出しについては、セクション5.3.2に記載のように使用されるにsctp_sndrcvinfo構造体へのポインタ。
flags: The same flags as used by the sendmsg() call flags (e.g., MSG_DONTROUTE).
フラグ：にsendmsg（）呼び出しフラグ（例えば、MSG_DONTROUTE）によって使用されるものと同じフラグ。
The call returns the number of bytes sent, or -1 if an error occurred. The variable errno is then set appropriately.
呼び出しが送信されたバイト数を返し、エラーが発生した場合は-1。変数errnoが、その後適切に設定されています。
This function call may also be used to terminate an association using an association identifier by setting the sinfo.sinfo_flags to SCTP_EOF and the sinfo.sinfo_assoc_id to the association that needs to be terminated. In such a case, len can be zero.
この関数呼び出しも終了する必要が関連するSCTP_EOFとsinfo.sinfo_assoc_idにsinfo.sinfo_flagsを設定することにより、関連識別子を使用して関連付けを終了させるために使用されてもよいです。このような場合には、lenはゼロとすることができます。
Using sctp_send() on a non-connected one-to-one style socket for implicit connection setup may or may not work, depending on the SCTP implementation.
暗黙の接続設定のための非接続1対1のスタイルのソケットにsctp_send（）を使用すると、またはSCTPの実装に依存し、動作しない場合があります。
Sending a message using sctp_send() is atomic unless explicit EOR marking is enabled on the socket specified by sd.
マーキング明示EORをSDによって指定されたソケットで有効になっていない限り）（sctp_sendを使用してメッセージを送信する原子です。
This function is deprecated; sctp_sendv() should be used instead.
この関数は廃止されました。 sctp_sendvは（）の代わりに使用する必要があります。
An implementation may provide another alternative function or system call to assist an application with the sending of data without the use of the cmsghdr structure, and to provide a list of addresses. The list of addresses is provided for implicit association setup. In such a case, the list of addresses serves the same purpose as the addresses given in sctp_connectx() (see Section 9.9).
実装は、cmsghdr構造体を使用せずにデータの送信を使用してアプリケーションを支援するため、およびアドレスのリストを提供するために、別の代替関数またはシステムコールを提供することができます。アドレスのリストは、暗黙的な関連の設定のために提供されます。このような場合には、アドレスのリスト（セクション9.9を参照されたい））（sctp_connectxで与えられたアドレスと同じ目的を果たします。
The function prototype is
関数プロトタイプは、
ssize_t sctp_sendx(int sd, const void *msg, size_t len, struct sockaddr *addrs, int addrcnt, struct sctp_sndrcvinfo *sinfo, int flags);
ssize_tのsctp_sendx（int型SD、CONSTのvoid *のMSG、size_tのLEN、構造体のsockaddr *アドレスが使われる、int型のaddrcnt、構造体にsctp_sndrcvinfo * SINFOは、フラグをint型）;
and the arguments are
そして、引数は、
sd: The socket descriptor.
SD：ソケット記述子。
msg: The message to be sent.
MSG：メッセージを送信します。
len: The length of the message.
LEN：メッセージの長さ。
addrs: An array of addresses.
アドレスが使われる：アドレスの配列。
addrcnt: The number of addresses in the array.
addrcnt：配列内のアドレスの数。
sinfo: A pointer to an sctp_sndrcvinfo structure used as described in Section 5.3.2 for a sendmsg() call.
SINFO：にsendmsg（）呼び出しについては、セクション5.3.2に記載のように使用されるにsctp_sndrcvinfo構造体へのポインタ。
flags: The same flags as used by the sendmsg() call flags (e.g., MSG_DONTROUTE).
フラグ：にsendmsg（）呼び出しフラグ（例えば、MSG_DONTROUTE）によって使用されるものと同じフラグ。
The call returns the number of bytes sent, or -1 if an error occurred. The variable errno is then set appropriately.
呼び出しが送信されたバイト数を返し、エラーが発生した場合は-1。変数errnoが、その後適切に設定されています。
Note that in the case of implicit connection setup, on return from this call, the sinfo_assoc_id field of the sinfo structure will contain the new association identifier.
暗黙の接続設定の場合には、この呼び出しからの戻り時に、SINFO構造のsinfo_assoc_idフィールドは、新しいアソシエーション識別子が含まれていることに注意してください。
This function call may also be used to terminate an association using an association identifier by setting the sinfo.sinfo_flags to SCTP_EOF and the sinfo.sinfo_assoc_id to the association that needs to be terminated. In such a case, len would be zero.
この関数呼び出しも終了する必要が関連するSCTP_EOFとsinfo.sinfo_assoc_idにsinfo.sinfo_flagsを設定することにより、関連識別子を使用して関連付けを終了させるために使用されてもよいです。このような場合には、lenはゼロであろう。
Sending a message using sctp_sendx() is atomic unless explicit EOR marking is enabled on the socket specified by sd.
マーキング明示EORをSDによって指定されたソケットで有効になっていない限り）（sctp_sendxを使用してメッセージを送信する原子です。
Using sctp_sendx() on a non-connected one-to-one style socket for implicit connection setup may or may not work, depending on the SCTP implementation.
暗黙の接続設定のための非接続1対1のスタイルのソケットにsctp_sendx（）を使用すると、またはSCTPの実装に依存し、動作しない場合があります。
The function prototype is
関数プロトタイプは、
ssize_t sctp_sendv(int sd, const struct iovec *iov, int iovcnt, struct sockaddr *addrs, int addrcnt, void *info, socklen_t infolen, unsigned int infotype, int flags);
ssize_tのsctp_sendv（int型SD、constの構造体のIOVEC * IOV、int型のiovcnt、構造体のsockaddr *アドレスが使われる、int型のaddrcnt、void *型情報、socklen_tをinfolen、unsigned int型のインフォタイプは、フラグをint型）;
The function sctp_sendv() provides an extensible way for an application to communicate different send attributes to the SCTP stack when sending a message. An implementation may provide sctp_sendv() as a library function or a system call.
関数sctp_sendv（）メッセージを送信するときSCTPスタックに異なる送信属性を通信するアプリケーションのための拡張可能な方法を提供します。実装は、ライブラリ関数やシステムコールとしてsctp_sendvを（）を提供することができます。
This document defines three types of attributes that can be used to describe a message to be sent. They are struct sctp_sndinfo (Section 5.3.4), struct sctp_prinfo (Section 5.3.7), and struct sctp_authinfo (Section 5.3.8). The following structure, sctp_sendv_spa, is defined to be used when more than one of the above attributes are needed to describe a message to be sent.
この文書では、送信されるメッセージを記述するために使用できる属性の三種類を定義します。彼らは、構造体sctp_prinfo構造体sctp_sndinfo（セクション5.3.4）、（5.3.7項）、および構造体sctp_authinfo（5.3.8項）です。以下の構造、sctp_sendv_spaは、上記属性の複数の送信されるメッセージを記述するために必要とされるときに使用されるように定義されます。
struct sctp_sendv_spa {
uint32_t sendv_flags;
struct sctp_sndinfo sendv_sndinfo;
struct sctp_prinfo sendv_prinfo;
struct sctp_authinfo sendv_authinfo;
};
The sendv_flags field holds a bitwise OR of SCTP_SEND_SNDINFO_VALID, SCTP_SEND_PRINFO_VALID, and SCTP_SEND_AUTHINFO_VALID indicating if the sendv_sndinfo/sendv_prinfo/sendv_authinfo fields contain valid information.
sendv_flagsフィールドはsendv_sndinfo / sendv_prinfo / sendv_authinfoフィールドは有効な情報が含まれているかどうかを示すSCTP_SEND_SNDINFO_VALID、SCTP_SEND_PRINFO_VALID、およびSCTP_SEND_AUTHINFO_VALIDのビット単位のORを保持しています。
In future, when new send attributes are needed, new structures can be defined. But those new structures do not need to be based on any of the above defined structures.
新しい送信属性が必要とされ、今後、で、新しい構造を定義することができます。しかし、これらの新しい構造は、上記で定義された構造のいずれかに基づいてする必要はありません。
The function takes the following arguments:
この関数は以下の引数を取ります。
sd: The socket descriptor.
SD：ソケット記述子。
iov: The gather buffer. The data in the buffer is treated as a single user message.
IOV：バッファを収集します。バッファ内のデータは、単一のユーザメッセージとして扱われます。
iovcnt: The number of elements in iov.
iovcnt：IOVの要素数。
addrs: An array of addresses to be used to set up an association or a single address to be used to send the message. NULL is passed in if the caller neither wants to set up an association nor wants to send the message to a specific address.
アドレスが使われる：アソシエーションまたはメッセージを送信するために使用される単一のアドレスを設定するために使用するアドレスのアレイ。呼び出し元がどちらの関連付けを設定したいことも、特定のアドレスにメッセージを送信したい場合はNULLが渡されます。
addrcnt: The number of addresses in the addrs array.
addrcnt：アドレスが使われる配列のアドレスの数。
info: A pointer to the buffer containing the attribute associated with the message to be sent. The type is indicated by the info_type parameter.
INFO：送信するメッセージに関連付けられた属性を含むバッファへのポインタ。型はinfo_typeパラメータによって示されます。
infolen: The length of info, in bytes.
infolen：情報の長さをバイト単位で指定します。
infotype: Identifies the type of the information provided in info. The current defined values are as follows:
インフォタイプは：情報で提供される情報の種類を識別します。次のように現在定義された値は次のとおりです。
SCTP_SENDV_NOINFO: No information is provided. The parameter info is a NULL pointer, and infolen is 0.
SCTP_SENDV_NOINFO：何の情報が提供されていません。パラメータ情報は、NULLポインタである、とinfolenは0です。
SCTP_SENDV_SNDINFO: The parameter info is pointing to a struct sctp_sndinfo.
SCTP_SENDV_SNDINFO：パラメータ情報は、構造体sctp_sndinfoを指しています。
SCTP_SENDV_PRINFO: The parameter info is pointing to a struct sctp_prinfo.
SCTP_SENDV_PRINFO：パラメータ情報は、構造体sctp_prinfoを指しています。
SCTP_SENDV_AUTHINFO: The parameter info is pointing to a struct sctp_authinfo.
SCTP_SENDV_AUTHINFO：パラメータ情報は、構造体sctp_authinfoを指しています。
SCTP_SENDV_SPA: The parameter info is pointing to a struct sctp_sendv_spa.
SCTP_SENDV_SPA：パラメータ情報は、構造体sctp_sendv_spaを指しています。
flags: The same flags as used by the sendmsg() call flags (e.g., MSG_DONTROUTE).
フラグ：にsendmsg（）呼び出しフラグ（例えば、MSG_DONTROUTE）によって使用されるものと同じフラグ。
The call returns the number of bytes sent, or -1 if an error occurred. The variable errno is then set appropriately.
呼び出しが送信されたバイト数を返し、エラーが発生した場合は-1。変数errnoが、その後適切に設定されています。
A note on the one-to-many style socket: The struct sctp_sndinfo attribute must always be used in order to specify the association on which the message is to be sent. The only case where it is not needed is when this call is used to set up a new association.
1対多のスタイルのソケット上の注意：属性sctp_sndinfo構造体は、常にメッセージが送信される上での関連付けを指定するために使用する必要があります。この呼び出しは、新しい関連付けを設定するために使用されている場合、それが必要とされていない場合のみです。
The caller provides a list of addresses in the addrs parameter to set up an association. This function will behave like calling sctp_connectx() (see Section 9.9), first using the list of addresses and then calling sendmsg() with the given message and attributes. For a one-to-many style socket, if the struct sctp_sndinfo attribute is provided, the snd_assoc_id field must be 0. When this function returns, the snd_assoc_id field will contain the association identifier of the newly established association. Note that the struct sctp_sndinfo attribute is not required to set up an association for a one-to-many style socket. If this attribute is not provided, the caller can enable the SCTP_ASSOC_CHANGE notification and use the SCTP_COMM_UP message to find out the association identifier.
呼び出し側は、関連付けを設定するにはaddrsパラメータにアドレスのリストを提供します。この関数は、最初のアドレスのリストを使用して、その後、与えられたメッセージと属性では、sendmsg（）を呼び出す、（セクション9.9を参照））（sctp_connectxを呼び出すように動作します。属性sctp_sndinfo構造体が提供されている場合、この関数が戻ると、snd_assoc_idフィールドが新たに設立された協会の関連識別子が含まれます場合は1対多のスタイルのソケットについては、snd_assoc_idフィールドは0でなければなりません。構造体sctp_sndinfo属性は1対多のスタイルのソケットの関連付けを設定するために必要ではないことに注意してください。この属性が提供されていない場合、呼び出し側はSCTP_ASSOC_CHANGE通知を有効にし、関連識別子を見つけるためにSCTP_COMM_UPメッセージを使用することができます。
If the caller wants to send the message to a specific peer address (hence overriding the primary address), it can provide the specific address in the addrs parameter and provide a struct sctp_sndinfo attribute with the field snd_flags set to SCTP_ADDR_OVER.
呼び出し側が（したがって、プライマリアドレスを上書きする）特定のピアアドレスにメッセージを送信したい場合は、addrsパラメータで特定のアドレスを提供し、フィールドを持つ構造体のsctp_sndinfo属性がSCTP_ADDR_OVERに設定snd_flags提供することができます。
This function call may also be used to terminate an association. The caller provides an sctp_sndinfo attribute with the snd_flags set to SCTP_EOF. In this case, len would be zero.
この関数呼び出しは、また、関連付けを終了させるために使用されてもよいです。呼び出し側はSCTP_EOFに設定snd_flagsとsctp_sndinfo属性を提供します。この場合、lenはゼロになります。
Sending a message using sctp_sendv() is atomic unless explicit EOR marking is enabled on the socket specified by sd.
マーキング明示EORをSDによって指定されたソケットで有効になっていない限り）（sctp_sendvを使用してメッセージを送信する原子です。
The function prototype is
関数プロトタイプは、
ssize_t sctp_recvv(int sd, const struct iovec *iov, int iovlen, struct sockaddr *from, socklen_t *fromlen, void *info, socklen_t *infolen, unsigned int *infotype, int *flags);
ssize_tのsctp_recvv（fromlen *のsocklen_tからSD、constの構造体IOVEC * IOV、int型iovlen、sockaddr構造体*をint型、void *型の情報、のsocklen_t * infolen、unsigned int型*インフォタイプ、INT *フラグ）;
The function sctp_recvv() provides an extensible way for the SCTP stack to pass up different SCTP attributes associated with a received message to an application. An implementation may provide sctp_recvv() as a library function or as a system call.
関数sctp_recvv（）はSCTPスタックは、アプリケーションに、受信したメッセージに関連付けられた異なるSCTP属性を渡すための拡張可能な方法を提供します。実装はライブラリ関数として、またはシステムコールとしてsctp_recvv（）を提供してもよいです。
This document defines two types of attributes that can be returned by this call: the attribute of the received message and the attribute of the next message in the receive buffer. The caller enables the SCTP_RECVRCVINFO and SCTP_RECVNXTINFO socket options, respectively, to receive these attributes. Attributes of the received message are returned in struct sctp_rcvinfo (Section 5.3.5), and attributes of the next message are returned in struct sctp_nxtinfo (Section 5.3.6). If both options are enabled, both attributes are returned using the following structure.
受信したメッセージの属性と、受信バッファ内の次のメッセージの属性：この文書では、この呼び出しによって返される可能性が2種類の属性を定義します。呼び出し側は、これらの属性を受け取るために、それぞれ、SCTP_RECVRCVINFOとSCTP_RECVNXTINFOソケットオプションを有効にします。受信したメッセージの属性が構造体sctp_rcvinfo（セクション5.3.5）に戻され、次のメッセージの属性は構造体sctp_nxtinfo（セクション5.3.6）に返されます。両方のオプションが有効になっている場合は、両方の属性は次の構造を使用して返されます。
struct sctp_recvv_rn {
struct sctp_rcvinfo recvv_rcvinfo;
struct sctp_nxtinfo recvv_nxtinfo;
};
In future, new structures can be defined to hold new types of attributes. The new structures do not need to be based on struct sctp_recvv_rn or struct sctp_rcvinfo.
将来的には、新しい構造は、新しい属性の種類を保持するために定義することができます。新しい構造は、構造体sctp_recvv_rnや構造体sctp_rcvinfoに基づいてする必要はありません。
This function takes the following arguments:
この関数は、次の引数を取ります。
sd: The socket descriptor.
SD：ソケット記述子。
iov: The scatter buffer. Only one user message is returned in this buffer.
IOV：散布バッファ。一つだけのユーザメッセージは、このバッファに返されます。
iovlen: The number of elements in iov.
iovlen：IOVの要素数。
from: A pointer to an address to be filled with the sender of the received message's address.
From：アドレスへのポインタは、受信したメッセージのアドレスの送信者で満たされます。
fromlen: An in/out parameter describing the from length.
fromlen：長さから説明IN /出力パラメータ。
info: A pointer to the buffer to hold the attributes of the received message. The structure type of info is determined by the info_type parameter.
情報：受信したメッセージの属性を保持するバッファへのポインタ。情報の構造型はinfo_typeパラメータによって決定されます。
infolen: An in/out parameter describing the size of the info buffer.
infolen：インフォバッファのサイズを記述する/出力パラメータ。
infotype: On return, *info_type is set to the type of the info buffer. The current defined values are as follows:
インフォタイプ：リターンで、* info_typeは、インフォバッファのタイプに設定されています。次のように現在定義された値は次のとおりです。
SCTP_RECVV_NOINFO: If both SCTP_RECVRCVINFO and SCTP_RECVNXTINFO options are not enabled, no attribute will be returned. If only the SCTP_RECVNXTINFO option is enabled but there is no next message in the buffer, no attribute will be returned. In these cases, *info_type will be set to SCTP_RECVV_NOINFO.
SCTP_RECVV_NOINFO：SCTP_RECVRCVINFOとSCTP_RECVNXTINFO両方のオプションが有効になっていない場合は、何の属性が返されません。唯一SCTP_RECVNXTINFOオプションが有効になっていますが、バッファに次のメッセージが存在していない場合は、何の属性が返されません。これらのケースでは、* info_typeはSCTP_RECVV_NOINFOに設定されます。
SCTP_RECVV_RCVINFO: The type of info is struct sctp_rcvinfo, and the attribute relates to the received message.
SCTP_RECVV_RCVINFO：情報の種類は、構造体sctp_rcvinfoで、かつ属性が受信したメッセージに関連します。
SCTP_RECVV_NXTINFO: The type of info is struct sctp_nxtinfo, and the attribute relates to the next message in the receive buffer. This is the case when only the SCTP_RECVNXTINFO option is enabled and there is a next message in the buffer.
SCTP_RECVV_NXTINFO：情報の種類は、構造体sctp_nxtinfoであり、属性は受信バッファ内の次のメッセージにも関します。これが唯一のSCTP_RECVNXTINFOオプションが有効になっている場合で、次のメッセージがバッファ内にあります。
SCTP_RECVV_RN: The type of info is struct sctp_recvv_rn. The recvv_rcvinfo field is the attribute of the received message, and the recvv_nxtinfo field is the attribute of the next message in the buffer. This is the case when both SCTP_RECVRCVINFO and SCTP_RECVNXTINFO options are enabled and there is a next message in the receive buffer.
SCTP_RECVV_RN：情報の種類は、構造体sctp_recvv_rnです。 recvv_rcvinfoフィールドは、受信したメッセージの属性であり、recvv_nxtinfoフィールドは、バッファ内の次のメッセージの属性です。これは、両方のSCTP_RECVRCVINFOとSCTP_RECVNXTINFOオプションが有効になっている場合であり、次のメッセージが受信バッファに存在します。
flags: A pointer to an integer to be filled with any message flags (e.g., MSG_NOTIFICATION). Note that this field is an in/out parameter. Options for the receive may also be passed into the value (e.g., MSG_PEEK). On return from the call, the flags value will be different than what was sent in to the call. If implemented via a recvmsg() call, the flags should only contain the value of the flags from the recvmsg() call when calling sctp_recvv(), and on return it has the value from msg_flags.
フラグ：任意のメッセージフラグで充填される整数へのポインタ（例えば、MSG_NOTIFICATION）。このフィールドは/出力パラメータであることに注意してください。受信するためのオプションも値（例えば、MSG_PEEK）に渡されてもよいです。呼び出しからの戻り時に、フラグ値は、コールに送信されたものとは異なるものになります。 recvmsg（）呼び出しを介して実装された場合、フラグが唯一のrecvmsgからのフラグの値が含まれている必要があります（）sctp_recvvを（呼び出し時に）呼び出し、リターン時にそれがmsg_flagsから値を持っています。
The call returns the number of bytes received, or -1 if an error occurred. The variable errno is then set appropriately.
呼が受信されたバイト数を返し、エラーが起きた場合は-1。変数errnoが、その後適切に設定されています。
Many TCP and UDP implementations reserve port numbers below 1024 for privileged users. If the target platform supports privileged users, the SCTP implementation should restrict the ability to call bind() or sctp_bindx() on these port numbers to privileged users.
特権ユーザのための1024以下の多くのTCPとUDPの実装準備金のポート番号。ターゲットプラットフォームは、特権ユーザーをサポートしている場合、SCTPの実装は、特権ユーザーにこれらのポート番号にバインド（）またはと、sctp_bindx（）を呼び出す機能を制限する必要があります。
Similarly, unprivileged users should not be able to set protocol parameters that could result in the congestion control algorithm being more aggressive than permitted on the public Internet. These parameters are as follows:
同様に、非特権ユーザーは、輻輳制御アルゴリズムは、公共のインターネット上で許可さよりも攻撃的になる可能性がプロトコルパラメータを設定することはできないはず。次のようにこれらのパラメータは次のとおりです。
o struct sctp_rtoinfo
O構造体sctp_rtoinfo
If an unprivileged user inherits a one-to-many style socket with open associations on a privileged port, accepting new associations might be permitted, but opening new associations should not be permitted. This could be relevant for the r* family (rsh, rlogin, rwho, ...) of protocols.
特権のないユーザーが特権ポート上でオープン団体と1対多のスタイルのソケットを継承する場合は、新しい団体を受け入れることは許されるかもしれないが、開いて新しいアソシエーションは許可すべきではありません。これは、プロトコルのR *家族（RSH、rloginの、は、rwho、...）に関連する可能性があります。
Applications using the one-to-many style sockets and using the interleave level (if 0) are subject to denial-of-service attacks, as described in Section 8.1.20.
セクション8.1.20に記載されているように1対多スタイルソケットを使用し、（0の場合）インターリーブレベルを使用するアプリケーションは、サービス拒否攻撃の対象となっています。
Applications needing transport layer security can use Datagram Transport Layer Security/SCTP (DTLS/SCTP) as specified in [RFC6083]. This can be implemented using the sockets API described in this document.
[RFC6083]で指定されたトランスポート層のセキュリティはデータグラムトランスポート層セキュリティ/ SCTP（DTLS / SCTP）を使用することができます必要とするアプリケーション。これは、このドキュメントで説明するソケットAPIを使用して実装することができます。
Special acknowledgment is given to Ken Fujita, Jonathan Woods, Qiaobing Xie, and La Monte Yarroll, who helped extensively in the early formation of this document.
特別な承認は、このドキュメントの初期の形成に広範囲に役立ったケン・藤田、ジョナサン・ウッズ、Qiaobing謝、そしてラ・モンテYarrollに与えられています。
The authors also wish to thank Kavitha Baratakke, Mike Bartlett, Martin Becke, Jon Berger, Mark Butler, Thomas Dreibholz, Andreas Fink, Scott Kimble, Jonathan Leighton, Renee Revis, Irene Ruengeler, Dan Wing, and many others on the TSVWG mailing list for contributing valuable comments.
著者らはまた、TSVWGメーリングリストでKavitha Baratakke、マイク・バートレット、マーティン・ベッケ、ジョン・バージャー、マーク・バトラー、トーマスDreibholz、アンドレアス・フィンク、スコット・キンブル、ジョナサン・レイトン、レニーRevis、アイリーンRuengeler、ダン・ウィング、および多くの他に感謝したいです貴重なコメントを貢献するため。
A special thanks to Phillip Conrad, for his suggested text, quick and constructive insights, and most of all his persistent fighting to keep the interface to SCTP usable for the application programmer.
フィリップコンラッドへの特別な感謝は、彼の提案テキスト、迅速かつ建設的な洞察力、およびすべての彼の永続的な戦いのほとんどは維持するためのインタフェースは、アプリケーション・プログラマのための使用可能なSCTPします。
[IEEE-1003.1-2008] Institute of Electrical and Electronics Engineers, "Information Technology - Portable Operating System Interface (POSIX)", IEEE Standard 1003.1, 2008.
[IEEE-1003.1から2008]電気電子技術者協会、 "情報技術 - ポータブルオペレーティングシステムインタフェース（POSIX）"、IEEE標準1003.1、2008。
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
[RFC3493]ギリガン、R.、トムソン、S.、バウンド、J.、マッキャン、J.、およびW.スティーブンス、 "IPv6の基本的なソケットインタフェース拡張"、RFC 3493、2003年2月。
[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, May 2003.
"IPv6用の拡張ソケットアプリケーション・プログラム・インターフェース（API）" [RFC3542]スティーブンス、W.、トーマス、M.、Nordmarkと、E.、およびT.神明、RFC 3542、2003年5月。
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
[RFC3758]スチュワート、R.、Ramalho、M.、謝、Q.、Tuexen、M.、およびP.コンラッド、 "ストリーム制御伝送プロトコル（SCTP）部分的な信頼性拡張"、RFC 3758、2004年5月。
[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, "Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)", RFC 4895, August 2007.
[RFC4895] Tuexen、M.、スチュワート、R.、レイ、P.、およびE.レスコラ、 "ストリーム制御伝送プロトコル（SCTP）に対して認証チャンク"、RFC 4895、2007年8月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]スチュワート、R.、エド。、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, September 2007.
[RFC5061]スチュワート、R.、謝、Q.、Tuexen、M.、丸山、S.、およびM.小塚、 "ストリーム制御伝送プロトコル（SCTP）動的アドレス再構成"、RFC 5061、2007年9月。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC1644] Braden, R., "T/TCP -- TCP Extensions for Transactions Functional Specification", RFC 1644, July 1994.
[RFC1644]ブレーデン、R.、 "T / TCP - 取引機能仕様のためのTCP拡張機能"、RFC 1644、1994年7月。
[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)", RFC 6083, January 2011.
[RFC6083] Tuexen、M.、Seggelmann、R.、およびE.レスコラ、RFC 6083、2011年1月、 "ストリーム制御伝送プロトコル（SCTP）のためのデータグラムトランスポート層セキュリティ（DTLS）"。
[RFC6247] Eggert, L., "Moving the Undeployed TCP Extensions RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, and RFC 1693 to Historic Status", RFC 6247, May 2011.
[RFC6247]エッゲルト、L.、 "歴史的な状態へのアンデプロイTCP拡張機能RFC 1072、RFC 1106、RFC 1110、RFC 1145、RFC 1146、RFC 1379、RFC 1644、およびRFC 1693の移動"、RFC 6247、2011年05月。
Appendix A. Example Using One-to-One Style Sockets
付録A.例1対1のスタイルのソケットを使用して
The following code is an implementation of a simple client that sends a number of messages marked for unordered delivery to an echo server making use of all outgoing streams. The example shows how to use some features of one-to-one style IPv4 SCTP sockets, including
次のコードは、すべての発信ストリームを利用して、エコーサーバへの順不同の配信のためにマークされたメッセージの数を送信単純なクライアントの実装です。例には、1対1スタイルのIPv4 SCTPソケットの一部の機能を使用する方法を示しています
o Creating and connecting an SCTP socket.
SCTPソケットを作成し、接続するO。
o Making a request to negotiate a number of outgoing streams.
送信ストリーム数を交渉する要求を行うO。
o Determining the negotiated number of outgoing streams.
送信ストリームのネゴシエートされた数を決定O。
o Setting an adaptation layer indication.
アダプテーション層の指標を設定O。
o Sending messages with a given payload protocol identifier on a particular stream using sctp_sendv().
sctp_sendvを使用して特定のストリーム上で与えられたペイロード・プロトコル識別子を有するメッセージを送信O（）。
<CODE BEGINS>
/*
Copyright (c) 2011 IETF Trust and the persons identified as authors of the code. All rights reserved.
著作権（C）2011 IETF信託コードの作者として特定の人物。全著作権所有。
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info).
、に基づき許可されており、中に含まれるライセンス条項に従う、簡体BSDライセンスは、IETFドキュメントに関連IETFトラストの法律規定（のセクション4.Cに記載されている変更の有無にかかわらず、ソースおよびバイナリ形式での再配布および使用http://trustee.ietf.org/license-info）。
*/
＊／
#include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <netinet/sctp.h> #include <arpa/inet.h> #include <string.h> #include <stdio.h> #include <unistd.h> #include <stdlib.h>
#includeは<sys / types.h>にする#includeは<sys / socket.h>にする#include <netinetの/ in.h>の#include <netinetの/ sctp.h>の#include <ARPA / inet.h>の#include <ストリング。 H>の#include <stdio.hに>する#include <unistd.h>の#include <STDLIB.H>
#define PORT 9
#define ADDR "127.0.0.1"
#define SIZE_OF_MESSAGE 1000
#define NUMBER_OF_MESSAGES 10
#define PPID 1234 int
main(void) {
unsigned int i;
int sd;
struct sockaddr_in addr;
char buffer[SIZE_OF_MESSAGE];
struct iovec iov;
struct sctp_status status;
struct sctp_initmsg init;
struct sctp_sndinfo info;
struct sctp_setadaptation ind;
socklen_t opt_len;
/* Create a one-to-one style SCTP socket. */
if ((sd = socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP)) < 0) {
perror("socket");
exit(1);
}
/* Prepare for requesting 2048 outgoing streams. */
memset(&init, 0, sizeof(init));
init.sinit_num_ostreams = 2048;
if (setsockopt(sd, IPPROTO_SCTP, SCTP_INITMSG,
&init, (socklen_t)sizeof(init)) < 0) {
perror("setsockopt");
exit(1);
}
ind.ssb_adaptation_ind = 0x01020304;
if (setsockopt(sd, IPPROTO_SCTP, SCTP_ADAPTATION_LAYER,
&ind, (socklen_t)sizeof(ind)) < 0) {
perror("setsockopt");
exit(1);
}
/* Connect to the discard server. */
memset(&addr, 0, sizeof(addr));
#ifdef HAVE_SIN_LEN
addr.sin_len = sizeof(struct sockaddr_in);
#endif
addr.sin_family = AF_INET;
addr.sin_port = htons(PORT);
addr.sin_addr.s_addr = inet_addr(ADDR);
if (connect(sd,
(const struct sockaddr *)&addr,
sizeof(struct sockaddr_in)) < 0) {
perror("connect");
exit(1);
}
/* Get the actual number of outgoing streams. */
memset(&status, 0, sizeof(status));
opt_len = (socklen_t)sizeof(status);
if (getsockopt(sd, IPPROTO_SCTP, SCTP_STATUS,
&status, &opt_len) < 0) {
perror("getsockopt");
exit(1);
}
memset(&info, 0, sizeof(info));
info.snd_ppid = htonl(PPID);
info.snd_flags = SCTP_UNORDERED;
memset(buffer, 'A', SIZE_OF_MESSAGE);
iov.iov_base = buffer;
iov.iov_len = SIZE_OF_MESSAGE;
for (i = 0; i < NUMBER_OF_MESSAGES; i++) {
info.snd_sid = i % status.sstat_outstrms;
if (sctp_sendv(sd,
(const struct iovec *)&iov, 1,
NULL, 0,
&info, sizeof(info), SCTP_SENDV_SNDINFO,
0) < 0) {
perror("sctp_sendv");
exit(1);
}
}
if (close(sd) < 0) {
perror("close");
exit(1);
}
return(0);
}
<CODE ENDS>
Appendix B. Example Using One-to-Many Style Sockets
付録B.例一対多スタイルのソケットを使用して
The following code is a simple implementation of a discard server over SCTP. The example shows how to use some features of one-to-many style IPv6 SCTP sockets, including
次のコードは、SCTPを超える廃棄サーバーの単純な実装です。例には、1対多のスタイルのIPv6 SCTPソケットの一部の機能を使用する方法を示しています
o Opening and binding of a socket.
オープニングとソケットの結合、O。
o Enabling notifications.
O通知を有効にします。
o Handling notifications.
O通知を取り扱い。
o Configuring the auto-close timer.
O自動クローズタイマーを設定します。
o Using sctp_recvv() to receive messages.
sctp_recvvを使用してO（）メッセージを受信します。
Please note that this server can be used in combination with the client described in Appendix A.
このサーバは、付録Aで説明したクライアントと組み合わせて使用することができることに注意してください
<CODE BEGINS>
/*
Copyright (c) 2011 IETF Trust and the persons identified as authors of the code. All rights reserved.
著作権（C）2011 IETF信託コードの作者として特定の人物。全著作権所有。
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info).
、に基づき許可されており、中に含まれるライセンス条項に従う、簡体BSDライセンスは、IETFドキュメントに関連IETFトラストの法律規定（のセクション4.Cに記載されている変更の有無にかかわらず、ソースおよびバイナリ形式での再配布および使用http://trustee.ietf.org/license-info）。
*/
＊／
#include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <netinet/sctp.h> #include <arpa/inet.h> #include <string.h> #include <stdio.h> #include <stdlib.h> #include <unistd.h>
#includeは<sys / types.h>にする#includeは<sys / socket.h>にする#include <netinetの/ in.h>の#include <netinetの/ sctp.h>の#include <ARPA / inet.h>の#include <ストリング。 H>の#include <stdio.hに>する#include <STDLIB.H>する#include <unistd.h>
#define BUFFER_SIZE (1<<16)
#define PORT 9
#define ADDR "0.0.0.0"
#define TIMEOUT 5 static void
print_notification(void *buf)
{
struct sctp_assoc_change *sac;
struct sctp_paddr_change *spc;
struct sctp_adaptation_event *sad;
union sctp_notification *snp;
char addrbuf[INET6_ADDRSTRLEN];
const char *ap;
struct sockaddr_in *sin;
struct sockaddr_in6 *sin6;
snp = buf;
SNP = BUF。
switch (snp->sn_header.sn_type) {
case SCTP_ASSOC_CHANGE:
sac = &snp->sn_assoc_change;
printf("^^^ Association change: ");
switch (sac->sac_state) {
case SCTP_COMM_UP:
printf("Communication up (streams (in/out)=(%u/%u)).\n",
sac->sac_inbound_streams, sac->sac_outbound_streams);
break;
case SCTP_COMM_LOST:
printf("Communication lost (error=%d).\n", sac->sac_error);
break;
case SCTP_RESTART:
printf("Communication restarted (streams (in/out)=(%u/%u).\n",
sac->sac_inbound_streams, sac->sac_outbound_streams);
break;
case SCTP_SHUTDOWN_COMP:
printf("Communication completed.\n");
break;
case SCTP_CANT_STR_ASSOC:
printf("Communication couldn't be started.\n");
break;
default:
printf("Unknown state: %d.\n", sac->sac_state);
break;
}
break;
case SCTP_PEER_ADDR_CHANGE:
spc = &snp->sn_paddr_change;
if (spc->spc_aaddr.ss_family == AF_INET) {
sin = (struct sockaddr_in *)&spc->spc_aaddr;
ap = inet_ntop(AF_INET, &sin->sin_addr,
addrbuf, INET6_ADDRSTRLEN);
} else {
sin6 = (struct sockaddr_in6 *)&spc->spc_aaddr;
ap = inet_ntop(AF_INET6, &sin6->sin6_addr,
addrbuf, INET6_ADDRSTRLEN);
}
printf("^^^ Peer Address change: %s ", ap);
switch (spc->spc_state) {
case SCTP_ADDR_AVAILABLE:
printf("is available.\n");
break;
case SCTP_ADDR_UNREACHABLE:
printf("is not available (error=%d).\n", spc->spc_error);
break;
case SCTP_ADDR_REMOVED:
printf("was removed.\n");
break;
case SCTP_ADDR_ADDED:
printf("was added.\n");
break;
case SCTP_ADDR_MADE_PRIM:
printf("is primary.\n");
break;
default:
printf("unknown state (%d).\n", spc->spc_state);
break;
}
break;
case SCTP_SHUTDOWN_EVENT:
printf("^^^ Shutdown received.\n");
break;
case SCTP_ADAPTATION_INDICATION:
sad = &snp->sn_adaptation_event;
printf("^^^ Adaptation indication 0x%08x received.\n",
sad->sai_adaptation_ind);
break;
default:
printf("^^^ Unknown event of type: %u.\n",
snp->sn_header.sn_type);
break;
};
} int
main(void) {
int sd, flags, timeout, on;
ssize_t n;
unsigned int i;
union {
struct sockaddr sa;
struct sockaddr_in sin;
struct sockaddr_in6 sin6;
} addr;
socklen_t fromlen, infolen;
struct sctp_rcvinfo info;
unsigned int infotype;
struct iovec iov;
char buffer[BUFFER_SIZE];
struct sctp_event event;
uint16_t event_types[] = {SCTP_ASSOC_CHANGE,
SCTP_PEER_ADDR_CHANGE,
SCTP_SHUTDOWN_EVENT,
SCTP_ADAPTATION_INDICATION};
/* Create a one-to-many style SCTP socket. */
if ((sd = socket(AF_INET6, SOCK_SEQPACKET, IPPROTO_SCTP)) < 0) {
perror("socket");
exit(1);
}
/* Enable the events of interest. */
memset(&event, 0, sizeof(event));
event.se_assoc_id = SCTP_FUTURE_ASSOC;
event.se_on = 1;
for (i = 0; i < sizeof(event_types)/sizeof(uint16_t); i++) {
event.se_type = event_types[i];
if (setsockopt(sd, IPPROTO_SCTP, SCTP_EVENT,
&event, sizeof(event)) < 0) {
perror("setsockopt");
exit(1);
}
}
/* Configure auto-close timer. */
timeout = TIMEOUT;
if (setsockopt(sd, IPPROTO_SCTP, SCTP_AUTOCLOSE,
&timeout, sizeof(timeout)) < 0) {
perror("setsockopt SCTP_AUTOCLOSE");
exit(1);
}
/* Enable delivery of SCTP_RCVINFO. */
on = 1;
if (setsockopt(sd, IPPROTO_SCTP, SCTP_RECVRCVINFO,
&on, sizeof(on)) < 0) {
perror("setsockopt SCTP_RECVRCVINFO");
exit(1);
}
/* Bind the socket to all local addresses. */
memset(&addr, 0, sizeof(addr));
#ifdef HAVE_SIN6_LEN
addr.sin6.sin6_len = sizeof(addr.sin6);
#endif
addr.sin6.sin6_family = AF_INET6;
addr.sin6.sin6_port = htons(PORT);
addr.sin6.sin6_addr = in6addr_any;
if (bind(sd, &addr.sa, sizeof(addr.sin6)) < 0) {
perror("bind");
exit(1);
}
/* Enable accepting associations. */
if (listen(sd, 1) < 0) {
perror("listen");
exit(1);
}
for (;;) {
flags = 0;
memset(&addr, 0, sizeof(addr));
fromlen = (socklen_t)sizeof(addr);
memset(&info, 0, sizeof(info));
infolen = (socklen_t)sizeof(info);
infotype = 0;
iov.iov_base = buffer;
iov.iov_len = BUFFER_SIZE;
n = sctp_recvv(sd, &iov, 1, &addr.sa, &fromlen, &info, &infolen, &infotype, &flags);
N = sctp_recvv（SD＆IOV、1、＆addr.sa、＆fromlen、＆情報、＆infolen、および情報のタイプ、およびフラグ）。
if (flags & MSG_NOTIFICATION) {
print_notification(iov.iov_base);
} else {
char addrbuf[INET6_ADDRSTRLEN];
const char *ap;
in_port_t port;
if (addr.sa.sa_family == AF_INET) {
ap = inet_ntop(AF_INET, &addr.sin.sin_addr,
addrbuf, INET6_ADDRSTRLEN);
port = ntohs(addr.sin.sin_port);
} else {
ap = inet_ntop(AF_INET6, &addr.sin6.sin6_addr,
addrbuf, INET6_ADDRSTRLEN);
port = ntohs(addr.sin6.sin6_port);
}
printf("Message received from %s:%u: len=%d",
ap, port, (int)n);
switch (infotype) {
case SCTP_RECVV_RCVINFO:
printf(", sid=%u", info.rcv_sid);
if (info.rcv_flags & SCTP_UNORDERED) {
printf(", unordered");
} else {
printf(", ssn=%u", info.rcv_ssn);
}
printf(", tsn=%u", info.rcv_tsn);
printf(", ppid=%u.\n", ntohl(info.rcv_ppid));
break;
case SCTP_RECVV_NOINFO:
case SCTP_RECVV_NXTINFO:
case SCTP_RECVV_RN:
printf(".\n");
break;
default:
printf(" unknown infotype.\n");
}
}
}
if (close(sd) < 0) {
perror("close");
exit(1);
}
return (0); } <CODE ENDS>
リターン（0）。 } <CODEを終了します>
Authors' Addresses
著者のアドレス
Randall R. Stewart Adara Networks Chapin, SC 29036 USA
ランドールR.スチュワートアダラネットワークチャピン、SC 29036 USA
EMail: randall@lakerest.net
メールアドレス：randall@lakerest.net
Michael Tuexen Muenster University of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt Germany
応用科学StegerwaldstrのマイケルTuexenミュンスター大学。 39 48565シュタインフルトドイツ
EMail: tuexen@fh-muenster.de
メールアドレス：tuexen@fh-muenster.de
Kacheong Poon Oracle Corporation
Kacheomは、Oracle Corporationの賭け
EMail: ka-cheong.poon@oracle.com
メールアドレス：ka-cheong.poon@oracle.com
Peter Lei Cisco Systems, Inc. 9501 Technology Blvd. West Office Center Rosemont, IL 60018 USA
ピーター・レイシスコシステムズ株式会社9501テクノロジー・ブルバードウェスト・オフィスセンターローズモント、IL 60018 USA
EMail: peterlei@cisco.com
メールアドレス：peterlei@cisco.com
Vladislav Yasevich HP 110 Spitrook Rd. Nashua, NH 03062 USA
ウラジスラフYasevich HP 110 Spitrook Rdを。ナシュア、ニューハンプシャー03062 USA
EMail: vladislav.yasevich@hp.com
メールアドレス：vladislav.yasevich@hp.com