[要約] RFC 6458は、SCTPのためのソケットAPI拡張に関する規格です。このRFCの目的は、SCTPをサポートするためのソケットAPIの拡張を提供することです。
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)
ストリーム制御伝送プロトコル（SCTP）のSocketsAPI拡張機能
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.
このドキュメントでは、ストリーム制御伝送プロトコル（SCTP）のソケットAPIへのマッピングについて説明します。このマッピングの利点には、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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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.
Sockets APIは、多くのオペレーティングシステムにインターネットプロトコルスイートの標準マッピングを提供しています。TCP [RFC0793]とUDP [RFC0768]の両方が、多くの多様なプラットフォームにわたるこの標準的な表現とアクセス方法の恩恵を受けています。SCTPは、TCPの特性の多くを提供するが、UDPに似たセマンティクスも組み込まれている新しいプロトコルです。このドキュメントでは、既存のソケットAPIをSCTPで使用するためにマッピングする方法を定義し、ほとんどの既存のTCPアプリケーションを変更して（もしあれば）変更されてSCTPに移行できるように、新機能へのアクセスと互換性の両方のベースを提供します。
There are three basic design objectives:
3つの基本的な設計目標があります。
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との一貫性を維持します。他のソケットAPIプロトコルマッピング（たとえばUDP、TCP、IPv4、IPv6）と一致する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
2. 1対多スタイルのインターフェイスをサポート：このセマンティクスのセットは、UDPなどのコネクションレスプロトコルで定義されているセマンティクスと類似しています。1対多くのスタイルのSCTPソケットは、複数のSCTP関連を制御できるはずです。これは、多くのピアエンドポイントと通信できるUDPソケットに似ています。これらのそれぞれの関連付けには、関連する識別子が割り当てられているため、
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.
アプリケーションは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ソケットは、1つのSCTPアソシエーションのみを制御する必要があります。このインターフェイスを定義する目的の1つは、他の接続指向のプロトコルに基づいて構築された既存のアプリケーションを、ほとんど努力せずにSCTPを使用するように移植できるようにすることです。これらのセマンティクスに精通している開発者は、SCTPに簡単に適応できます。別の目的は、Select（）などのソケットをサポートするほとんどのオペレーティングシステムの既存のメカニズムが、このスタイルのソケットで引き続き動作し続けることを確認することです。このマッピングに拡張機能が追加され、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対多スタイルのマッピングと1対1のスタイルマッピング、つまり1対1のスタイルマッピングの2つのマッピングモードを定義します。これらの2つのモードは、いくつかの一般的なデータ構造と操作を共有していますが、2つの異なるアプリケーションプログラミングスタイルを使用する必要があります。すべての新しいSCTP機能は、両方のスタイルのソケットで使用できることに注意してください。使用する決定は、主にアプリケーションの性質に依存します。
A mechanism is defined to extract an SCTP association from a one-to-many style socket into a one-to-one style socket.
メカニズムは、1対多様なスタイルのソケットから1対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()
o 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()
o 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
このスタイルでは、デフォルトでは、エンドポイントに接続されているすべての関連付けが単一のソケットで表されます。各関連付けには、アソシエーション識別子（タイプはsctp_assoc_t）が割り当てられているため、アプリケーションが使用してそれらを区別できるようにします。いくつかの実装では、ピアエンドポイントのアドレスをこの目的に使用することもできます。しかし、これはパフォーマンス上の理由で必要ありません。もしも
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.
実装では、アドレスを使用して異なる関連性を区別することはサポートされていません。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.
Association Identifierが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（）およびsend（）関数で使用できる新しい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.
1対多くのスタイルのソケットコールについては、以下のサブセクションで詳細に説明します。
Applications use socket() to create a socket descriptor to represent an SCTP endpoint.
アプリケーションはSocket（）を使用してSCTPエンドポイントを表すソケット記述子を作成します。
The function prototype is
関数プロトタイプはです
int socket(int domain, int type, int protocol);
int socket（int domain、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_INETドメインを使用すると、IPv4アドレスのみを使用できるエンドポイントの作成が示され、PF_INET6はIPv6アドレスとIPv4アドレスの両方を使用できるエンドポイントを作成します。
Applications use bind() to specify with which local address and port the SCTP endpoint should associate itself.
アプリケーションはbind（）を使用して、どのローカルアドレスと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に導入して、アプリケーションが複数のアドレスを関連付ける仕事をするのを支援します。ただし、エンドポイントは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).
bind（）を呼び出した後、エンドポイントがソケットの新しい関連付けを受け入れたい場合は、聴取（）を呼び出す必要があります（セクション3.1.3を参照）。
The function prototype of bind() is
bind（）の関数プロトタイプはです
int bind(int sd, struct sockaddr *addr, socklen_t addrlen);
int bind（int sd、struct 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：アドレス構造（IPv4アドレスのstruct sockaddr_inまたはipv6アドレスのstruct sockaddr_in6; [rfc3493]を参照）。
addrlen: The size of the address structure.
Addrlen：アドレス構造のサイズ。
bind() returns 0 on success and -1 in case of an error.
bind（）は、エラーが発生した場合に成功して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.
アプリケーションは、複数のアドレスをエンドポイントに関連付けるためにBind（）を複数回呼び出すことはできません。bind（）の最初の呼び出しの後、後続の呼び出しはすべてエラーを返します。
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アドレスの場合はINADDR_ANY、またはIN6ADDR_ANY_INITまたはIPv6アドレスのIN6ADDR_ANYとして指定されている場合、オペレーティングシステムはエンドポイントを利用可能なインターフェイスの最適なアドレスセットに関連付けます。IPv4 SIN_PORTまたはIPv6 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.
bind（）がsendmsg（）コールの前に呼び出されない場合、新しい関連付けを開始すると、システムは一時的なポートを選択し、ワイルドカードアドレスとのバインディングに相当するアドレスセットを選択します。これらのアドレスの1つは、協会の主要な住所になります。これにより、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.
このbind（）プロセスの完了により、SCTPエンドポイントがインバウンドSCTP関連要求を受け入れることはできません。以下で説明するListen（）システムコールがソケットで実行されるまで、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対Manyスタイルのソケットは、新しい関連付けのリクエストを受け入れません。アプリケーションは、聴取（）を使用して、ソケットを新しい関連付けを受け入れることができるとマークします。
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
1対多スタイルのソケット消費者は、新しい関連付けを取得するためにaccept（）を呼び出す必要はないことに注意してください。1対多スタイルのソケットでaccept（）を呼び出す必要があります。むしろ、新しい関連付けは自動的に受け入れられ、新しい協会の通知はsctp_assoc_changeイベントでrecvmsg（）を介して配信されます（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.
これらの通知が有効になります）。通常、クライアントはlisten（）を呼び出しないため、ソケットで積極的に開始された関連性のみが可能であることを保証できます。一方、サーバーまたはピアツーピアのソケットは常に新しい関連付けを受け入れます。そのため、サーバーを使用したよく書かれたアプリケーションを1対Manyスタイルのソケットを使用して、不要なピアからの新しい関連付けを処理する必要があります。
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 struct msghdr *message、int flags）;
and
と
ssize_t recvmsg(int sd, struct msghdr *message, int flags);
ssize_t recvmsg（int sd、struct msghdr *message、int flags）;
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フィールドは、意図した受信機の輸送アドレスの1つで満たされます。送信者と意図したレシーバーの間に既存の関連付けがない場合、送信者のSCTPスタックは新しい関連付けをセットアップし、ユーザーデータを送信します（暗黙的な関連付けのセットアップの詳細については、セクション7.5を参照）。sendmsg（）がデータなしで呼び出され、既存の関連付けがない場合、新しい関連性が確立されます。SCTP_INITタイプの補助データを使用して、新しい関連付けを設定するために使用されるパラメーターの一部を変更できます。sendmsg（）がnullデータで呼び出され、既存の関連性がない場合、sctp_abortまたはsctp_eofフラグがセクション5.3.4で説明されているように設定されている場合、-1が返され、errnoがeinvalに設定されます。sendmsg（）を使用してメッセージを送信すると、SDで指定されたソケットで明示的な終了（EOR）マーキングが有効になっていない限り、原子は原子です（セクション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.
ピアがシャットダウンを送信した場合、その通知が有効になった場合、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のスタイルソケットの両方でメッセージのインターレースが発生するもののさまざまな側面を制御します。メッセージ配信オプションの詳細については、セクション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.
アプリケーションはclose（）を使用して、現在1対多様なスタイルソケットで表されているすべての関連付けで、優雅なシャットダウン（[RFC4960]のセクション10.1で説明されているように）を実行します。
The function prototype is
関数プロトタイプはです
int close(int sd);
int close（int sd）;
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.
1対多スタイルのソケットに代表される特定の関連付けを優雅にシャットダウンするには、アプリケーションは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.
Close（）のSDが1つの関連付けのみを表す分岐ソケットである場合、その関連付けのみでシャットダウンが実行されます。
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 connect（int sd、const struct sockaddr *nam、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]).
NAM：アドレス構造（IPv4アドレスのstruct sockaddr_inまたはipv6アドレスのstruct sockaddr_in6; [rfc3493]を参照）。
len: The size of the address.
レン：アドレスのサイズ。
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ソケットのConnect（）のセマンティクスとは異なります。
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は、Associationセットアップフェーズ中に、T/TCP [RFC1644]（[RFC6247]によって歴史的に作られた）と同様に、データ交換を許可することに注意してください。アプリケーションがこれを行いたい場合、Connect（）呼び出しを使用できません。代わりに、sendto（）またはsendmsg（）を使用して関連を開始する必要があります。sendto（）を使用し、初期化の動作を変更したい場合、sendto（）を呼び出す前にsctp_initmsgソケットオプションを使用する必要があります。または、SCTP_INITタイプの補助データを使用してsendmsg（）を使用して、SetSockopt（）を呼び出すことなく関連性を開始できます。暗黙のセットアップは、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は、半分のセマンティクスをサポートしていません。これは、T/TCPとは異なり、接続を開始するために呼び出しを使用してもsend（）またはsendmsg（）を呼び出すときに、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
bind（）コールおよび/またはその後のsctp_bindx（）呼び出しが1対多様なスタイルソケットで完了すると、アプリケーションはfcntl（）（o_nonblockなど）を介して非ブロッキングオプションを設定する場合があります。ソケットを非ブロッキングモードに設定した後、sendmsg（）関数はすぐに戻ります。データメッセージの送信の成功または失敗（SCTP_INITMSGの補助データの可能性）は、sctp_assoc_changeイベントによってsctp_comm_upまたはsctp_cant_start_assocを使用してシグナルが表示されます。ユーザーデータを送信できなかった場合（sctp_cant_start_assocのため）、送信者はsctp_send_failed_eventイベントも受け取ります。イベントは、ユーザーがrecvmsg（）を呼び出すことで受信できます。サーバー（聞き（）と呼ばれる）も
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_assoc_changeを受信してsctp_comm_upを使用してsctp_assoc_changeを受信して、recvmsg（）の呼び出しと、おそらく最初のデータメッセージの受信を介して通知されます。
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.
アソシエーションを優雅にシャットダウンするには、ユーザーは、セクション5.3.4で説明されているように、データなしとSCTP_EOFフラグを使用してsendmsg（）を呼び出す必要があります。関数はすぐに戻り、優雅なシャットダウンの完了は、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.
select（またはpoll（））を使用する場合は、1対多様なスタイルソケットに書き込む場合は、select（）を作成する場合は注意を払うことをお勧めします。一般的に、書き込みのselect（）の正のリターンは、1対多スタイルのソケットで表される関連の1つが書き込み可能であることを示しているだけです。select（）リターンの後に書き込むアプリケーションは、書き込み可能な協会は書き込みコールの宛先協会ではないため、まだブロックされる場合があります。同様に、1対多様なスタイルソケットから読み取りのためのselect（またはpoll（））は、ソケットで表される関連付けの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のスタイルを使用するか、sctp_peeloff（）関数（セクション9.2を参照）を使用して、対象の関連性を1対1で分離する必要があります。多くのスタイルソケット。
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対多スタイルのソケットの特定の関連付けの選択を許可する可能性のあるepollや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.
SCTPがTCPと共有する重要な機能は、フロー制御です。具体的には、送信者はレシーバーが消費できるよりも速くデータを送信することはできません。
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でフロー制御が提供されます。読者が読み取りを停止した場合、送信者ソケットバッファーが完全に満たされるまで、送信者がソケット層のメッセージをキューにキューします。これにより、「停止接続」になります。ソケットに書き込みのさらなる試行では、非ブロッキングソケットのエラーまたは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.
1対1のスタイルのSCTPソケットの場合（これには、SCTP_PEELOFF（）を使用した1対多様なスタイルソケットから分離されたソケット記述子が含まれます）、動作は同一です。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 1対1のスタイルソケットを使用して、潜在的に失速する可能性があります（最初から、または停止状態を引き起こす可能性のある大量のデータを送信する前にsctp_peeloff（）を使用して）。
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ソケットと同様に、1対1のスタイルソケットを最大で（明示的にまたは暗黙的に）接続できます。
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.
Accept（）コールは、新しい関連付けが設定されるまでブロックします。新しいソケット記述子で戻ります。サーバーは、新しいソケット記述子を使用してクライアントと通信し、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（）callから返すと、クライアントはsend（）/ 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.
アプリケーションはSocket（）を呼び出してSCTPエンドポイントを表すソケット記述子を作成します。
The function prototype is
関数プロトタイプはです
int socket(int domain, int type, int protocol);
int socket（int domain、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_INETドメインを使用すると、IPv4アドレスのみを使用できるエンドポイントの作成が示され、PF_INET6はIPv6アドレスとIPv4アドレスの両方を使用できるエンドポイントを作成します。
Applications use bind() to specify with which local address and port the SCTP endpoint should associate itself.
アプリケーションはbind（）を使用して、どのローカルアドレスと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に導入して、アプリケーションが複数のアドレスを関連付ける仕事をするのを支援します。ただし、エンドポイントは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
bind（）の関数プロトタイプはです
int bind(int sd, struct sockaddr *addr, socklen_t addrlen);
int bind（int sd、struct 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：アドレス構造（IPv4アドレスのstruct sockaddr_inまたはipv6アドレスのstruct sockaddr_in6; [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.
アプリケーションは、複数のアドレスをエンドポイントに関連付けるためにBind（）を複数回呼び出すことはできません。bind（）の最初の呼び出しの後、後続の呼び出しはすべてエラーを返します。
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アドレスの場合はINADDR_ANY、またはIN6ADDR_ANY_INITまたはIPv6アドレスのIN6ADDR_ANYとして指定されている場合、オペレーティングシステムはエンドポイントを利用可能なインターフェイスの最適なアドレスセットに関連付けます。IPv4 SIN_PORTまたはIPv6 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.
bind（）がconnect（）呼び出しの前に呼び出されない場合、システムは一時的なポートを選択し、ワイルドカードアドレスとのバインディングに相当するアドレスセットを選択します。これらのアドレスの1つは、協会の主要なアドレスになります。これにより、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.
このbind（）プロセスの完了により、SCTPエンドポイントがインバウンドSCTP関連要求を受け入れることはできません。以下で説明するListen（）システムコールがソケットで実行されるまで、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.
バックログ：ソケットの受け入れキューで許可されている傑出した関連付けの最大数を指定します。これらは、4方向の開始握手を終えた協会（[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.
アプリケーションは、Accept（）呼び出しを使用して、エンドポイントのAccept Queueから確立されたSCTPアソシエーションを削除します。新たに形成された関連付けを表すために、新しいソケット記述子がAccept（）から返されます。
The function prototype is
関数プロトタイプはです
int accept(int sd, struct sockaddr *addr, socklen_t *addrlen);
int accept（int sd、struct 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（IPv4アドレスのstruct sockaddr_inまたはIPv6アドレスのstruct sockaddr_in6; [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.
この関数は、エラーが発生した場合、成功に関する新たに形成された関連付けのソケット記述子を返します。
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 connect（int sd、const struct 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：PEER'S（IPv4アドレスのStruct Sockaddr_inまたはIPv6アドレスのStruct Sockaddr_in6; [RFC3493]を参照）アドレス。
addrlen: The size of the address.
Addrlen：アドレスのサイズ。
connect() returns 0 on success and -1 on error.
connect（）は成功で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.
bind（）がconnect（）呼び出しの前に呼び出されない場合、システムは一時的なポートを選択し、IPv4およびIPv6ソケットのINADDR_ANYおよびIN6ADDR_ANY_INITとのバインディングに相当するアドレスセットを選択します。アドレスの1つは、協会の主要なアドレスになります。これにより、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は、Associationセットアップフェーズ中に、T/TCP [RFC1644]（[RFC6247]によって歴史的に作られた）と同様に、データ交換を許可することに注意してください。アプリケーションがこれを行いたい場合、Connect（）呼び出しを使用できません。代わりに、sendto（）またはsendmsg（）を使用して関連を開始する必要があります。sendto（）を使用し、初期化の動作を変更したい場合、sendto（）を呼び出す前にsctp_initmsgソケットオプションを使用する必要があります。または、SCTP_INITタイプの補助データを使用してsendmsg（）を使用して、SetSockopt（）を呼び出すことなく関連性を開始できます。暗黙のセットアップは、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は、半分のセマンティクスをサポートしていません。これは、T/TCPとは異なり、接続を開始するために呼び出しを使用してもsend（）またはsendmsg（）を呼び出すときに、MSG_EOFをFlagsパラメーターに設定しないことを意味します。MSG_EOFは、SCTPソケットを備えた許容フラグではありません。
Applications use close() to gracefully close down an association.
アプリケーションはclose（）を使用して、関連性を優雅に閉じます。
The function prototype is
関数プロトタイプはです
int close(int sd);
int close（int sd）;
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.
close（）は、エラーが発生した場合に成功で0を返し、-1を返します。
After an application calls close() on a socket descriptor, no further socket operations will succeed on that descriptor.
アプリケーションがソケット記述子にclose（）を呼び出すと、その記述子ではそれ以上のソケット操作は成功しません。
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のShutdown（）呼び出しはTCP Shutdown（）呼び出しの近似であり、いくつかの異なる問題を解決します。完全なTCP互換性は提供されていないため、SCTPにTCPアプリケーションを移植する開発者は、Shutdown（）を使用してセクションを再コーディングする必要がある場合があります。（SCTPストリームを使用してSCTPでハーフクローズと同じ結果を達成することが可能であることに注意してください。）
The function prototype is
関数プロトタイプはです
int shutdown(int sd, int how);
int shutdown（int sd、int how）;
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.
shutdown（）は、エラーが発生した場合に成功して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 Shutdown（）の主な違いは、SCTP Shut_WRが即時および完全なプロトコルシャットダウンを開始するのに対し、TCP Shut_WRはTCPがハーフクローズ状態に入ることです。SHUT_RDは、TCPと同じように同じように動作します。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で説明されている中止操作を実行するには、アプリケーションはソケットオプション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:
1対1のスタイルソケットを使用すると、アプリケーションはsendmsg（）とrecvmsg（）を使用して、ピアからデータを送信してデータを受信することもできます。セマンティクスは、1対多様なスタイルで使用されているものと似ています（セクション3.1.4を参照）、次の違いがあります。
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の実装に応じて、暗黙の接続セットアップのために、接続されていない1対1のスタイルソケットで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、struct 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.
アドレスの実際の長さが供給されたソッカドドル構造の長さよりも大きい場合、保存されたアドレスが切り捨てられます。
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に固有の重要なデータ構造について説明し、SCTPエンドポイント操作を制御し、補助情報と通知にアクセスするために、sendmsg（）およびrecvmsg（）呼び出しで使用されます。
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（）およびrecvmsg（）呼び出しで使用されるMSGHDR構造、および構造に掲載された補助データは、アプリケーションが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().
散布/収集バッファー、またはI/Oベクトル（MSG_IOVフィールドが指す）は、SCTPによってSENDMSG（）と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_CONTROLフィールド）を使用して、MSG_IOVに格納されているメッセージのSCTP_RCVINFOなどの属性をソケットエンドポイントに通信します。さまざまな補助データ型については、セクション5.3で説明します。
The msg_flags are not used when sending a message with sendmsg().
msg_flagsは、sendmsg（）でメッセージを送信するときに使用されません。
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アイテム、非SCTPアイテム（IPレベルアイテムなど）、またはその両方が含まれます。
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（）呼び出しに対して、このようなタイプの補助データは1つだけです。
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:
実装には補助データのパディング要件が異なる場合があるため、ポータブルアプリケーションはMacroS CMSG_FIRSTHDR、CMSG_NXTHDR、CMSG_DATA、CMSG_SPACE、およびCMSG_LENを利用する必要があります。詳細については、[RFC3542]およびSCTP実装のドキュメントを参照してください。以下は、[RFC3542]の例であり、これらのマクロの使用が補助データにアクセスすることを示しています。
struct msghdr msg; struct cmsghdr *cmsgptr;
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（）に渡すために必要な最大バッファサイズを決定的に計算できることが不可欠です。これを可能にするこの仕様に課される制約の1つは、すべての補助データ定義が固定された長さであることです。必要な最大バッファサイズを計算する1つの方法は、CMSG_SPACEで計算されるように、すべての有効な補助データアイテム構造のサイズの合計を取ることです。たとえば、sctp_sndrcv_infoとipv6_recvpktinfo [rfc3542]を有効にした場合、次のようにバッファサイズを計算して割り当てます。
size_t total; void *buf;
size_t合計;void *buf;
total = CMSG_SPACE(sizeof(struct sctp_sndrcvinfo)) +
CMSG_SPACE(sizeof(struct in6_pktinfo));
buf = malloc(total);
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.
その後、各呼び出しでmsg_controlにこのバッファ（buf）をrecvmsg（）に使用し、補助的なデータを切り捨てないことを保証できます。
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固有のソケット拡張機能の重要な要素は、sendmsg（）およびrecvmsg（）で使用されるMSGHDR構造のMSG_CONTROLメンバーを介して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 []メンバーに含まれるデータの関数と目的を定義するstruct 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を参照してください。これらのデータ構造は、struct sockaddr_storage（[rfc3493]で定義されている）をポータブルで固定長のアドレス形式として使用します。
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]）は、多くの補助データ項目を定義します。SOCKETS 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.
Socketsアプリケーションは、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ヘッダー情報を説明します。この構造は、送信パスと受信パスを混合します。SCTP_SNDINFO（セクション5.3.4で説明）および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：このフィールドには、次のフラグのいずれかが含まれている場合があり、ビットワイズまたはこれらの値で構成されています。
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対Manyスタイルのソケットの場合、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 Chunkには、原因コード12を使用して「ユーザーが開始された中止」のエラー原因が含まれます。このエラー原因の原因固有の情報は、MSG_IOVで提供されます。
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 Graceful Shutdownプロシージャが呼び出されます。優雅なシャットダウンは、両方のエンドポイントによってキューに掲載されたすべてのデータが、協会を閉じる前に正常に送信されることを保証します。
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：Associationハンドルフィールド、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（セクション8.1.22を参照）を設定している場合にのみ受信されることに注意してください（セクション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：このビットマスクは、次の値の1つ以上を保持します。
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に設定されている場合、メッセージはまだ受信されているため（部分的に配信されているため）、次の_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を参照）、受信メッセージ関数の1つへの後続の呼び出しで受信される次のストリーム番号が含まれています。
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を参照）、受信メッセージ関数の1つへの後続の呼び出しで受信される次のメッセージの長さを含んでいます。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：このフィールドには、次のフラグのいずれかが含まれている場合があり、ビットワイズまたはこれらの値で構成されています。
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対Manyスタイルのソケットの場合、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 Chunkには、原因コード12を使用して「ユーザーが開始された中止」のエラー原因が含まれます。このエラー原因の原因固有の情報は、MSG_IOVで提供されます。
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 Graceful Shutdown手順が呼び出されます。優雅なシャットダウンは、両方のエンドポイントによってキューに掲載されたすべてのデータが、協会を閉じる前に正常に送信されることを保証します。
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：Associationハンドルフィールド、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構造は、recvmsg（）を介して受信したメッセージに関するSCTPの受信情報を説明しています。
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：このフィールドには、次のフラグのいずれかが含まれている場合があり、ビットワイズまたはこれらの値で構成されています。
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：Associationハンドルフィールド、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構造は、現在のメッセージを配信するときにこの情報が既に利用可能である場合、recvmsg（）を介して配信される次のメッセージのSCTPの受信情報を説明しています。
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：このフィールドには、次のフラグのいずれかが含まれている場合があり、ビットワイズまたはこれらの値で構成されています。
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：この値は、現在ソケットバッファ内のメッセージの長さです。部分的な配信が進行中である可能性があるため、これはメッセージの全長ではないかもしれません。Flag 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; };
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スタックに非DATAイベントの通知を配信したい場合、必要な通知に適切なソケットオプションを設定します。これらのソケットオプションについては、セクション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：ピアはシャットダウンを送信しました。このソケットにそれ以上のデータを送信する必要はありません。
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：新しい協会の準備が整い、データがこのピアと交換される可能性があります。協会が正常に確立された場合、この通知は最初の通知である必要があります。
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イベントが伴います。
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対Manyスタイルのソケット）、sctp_cant_str_assocには、一連のsctp_send_failed_eventイベントが伴います。
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フィールドは、関連付けの識別子を保持します。特定の関連付けのすべての通知には、同じ関連付け識別子があります。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：SAC_STATEがSCTP_COMM_LOSTであり、この関連付けのために中止チャンクが受信された場合、SAC_INFO []には、SCTP仕様[RFC4960]のセクション3.3.7で定義されている完全な中止チャンクが含まれています。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対Manyスタイルのソケットの場合、ローカルエンドポイントは、各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フィールドは、協会の識別子を保持します。特定の関連付けのすべての通知には、同じ関連付け識別子があります。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:
リモートピアは、操作エラーメッセージをピアに送信する場合があります。このメッセージは、関連性のさまざまなエラー条件を示しています。ワイヤーに表示されるエラーチャンク全体は、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]で定義されている操作エラーの1つを表します。
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フィールドは、関連付けの識別子を保持します。特定の関連付けのすべての通知には、同じ関連付け識別子があります。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で定義されているエラーチャンクが含まれています。
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：このフィールドには、未配達のメッセージを送信するために使用される補助データ（struct 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は、協会の識別子を保持します。特定の関連付けのすべての通知には、同じ関連付け識別子があります。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.
ピアがシャットダウンを送信すると、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（struct 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フィールドは、関連付けの識別子を保持します。特定の関連付けのすべての通知には、同じ関連付け識別子があります。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（struct 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フィールドは、協会の識別子を保持します。特定の関連付けのすべての通知には、同じ関連付け識別子があります。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（struct sctp_pdapi_event）になります。
pdapi_indication: This field holds the indication being sent to the application. Currently, there is only one defined value:
PDAPI_INDICATION：このフィールドには、アプリケーションに送信されている適応が保持されます。現在、定義された値は1つだけです。
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フィールドは、協会の識別子を保持します。特定の関連付けのすべての通知には、同じ関連付け識別子があります。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（struct 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フィールドは、協会の識別子を保持します。特定の関連付けのすべての通知には、同じ関連付け識別子があります。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（struct 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フィールドは、協会の識別子を保持します。特定の関連付けのすべての通知には、同じ関連付け識別子があります。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_notificationであり、sctp_tlv構造（上記の組合を参照）のみが使用されます。SN_TYPEフィールドにこのタイプ、SCTP_TLV構造のサイズに設定されたSN_Lengthフィールドのみ、SN_FLAGSが0に設定されています。アプリケーションがこの通知を受信した場合、関心のある通知に再登録する必要があります。、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：このフィールドには、未配達のメッセージを送信するために使用される補助データ（struct 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は、関連付けの識別子を保持します。特定の関連付けのすべての通知には、同じ関連付け識別子があります。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情報が1人あたりの情報を受信します。アプリケーションは、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に設定すると、Associationイベント通知の受信が可能になります。フラグを0に設定すると、Associationイベント通知が無効になります。
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;
{struct sctp_event_subscribeイベント;
memset(&events, 0, sizeof(events));
events.sctp_data_io_event = 1;
events.sctp_association_event = 1;
setsockopt(sd, IPPROTO_SCTP, SCTP_EVENTS, &events, sizeof(events));
}
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.
1対多くのスタイルの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対1のスタイルと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のスタイルソケットでは無視されます。1対多スタイルのソケットの場合、このフィールドは特定の関連性識別子またはsctp_ {future | currentになります|すべて} _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フィールドは、それぞれのSN_TYPEフィールド（通知のSCTP_TLV構造）に表示される任意の値で満たすことができます。
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;
{struct sctp_event event;
memset(&event, 0, sizeof(event));
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対1のスタイルと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.
アプリケーションは、send（）およびsendto（）を使用して、SCTPエンドポイントのピアにデータを送信できます。recv（）およびrecvfrom（）を使用して、ピアからデータを受信できます。
The function prototypes are
関数プロトタイプはです
ssize_t send(int sd, const void *msg, size_t len, int flags);
ssize_t send（int sd、const void *msg、size_t len、int flags）;
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 flags、const struct sockaddr *to、socklen_t tolen）;
ssize_t recv(int sd, void *buf, size_t len, int flags);
ssize_t recv（int sd、void *buf、size_t len、int flags）;
ssize_t recvfrom(int sd, void *buf, size_t len, int flags, struct sockaddr *from, socklen_t *fromlen);
ssize_t recvfrom（int sd、void *buf、size_t len、int flags、struct sockaddr *from、socklen_t *fromlen）;
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：FROMアドレスのサイズ。
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つの関連付けに複数のストリームの概念があります。上記の呼び出しでは、発信者がメッセージを送信するストリームについて指定することはできません。システムは、send（）およびsend（）のデフォルトストリームとしてストリーム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はメッセージベースです。send（）およびsendto（）の上記のMSGバッファーは、単一のメッセージと見なされます。これは、発信者がいくつかのバッファーで構成されたメッセージを送信する場合、発信者はsend（）またはsend（）を呼び出す前にそれらを結合する必要があることを意味します。あるいは、発信者はsendmsg（）を使用してそれらを組み合わせることなくそれを行うことができます。send（）またはsend（）を使用してメッセージの送信は、SDで指定されたソケットで明示的なEORマーキングが有効になっていない限り、原子です。SCTPの実装に応じて、暗黙の接続セットアップのために、接続されていない1対1のスタイルソケットでSendTo（）を使用する場合があります。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.
send（）および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].
アプリケーションがユーザーデータなしでsend（）または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 level、int optname、void *optval、socklen_t *optlen）;
and
と
int setsockopt(int sd, int level, int optname, const void *optval, socklen_t optlen);
int setSockopt（int sd、int level、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.
アプリケーションは、read（）およびwrite（）を使用して、ピアからデータを受信して送信できます。Flagsパラメーターを使用できないことを除いて、recv（）およびsend（）と同じセマンティクスを持っています。
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、struct 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.
アドレス：返品時に、1つのローカルバインドされたアドレス（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（）は、エラーが発生した場合に成功すると-1を返します。
If the actual length of the address is greater than the length of the supplied sockaddr structure, the stored address will be truncated.
アドレスの実際の長さが供給されたソッカドドル構造の長さよりも大きい場合、保存されたアドレスが切り捨てられます。
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（）またはsend（）/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スタックが送信者と意図したレシーバーの間に関連性が存在しないことがわかります（sendmsg（）sendmsg（）callのmsghdr構造のmsg_nameフィールドのいずれかで渡されたアドレスで識別されますまたは、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対Manyスタイルのソケットの場合、sctp_assoc_t（association識別子）パラメーターを使用して、操作が影響する関連インスタンスを識別します。したがって、このスタイルを使用するときは設定する必要があります。
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.
1対1のスタイルのソケットと1対多スタイルのソケットを分岐する場合（セクション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.
ソケットまたはIPレベルのオプションは、ソケットごとに設定または取得されることに注意してください。これは、1対多くのスタイルのソケットの場合、ソケットに属するすべてのアソシエーション（sctp_all_assocを関連性識別子として使用するのと同様）にオプションが適用されることを意味します。1対1のスタイルの場合、これらのオプションは、ソケットによって制御される関連付けのすべてのピアアドレスに適用されます。これらのオプションの設定には、アプリケーションが注意する必要があります。
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（）の構文はISです
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 opt、void *arg、socklen_t *size）;
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はQueryの関連付けを指定します。1対1のスタイルのソケットの場合、IDは無視されます。1対多スタイルのソケットの場合、ARGとして提供される構造の関連付け識別子は無視され、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（）callsで使用できないことに注意してください。それらを使用すると、エラーが発生します（-1とerrnoがeinvalに設定されます）。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.
ARGフィールドは、発信者が提供するオプション固有の構造バッファーです。これらのオプションとオプション固有の構造の詳細については、このセクションの残りを参照してください。
sctp_opt_info() returns 0 on success, or on failure returns -1 and sets errno to the appropriate error code.
sctp_opt_info（）は成功または障害時に0を返し、rernoを適切なエラーコードに設定します。
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対多スタイルのソケットの場合、アプリケーションはAssociation Identifierまたはsctp_future_assocに記入する場合があります。srto_assoc_idでsctp_ {current | all} _assocを使用するのはエラーです。
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.
これらのパラメーターにアクセスまたは変更するには、アプリケーションはそれぞれgetsockopt（）またはsetSockopt（）を呼び出す必要があります。
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対多スタイルのソケットの場合、アプリケーションはAssociation Identifierまたはsctp_future_assocに記入する場合があります。SCTP_ {current | all} _assocを使用するのはエラーです。
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を発行する際に使用されるAssociationのCookie Life Valueです。
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.
これらのパラメーターにアクセスまたは変更するには、アプリケーションはそれぞれgetsockopt（）またはsetSockopt（）を呼び出す必要があります。
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エンドポイントを構成する場合、ユーザーは「association.max.retrans」（このオプションのsasoc_maxrxt）の値が「path.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.
アプリケーションは、このオプションを使用して、SCTP Abort Primitiveを実行できます。このオプションは、ソケットに関連するすべての関連付けに影響します。
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.
オプションを有効にするには、l_onoffを1に設定します。L_linger値が0に設定されている場合、Close（）を呼び出すことはAbort Primitiveと同じです。値が負の値に設定されている場合、SetSockopt（）呼び出しはエラーを返します。値が正の値に設定されている場合、linger_timeの場合、close（）をブロックできます。POSIXによると、時間単位は数秒であるが、特定のプラットフォームでは異なる場合があることに注意してください。この期間中に優雅なシャットダウンフェーズが終了しない場合、Close（）が戻りますが、優雅なシャットダウンフェーズはシステムで続きます。
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回の送信コールで送信できるデータの最大サイズを削減します。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対Manyスタイルのソケットのみに適用できます。設定すると、指定された秒数を超えてアイドル状態の関連付けにより、優雅なシャットダウン手順を使用して自動的に閉じます。アイドル協会は、ユーザーデータを送信または受信していない協会として定義されます。「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.
このオプションを使用するアプリケーションは、Association変更通知を受信する機能を有効にする必要があります。これは、協会の閉鎖についてアプリケーションが通知される唯一のメカニズムです。協会が閉鎖された後、それに割り当てられた関連付け識別子は再利用できます。アプリケーションは、誤ったピアエンドポイントにデータを送信する可能性のある問題を回避するためにこれに注意する必要があります。
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スタックが密閉されたピアアドレスを協会のプライマリとして使用することを要求します。囲まれたアドレスは、協会のピアのアドレスの1つでなければなりません。
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対多スタイルのソケットについては、このリクエストの関連付けを識別します。特別なsctp_assoc_t sctp_ {future | all | current} _assocは許可されていないことに注意してください。
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-ack交換の指定された適応レイヤー表示パラメーターを設定することを要求します。
The following structure is used to access and modify this parameter:
次の構造は、このパラメーターにアクセスして変更するために使用されます。
struct sctp_setadaptation { uint32_t ssb_adaptation_ind; };
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
このオプションはオン/オフフラグであり、ゼロ以外がオンでゼロがオフになっている整数として渡されます。有効にすると、SCTPメッセージの断片化は実行されません。このオプションを有効にする効果
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.
送信されるメッセージが現在のパス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対多スタイルのソケットの場合、アプリケーションは、このクエリのAssociation識別子またはsctp_future_assocに記入する場合があります。sctp_ {current | all} _assocを使用するのはエラーです。
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とジッターも含まれるため、SCTPが継続的にハートビートを送信することを意味しません（[RFC4960]のセクション8.3を参照）。
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は相互に排他的であることに注意してください。これら2つのうち1つのみを指定する必要があります。両方のフィールドを有効にすると、未定の結果が得られます。
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
SendTo（）システムコールを使用したいアプリケーションでは、通常、補助データを含めることで提供されるパラメーターのデフォルトセットを指定することをお勧めします。このソケットオプションは許可されます
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.
デフォルトのsctp_sndrcvinfo構造を設定するためのこのようなアプリケーション。このソケットオプションを使用したいアプリケーションは、SCTP_SNDRCVINFO構造（セクション5.3.2で定義）をこの呼び出しに渡すだけです。この呼び出しで受け入れられた入力パラメーターには、sinfo_stream、sinfo_flags、sinfo_ppid、sinfo_context、およびsinfo_timetoliveが含まれます。sinfo_flagsフィールドは、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
このオプションは、最大サイズを取得または設定して、発信SCTPデータチャンクを入力します。メッセージがこの最大サイズよりも大きい場合、SCTPによって指定されたサイズに断片化されます。基礎となるSCTP実装は、基礎となる関連付けのPMTUがユーザーが設定した値よりも小さい場合、より小さなサイズのチャンクに断片化する可能性があることに注意してください。このオプションのデフォルト値は「0」です。これは、ユーザーが断片化を制限しておらず、PMTUのみがSCTPのデータチャンクサイズの選択に影響することを示しています。それも注意してください
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).
IPデータグラムの最大サイズよりも大きく設定された値により、SCTPが断片化を効果的に制御できます（つまり、このオプションを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対多スタイルのソケットの場合、このパラメーターは、ユーザーがアクションを実行している関連付けを示します。sctp_ {current | all} _assocを使用するのはエラーです。
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.
このオプションは、Association共有キーを構築するために使用されるアクティブな共有キーを取得または設定します。
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'がデフォルトでnullキーになることに注意してください。
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（）呼び出し後にSEND CALLを介してSCTP実装に与えられたすべてのメッセージに対して、再び変更されるまで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.
このオプションは、遅延サックの実行方法に影響します。このオプションにより、アプリケーションはミリ秒単位で遅延したサック時間を取得または設定できます。また、遅延したサック周波数を変更することもできます。周波数を1に変更すると、遅延したサックアルゴリズムが無効になります。このオプションを設定するときに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：このパラメーターには、ユーザーが遅延したサックタイマーを設定することを要求しているミリ秒数が含まれています。この値は[RFC4960]で200〜500ミリ秒であると定義されていることに注意してください。
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：このパラメーターには、遅延タイマーが期限切れになるのを待たずにサックを送信する前に受信する必要があるパケットの数が含まれています。デフォルト値は2です。この値を1に設定すると、遅延サックアルゴリズムが無効になります。
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つのレベルのフラグメントインターリーブがあります。2つのレベルは1対1のスタイルのソケットに影響しますが、1対多様なスタイルのソケットは3つのレベルすべての影響を受けます。
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:
3つのレベルを設定すると、次の受信機相互作用が提供されます。
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：メッセージの完全なインターリーブを許可します。このレベルでは、送信者がピアアソシエーション識別子（またはアドレス）を注意深く観察するだけでなく、ストリーム番号に注意を払う必要があります。このオプションを有効にすると、部分的に配信されたメッセージがAssociation "x"ストリーム "y"に対して配信され始める場合があり、次の後続の受信は、協会の「x "stream" z」からのメッセージを返すことができます。Association "x" Stream "y"に対して他のメッセージは、すべてのStream "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対多スタイルのソケットをレベル1にデフォルトでデフォルトする必要があります。そうしないと、ピアが部分的なメッセージの送信を開始し、他のすべてのピアがデータの送信をブロックする可能性があるためです。ただし、レベル2の設定では、アプリケーションが協会（協会の識別子またはピアのアドレスを介して）だけでなく、ストリーム番号も認識する必要があります。ユーザーがSCTP_DATA_IO_EVENT（セクション6.2を参照）に購読している場合を除き、SCTP_RECVRCVINFOソケットオプションを有効にしている場合（セクション6.2を参照）、ストリーム番号は存在しません（セクション8.1.29を参照）。これは、1対1のスタイルのソケットをレベル0にデフォルトすることをお勧めする理由でもあります（1対1のスタイルのソケットのレベル1には効果がありません）。アプリケーションがレベルを2に設定しようとし、廃止されたSCTP_DATA_IO_EVENTイベントにサブスクライブしていない場合、またはSCTP_RECVRCVINFOソケットオプションを有効にしていない場合、実装はエラーを返す必要があることに注意してください。
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の部分配信ポイントを設定または取得します。このポイントは、ピア用のRWNDスペースを解放するために部分配信APIが呼び出されるメッセージのサイズです。これをより低い値に設定すると、部分的な配信がより頻繁に行われます。このオプションは、バイトで部分的な配信ポイントを設定または取得する整数を期待しています。また、ユーザーがソケットがバッファサイズを受信するよりも大きいこの値を設定しようとすると、通話が失敗することにも注意してください。
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部分以下の長さを持つ単一のメッセージが1回の読み取りコールで配信されることに注意してください。
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チャンクの自動生成の使用を有効または無効にして、既存の関連付けにアドレスを追加および削除します。このオプションには2つの警告があります。つまり、a）SCTPスタックで利用可能なすべてのアドレスにバインドされているソケットのみに影響し、b）システム管理者は、ソケットの設定に関係なくASCONF機能をオフにするオーバーライドコントロールを持つ場合があります。オプションにはあります。
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ソケットのみをサポートしています。1対多くのスタイルの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ソケットにbind（）またはsctp_bindx（）を呼び出した後に使用しないでください。sctp_reuse_portオプションを備えたソケットでbind（）またはsctp_bindx（）を使用している場合、同じポートにバインドされた他のすべてのsctpソケットには、sctp_reuse_portオプションを設定する必要があります。SCTP_REUSE_PORTオプションを設定せずにソケットにbind（）または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_rcvinfoの配信を有効または無効にする（sctp_recvrcvinfo）
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_nxtinfoの配信を有効または無効にする（sctp_recvnxtinfo）
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パラメーターは、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のスタイルソケットでは無視されます。1対多スタイルのソケットの場合、pr_assoc_idは特定の関連性識別子またはsctp_ {future | current | all} _assocになります。
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.
アプリケーションは、協会の状態、ピアレシーバーのウィンドウサイズ、未解決のデータチャンクの数、保留中のデータチャンクの数を含む関連に関する現在のステータス情報を取得できます。この情報は読み取り専用です。
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対多スタイルのソケットの場合、関連付けの識別子が保持されます。特定の関連付けのすべての通知には、同じ関連付け識別子があります。特別なsctp_ {future |電流|すべて} _assocは使用できません。
sstat_state: This contains the association's current state, i.e., one of the following values:
SSTAT_STATE：これには、協会の現在の状態、つまり次の値の1つが含まれています。
* 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_ESTABLISHED
* 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：これには、Association Peerの現在のレシーバーウィンドウサイズが含まれています。
sstat_unackdata: This is the number of unacknowledged DATA chunks.
SSTAT_UNACKDATA：これは、未承認のデータチャンクの数です。
sstat_penddata: This is the number of DATA chunks pending receipt.
SSTAT_PENDDATA：これは、領収書が保留中のデータチャンクの数です。
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対多スタイルのソケットの場合、アプリケーションはAssociation Identifierまたはsctp_future_assocに記入する場合があります。gauth_assoc_idでsctp_ {current | all} _assocを使用するのはエラーです。
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. Associations（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]を参照）。囲まれたアドレスは、協会のローカルにバインドされたアドレスの1つでなければなりません。
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; };
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 |すべて} _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'がデフォルトでnullキーになることに注意してください。
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：このパラメーターには、エンドポイント（または関連）が共有シークレットキーとして使用するバイトの配列が含まれています。このフィールドの長さがゼロの場合、nullキーが設定されていることに注意してください。
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 |電流|すべて} _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：このパラメーターは、アプリケーションが非アクティブ化されることを要求している共有キー識別子です。キー識別子は、既存の共有キーに対応する必要があります。このパラメーターがゼロの場合、nullキー識別子 '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 Associationの共有シークレットキーを削除します。
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 |電流|すべて} _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実装によって送信されるパケットに使用してはなりません。これは、特に、最初に非アクティブ化する必要があることを意味します。このパラメーターがゼロの場合、nullキー識別子 '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、struct sockaddr *addrs、int addrcnt、int flags）;
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アドレスのINADDR_ANYとして、またはIPv6アドレスのIN6ADDR_ANY_INITまたはIN6ADDR_ANYとして1つのアドレスを指定できます。この使用については、セクション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.
ADDRSは、1つ以上のソケットアドレスの配列へのポインターです。各アドレスは、適切な構造に含まれています。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（）は0を返します。失敗時に、sctp_bindx（）は-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（）は故障し、errnoをeinvalに設定します。
The flags parameter is formed from the bitwise OR of zero or more of the following currently defined flags:
フラグパラメーターは、ビットワイズまたは現在定義されているフラグのゼロ以上から形成されます。
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
アプリケーションは、sctp_bindx（sctp_bindx_add_addr）を使用して、bind（）を呼び出した後、追加のアドレスをエンドポイントに関連付けることができます。または、アプリケーションはsctp_bindx（sctp_bindx_rem_addr）を使用して、リスニングソケットが関連付けられているアドレスを削除するため、これらのアドレスに関連付けられている新しい関連付けはありません。場合
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_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を返し、errnoをeopnotsuppに設定する必要があります。
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または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のスタイルAccept（）Callから多少変更されていることに注意してください。）また、新しいソケットは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：Socket（）システムコールから返された元の1対Manyスタイルのソケット記述子（セクション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のスタイルAccept（）呼び出しでは、これはOUTパラメーターになりますが、1対Manyスタイルの呼び出しでは、これはパラメーターです。）
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、struct sockaddr ** addrs）;
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.
返品後、ADDRSは、ソケットタイプに適切なタイプのSockADDR構造の動的に割り当てられた配列を指します。発信者は、sctp_freepaddrs（）を使用してメモリを解放する必要があります。イン/アウトパラメーターaddrは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ソケットの場合、返されるアドレスはIPv4またはIPv6アドレスの組み合わせであり、SCTP_I_WANT_MAPPENT_MAPPED_V4_ADDRオプション設定に従ってIPv4アドレスが返されます。
For one-to-many style sockets, id specifies the association to query. For one-to-one style sockets, id is ignored.
1対多スタイルのソケットの場合、IDはQueryの関連付けを指定します。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（）によって割り当てられたすべてのリソースをfreysします。
The function prototype is
関数プロトタイプはです
void sctp_freepaddrs(struct sockaddr *addrs);
and addrs is the array of peer addresses returned by sctp_getpaddrs().
addrsは、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、struct sockaddr ** addrs）;
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.
返品後、ADDRSは、ソケットタイプに適切なタイプのSockADDR構造の動的に割り当てられた配列を指します。発信者は、sctp_freeladdrs（）を使用してメモリを解放する必要があります。イン/アウトパラメーターaddrは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ソケットの場合、返されるアドレスはIPv4またはIPv6アドレスの組み合わせであり、SCTP_I_WANT_MAPPENT_MAPPED_V4_ADDRオプション設定に従ってIPv4アドレスが返されます。
For one-to-many style sockets, id specifies the association to query. For one-to-one style sockets, id is ignored.
1対多スタイルのソケットの場合、IDはQueryの関連付けを指定します。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（）によって割り当てられたすべてのリソースをfreysします。
The function prototype is
関数プロトタイプはです
void sctp_freeladdrs(struct sockaddr *addrs);
and addrs is the array of local addresses returned by sctp_getladdrs().
addrsは、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（int sd、const void *msg、size_t len、const struct sockaddr *to、socklen_t tolen、uint32_t ppid、uint32_t flags、uint16_t strame_no、uint32_t timetolive、uint32_t contertion）;
and the arguments are
そして、議論はそうです
sd: The socket descriptor.
SD：ソケット記述子。
msg: The message to be sent.
MSG：送信されるメッセージ。
len: The length of the message.
レン：メッセージの長さ。
to: The destination address of the message.
宛先：メッセージの宛先アドレス。
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).
sctp_sendmsg（）を使用してメッセージの送信はAtomicです（SDで指定されたソケットで明示的なEORマーキングが有効になっていない限り）。
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.
SCTPの実装に応じて、暗黙の接続セットアップのために、接続されていない1対1のスタイルソケットでsctp_sendmsg（）を使用する場合があります。
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 sd、void *msg、size_t len、struct sockaddr *from、socklen_t *fromlen struct sctp_sndrcvinfo *sinfo int *msg_flags）;
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：from Lengthを記述するイン/アウトパラメーター。
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、struct sockaddr *addrs、int addrcnt、sctp_assoc_t *id）;
and the arguments are
そして、議論はそうです
sd: The socket descriptor.
SD：ソケット記述子。
addrs: An array of addresses.
addrs：アドレスの配列。
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：非ヌルとして渡された場合、新しく作成されたアソシエーションの協会識別子を返す出力パラメーター（成功した場合）。
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 struct sctp_sndrcvinfo *sinfo、int flags）;
and the arguments are
そして、議論はそうです
sd: The socket descriptor.
SD：ソケット記述子。
msg: The message to be sent.
MSG：送信されるメッセージ。
len: The length of the message.
レン：メッセージの長さ。
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.
この関数呼び出しは、SINFO.SINFO_FLAGSをSCTP_EOFに設定し、SINFO.SINFO_ASSOC_IDを終了する必要がある協会に設定することにより、アソシエーション識別子を使用してアソシエーションを終了するために使用することもできます。そのような場合、レンはゼロになる可能性があります。
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.
SCTPの実装に応じて、暗黙的な接続セットアップのために、接続されていない1対1のスタイルソケットでsctp_send（）を使用する場合があります。
Sending a message using sctp_send() is atomic unless explicit EOR marking is enabled on the socket specified by sd.
SCTP_SEND（）を使用してメッセージの送信は、SDで指定されたソケットで明示的なEORマーキングが有効になっていない限りAtomicです。
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構造を使用せずにデータの送信でアプリケーションを支援し、アドレスのリストを提供するために、別の代替機能またはシステムコールを提供する場合があります。アドレスのリストは、暗黙的な協会のセットアップのために提供されています。そのような場合、アドレスのリストは、sctp_connectx（）に与えられたアドレスと同じ目的を果たします（セクション9.9を参照）。
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、struct sockaddr *addrs、int addrcnt、struct sctp_sndrcvinfo *sinfo、int flags）;
and the arguments are
そして、議論はそうです
sd: The socket descriptor.
SD：ソケット記述子。
msg: The message to be sent.
MSG：送信されるメッセージ。
len: The length of the message.
レン：メッセージの長さ。
addrs: An array of addresses.
addrs：アドレスの配列。
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.
この関数呼び出しは、SINFO.SINFO_FLAGSをSCTP_EOFに設定し、SINFO.SINFO_ASSOC_IDを終了する必要がある協会に設定することにより、アソシエーション識別子を使用してアソシエーションを終了するために使用することもできます。そのような場合、レンはゼロになります。
Sending a message using sctp_sendx() is atomic unless explicit EOR marking is enabled on the socket specified by sd.
SCTP_SENDX（）を使用してメッセージの送信は、SDで指定されたソケットで明示的なEORマーキングが有効になっていない限りAtomicです。
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.
SCTPの実装に応じて、暗黙的な接続セットアップのために非接続された1対1のスタイルソケットでsctp_sendx（）を使用する場合があります。
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 struct iovec *iov、int iovcnt、struct sockaddr *addrs、int addrcnt、void *info、socklen_t infolen、unsigned int infotype、int flags）;
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.
このドキュメントでは、送信されるメッセージを説明するために使用できる3種類の属性を定義します。それらは、struct sctp_sndinfo（セクション5.3.4）、struct sctp_prinfo（セクション5.3.7）、およびstruct 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フィールドは、sctp_send_sndinfo_valid、sctp_send_prinfo_valid、およびsctp_sndinfo/sendv_prinfo/sendvo/sendvo fieldsが有効な情報を含むかどうかを示すsctp_send_prinfo_valid、およびsctp_send_prinfo_validのビットワイズまたはビットワイズまたは保持を保持します。
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.
ADDRS：メッセージを送信するために使用されるアソシエーションまたは単一のアドレスをセットアップするために使用される一連のアドレス。発信者が協会を設定したくないし、特定のアドレスにメッセージを送信したくない場合、Nullは渡されます。
addrcnt: The number of addresses in the addrs array.
addrcnt：addrs配列のアドレスの数。
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_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:
Infotype：情報で提供される情報のタイプを識別します。現在の定義された値は次のとおりです。
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：パラメーター情報は、struct sctp_sndinfoを指しています。
SCTP_SENDV_PRINFO: The parameter info is pointing to a struct sctp_prinfo.
sctp_sendv_prinfo：パラメーター情報は、struct sctp_prinfoを指しています。
SCTP_SENDV_AUTHINFO: The parameter info is pointing to a struct sctp_authinfo.
sctp_sendv_authinfo：パラメーター情報は、struct sctp_authinfoを指しています。
SCTP_SENDV_SPA: The parameter info is pointing to a struct sctp_sendv_spa.
sctp_sendv_spa：パラメーター情報は、struct 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対Manyスタイルのソケットに関するメモ：struct 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パラメーターのアドレスのリストを提供して、関連付けを設定します。この関数は、sctp_connectx（）を呼び出すように振る舞います（セクション9.9を参照）、最初にアドレスのリストを使用してから、指定されたメッセージと属性を使用してsendmsg（）を呼び出します。1対多スタイルのソケットの場合、struct sctp_sndinfo属性が提供されている場合、SND_ASSOC_IDフィールドは0でなければなりません。この関数が戻ると、SND_ASSOC_IDフィールドには、新しく確立された関連付けの協会識別子が含まれます。Struct 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_ADDR_OVERに設定されたフィールドSND_FLAGSでstruct SCTP_SNDINFO属性を提供できます。
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.
この関数呼び出しは、関連付けを終了するためにも使用できます。発信者は、snd_flagsがsctp_eofに設定されたsctp_sndinfo属性を提供します。この場合、レンはゼロになります。
Sending a message using sctp_sendv() is atomic unless explicit EOR marking is enabled on the socket specified by sd.
SCTP_SENDV（）を使用してメッセージの送信は、SDで指定されたソケットで明示的なEORマーキングが有効になっていない限り、原子です。
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（int sd、const struct iovec *iov、int iovlen、struct sockaddr *from、socklen_t *from、void *info、socklen_t *infolen、unsigned int *infotype、int *flags）;
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ソケットオプションをそれぞれこれらの属性を受信できるようにします。受信メッセージの属性はstruct sctp_rcvinfo（セクション5.3.5）で返され、次のメッセージの属性はstruct 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.
将来的には、新しいタイプの属性を保持するために新しい構造を定義できます。新しい構造は、struct sctp_recvv_rnまたはstruct 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：散布バッファー。このバッファーでは、1つのユーザーメッセージのみが返されます。
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：from Lengthを記述するイン/アウトパラメーター。
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：情報のタイプはstruct 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：情報のタイプはstruct 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：情報のタイプはstruct 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（）呼び出しを介して実装された場合、フラグはsctp_recvv（）を呼び出すときにrecvmsg（）呼び出しのフラグの値のみを含める必要があり、返送時に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.
多くのTCPおよびUDP実装は、特権ユーザーの場合は1024未満のポート番号を予約しています。ターゲットプラットフォームが特権ユーザーをサポートする場合、SCTP実装は、これらのポート番号のbind（）または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 struct 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対多スタイルのソケットを使用し、インターリーブレベル（IF 0）を使用しているアプリケーション（IF 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）を使用できます。これは、このドキュメントで説明したSockets 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.
Ken Fujita、Jonathan Woods、Qiaobing Xie、La Monte 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.
著者はまた、Kavitha Baratkke、Mike Bartlett、Martin Becke、Jon Berger、Mark Butler、Thomas Dreibholz、Andreas Fink、Scott Kimble、Jonathan Leighton、Renee Revis、Irene Regeler、Dan Wing、その他TSVWGの郵送リストに感謝します。貴重なコメントを提供するために。
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 Standard 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] Gilligan、R.、Thomson、S.、Bound、J.、McCann、J。、およびW. Stevens、「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.
[RFC3542] Stevens、W.、Thomas、M.、Nordmark、E。、およびT. Jinmei、「IPv6用Advanced Socketsアプリケーションプログラムインターフェイス（API）」、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] Stewart、R.、Ramalho、M.、Xie、Q.、Tuexen、M。、およびP. Conrad、「Stream Control Transmission Protocol（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.、Stewart、R.、Lei、P。、およびE. Rescorla、「ストリーム制御伝送プロトコル（SCTP）の認証チャンク」、RFC 4895、2007年8月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R.、ed。、「Stream Control Transmission Protocol」、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] Stewart、R.、Xie、Q.、Tuexen、M.、Maruyama、S。、およびM. Kozuka、「Stream Control Transmission Protocol（SCTP）動的アドレス再構成」、RFC 5061、2007年9月。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768] POSTEL、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC1644] Braden, R., "T/TCP -- TCP Extensions for Transactions Functional Specification", RFC 1644, July 1994.
[RFC1644] Braden、R。、「T/TCP -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. Rescorla、「Stream Control Transmission Protocol（SCTP）のデータグラム輸送層セキュリティ（DTLS）」、RFC 6083、2011年1月。
[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] Eggert、L。、「非公開のTCP拡張機能RFC 1072、RFC 1106、RFC 1110、RFC 1145、RFC 1146、RFC 1379、RFC 1644、およびRFC 1693への移動」、RFC 6247、5月。
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のスタイルIPv4SCTPソケットのいくつかの機能を使用する方法を示しています。
o Creating and connecting an SCTP socket.
o SCTPソケットの作成と接続。
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().
o SCTP_SENDV（）を使用して、特定のストリームで特定のペイロードプロトコル識別子を使用してメッセージを送信します。
<CODE BEGINS> /*
<コードが始まる> /*
Copyright (c) 2011 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）2011 IETF TrustおよびCodeの著者として特定された人。全著作権所有。
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).
変更とバイナリ形式での再配布と使用は、変更の有無にかかわらず、IETF Trustの法的規定（IETFドキュメントに関する法的規定）のセクション4.Cに記載されている簡略化されたBSDライセンスに基づいて許可されており、ライセンス条件に従うことが許可されています。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>
#define PORT 9 #define ADDR "127.0.0.1" #define SIZE_OF_MESSAGE 1000 #define NUMBER_OF_MESSAGES 10 #define PPID 1234
#defineポート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>
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対ManyスタイルのIPv6SCTPソケットのいくつかの機能を使用する方法を示しています。
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.
o sctp_recvv（）を使用してメッセージを受信します。
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.
Copyright（c）2011 IETF TrustおよびCodeの著者として特定された人。全著作権所有。
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).
変更とバイナリ形式での再配布と使用は、変更の有無にかかわらず、IETF Trustの法的規定（IETFドキュメントに関する法的規定）のセクション4.Cに記載されている簡略化されたBSDライセンスに基づいて許可されており、ライセンス条件に従うことが許可されています。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>
#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、＆infotype、＆flags）;
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>
return（0）;} <Code End>
Authors' Addresses
著者のアドレス
Randall R. Stewart Adara Networks Chapin, SC 29036 USA
ランドールR.スチュワートアダラネットワークチャピン、サウスカロライナ州29036 USA
EMail: randall@lakerest.net
Michael Tuexen Muenster University of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt Germany
Michael Tuexen Muenster University of Applied Sciences Stegerwaldstr。39 48565 Steinfurtドイツ
EMail: tuexen@fh-muenster.de
Kacheong Poon Oracle Corporation
Kacheong Poon Oracle Corporation
EMail: ka-cheong.poon@oracle.com
Peter Lei Cisco Systems, Inc. 9501 Technology Blvd. West Office Center Rosemont, IL 60018 USA
Peter Lei Cisco Systems、Inc。9501 Technology Blvd.ウェストオフィスセンターローズモント、イリノイ州60018 USA
EMail: peterlei@cisco.com
Vladislav Yasevich HP 110 Spitrook Rd. Nashua, NH 03062 USA
Vladislav Yasevich HP 110 Spitrook Rd。ナシュア、NH 03062 USA
EMail: vladislav.yasevich@hp.com