[要約] RFC 7574は、P2Pストリーミングプロトコル（PPSPP）に関する規格であり、P2Pネットワーク上でのストリーミング配信を効率的に行うためのプロトコルです。目的は、帯域幅の効率的な利用とネットワークの負荷軽減を実現することです。
Internet Engineering Task Force (IETF) A. Bakker
Request for Comments: 7574 Vrije Universiteit Amsterdam
Category: Standards Track R. Petrocco
ISSN: 2070-1721 V. Grishchenko
Technische Universiteit Delft
July 2015
Peer-to-Peer Streaming Peer Protocol (PPSPP)
ピアツーピアストリーミングピアプロトコル（PPSSPP）
Abstract
概要
The Peer-to-Peer Streaming Peer Protocol (PPSPP) is a protocol for disseminating the same content to a group of interested parties in a streaming fashion. PPSPP supports streaming of both prerecorded (on-demand) and live audio/video content. It is based on the peer-to-peer paradigm, where clients consuming the content are put on equal footing with the servers initially providing the content, to create a system where everyone can potentially provide upload bandwidth. It has been designed to provide short time-till-playback for the end user and to prevent disruption of the streams by malicious peers. PPSPP has also been designed to be flexible and extensible. It can use different mechanisms to optimize peer uploading, prevent freeriding, and work with different peer discovery schemes (centralized trackers or Distributed Hash Tables). It supports multiple methods for content integrity protection and chunk addressing. Designed as a generic protocol that can run on top of various transport protocols, it currently runs on top of UDP using Low Extra Delay Background Transport (LEDBAT) for congestion control.
ピアツーピアストリーミングピアプロトコル（PPSPP）は、同じコンテンツをストリーミング方式で関係者のグループに配布するためのプロトコルです。 PPSPPは、事前に記録された（オンデマンド）とライブのオーディオ/ビデオコンテンツの両方のストリーミングをサポートします。これはピアツーピアパラダイムに基づいており、コンテンツを消費するクライアントは最初にコンテンツを提供するサーバーと対等に置かれ、誰もがアップロード帯域幅を提供できるシステムを作成します。エンドユーザーに短い再生時間を提供し、悪意のあるピアによるストリームの中断を防ぐように設計されています。 PPSPPは、柔軟性と拡張性も備えて設計されています。さまざまなメカニズムを使用して、ピアのアップロードを最適化し、フリーライディングを防止し、さまざまなピア検出スキーム（集中型トラッカーまたは分散ハッシュテーブル）を操作できます。コンテンツの整合性保護とチャンクアドレッシングのための複数の方法をサポートしています。さまざまなトランスポートプロトコルの上で実行できる汎用プロトコルとして設計されており、現在、輻輳制御のために低余分遅延バックグラウンドトランスポート（LEDBAT）を使用してUDP上で実行されています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc7574.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7574で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................5
1.1. Purpose ....................................................5
1.2. Requirements Language ......................................6
1.3. Terminology ................................................6
2. Overall Operation ...............................................9
2.1. Example: Joining a Swarm ...................................9
2.2. Example: Exchanging Chunks ................................10
2.3. Example: Leaving a Swarm ..................................10
3. Messages .......................................................11
3.1. HANDSHAKE .................................................11
3.1.1. Handshake Procedure ................................12
3.2. HAVE ......................................................14
3.3. DATA ......................................................15
3.4. ACK .......................................................15
3.5. INTEGRITY .................................................15
3.6. SIGNED_INTEGRITY ..........................................16
3.7. REQUEST ...................................................16
3.8. CANCEL ....................................................16
3.9. CHOKE and UNCHOKE .........................................17
3.10. Peer Address Exchange ....................................17
3.10.1. PEX_REQ and PEX_RES Messages ......................17
3.11. Channels .................................................19
3.12. Keep Alive Signaling .....................................20
4. Chunk Addressing Schemes .......................................21
4.1. Start-End Ranges ..........................................21
4.1.1. Chunk Ranges .......................................21
4.1.2. Byte Ranges ........................................21
4.2. Bin Numbers ...............................................22
4.3. In Messages ...............................................23
4.3.1. In HAVE Messages ...................................23
4.3.2. In ACK Messages ....................................24
5. Content Integrity Protection ...................................24
5.1. Merkle Hash Tree Scheme ...................................25
5.2. Content Integrity Verification ............................26
5.3. The Atomic Datagram Principle .............................27
5.4. INTEGRITY Messages ........................................28
5.5. Discussion and Overhead ...................................28
5.6. Automatic Detection of Content Size .......................29
5.6.1. Peak Hashes ........................................29
5.6.2. Procedure ..........................................31
6. Live Streaming .................................................32
6.1. Content Authentication ....................................32
6.1.1. Sign All ...........................................33
6.1.2. Unified Merkle Tree ................................33
6.1.2.1. Signed Munro Hashes .......................34
6.1.2.2. Munro Signature Calculation ...............36
6.1.2.3. Procedure .................................37
6.1.2.4. Secure Tune In ............................37
6.2. Forgetting Chunks .........................................38
7. Protocol Options ...............................................38
7.1. End Option ................................................39
7.2. Version ...................................................39
7.3. Minimum Version ...........................................40
7.4. Swarm Identifier ..........................................40
7.5. Content Integrity Protection Method .......................41
7.6. Merkle Tree Hash Function .................................41
7.7. Live Signature Algorithm ..................................42
7.8. Chunk Addressing Method ...................................42
7.9. Live Discard Window .......................................43
7.10. Supported Messages .......................................44
7.11. Chunk Size ...............................................44
8. UDP Encapsulation ..............................................45
8.1. Chunk Size ................................................45
8.2. Datagrams and Messages ....................................46
8.3. Channels ..................................................47
8.4. HANDSHAKE .................................................47
8.5. HAVE ......................................................48
8.6. DATA ......................................................48
8.7. ACK .......................................................49
8.8. INTEGRITY .................................................50
8.9. SIGNED_INTEGRITY ..........................................51
8.10. REQUEST ..................................................52
8.11. CANCEL ...................................................52
8.12. CHOKE and UNCHOKE ........................................53
8.13. PEX_REQ, PEX_RESv4, PEX_RESv6, and PEX_REScert ...........53
8.14. KEEPALIVE ................................................55
8.15. Flow and Congestion Control ..............................56
8.16. Example of Operation .....................................57
9. Extensibility ..................................................61
9.1. Chunk Picking Algorithms ..................................61
9.2. Reciprocity Algorithms ....................................62
10. IANA Considerations ...........................................62
10.1. PPSPP Message Type Registry ..............................62
10.2. PPSPP Option Registry ....................................62
10.3. PPSPP Version Number Registry ............................62
10.4. PPSPP Content Integrity Protection Method Registry .......62
10.5. PPSPP Merkle Hash Tree Function Registry .................63
10.6. PPSPP Chunk Addressing Method Registry ...................63
11. Manageability Considerations ..................................63
11.1. Operations ...............................................63
11.1.1. Installation and Initial Setup ....................63
11.1.2. Migration Path ....................................64
11.1.3. Requirements on Other Protocols and
Functional Components .............................64
11.1.4. Impact on Network Operation .......................64
11.1.5. Verifying Correct Operation .......................65
11.1.6. Configuration .....................................65
11.2. Management Considerations ................................66
11.2.1. Management Interoperability and Information .......67
11.2.2. Fault Management ..................................67
11.2.3. Configuration Management ..........................67
11.2.4. Accounting Management .............................68
11.2.5. Performance Management ............................68
11.2.6. Security Management ...............................68
12. Security Considerations .......................................68
12.1. Security of the Handshake Procedure ......................68
12.1.1. Protection against Attack 1 .......................69
12.1.2. Protection against Attack 2 .......................70
12.1.3. Protection against Attack 3 .......................70
12.2. Secure Peer Address Exchange .............................71
12.2.1. Protection against the Amplification Attack .......71
12.2.2. Example: Tracker as Certification Authority .......72
12.2.3. Protection against Eclipse Attacks ................73
12.3. Support for Closed Swarms ................................73
12.4. Confidentiality of Streamed Content ......................74
12.5. Strength of the Hash Function for Merkle Hash Trees ......74
12.6. Limit Potential Damage and Resource Exhaustion by
Bad or Broken Peers ......................................74
12.6.1. HANDSHAKE .........................................75
12.6.2. HAVE ..............................................75
12.6.3. DATA ..............................................75
12.6.4. ACK ...............................................75
12.6.5. INTEGRITY and SIGNED_INTEGRITY ....................76
12.6.6. REQUEST ...........................................76
12.6.7. CANCEL ............................................76
12.6.8. CHOKE .............................................77
12.6.9. UNCHOKE ...........................................77
12.6.10. PEX_RES ..........................................77
12.6.11. Unsolicited Messages in General ..................77
12.7. Exclude Bad or Broken Peers ..............................77
13. References ....................................................78
13.1. Normative References .....................................78
13.2. Informative References ...................................79
Acknowledgements ..................................................84
Authors' Addresses ................................................85
This document describes the Peer-to-Peer Streaming Peer Protocol (PPSPP), designed for disseminating the same content to a group of interested parties in a streaming fashion. PPSPP supports streaming of both prerecorded (on-demand) and live audio/video content. It is based on the peer-to-peer paradigm where clients consuming the content are put on equal footing with the servers initially providing the content, to create a system where everyone can potentially provide upload bandwidth.
このドキュメントでは、ピアツーピアストリーミングピアプロトコル（PPSPP）について説明します。PPSPPは、同じコンテンツをストリーミング方式で関係者のグループに配布するために設計されています。 PPSPPは、事前に記録された（オンデマンド）とライブのオーディオ/ビデオコンテンツの両方のストリーミングをサポートします。これはピアツーピアパラダイムに基づいており、コンテンツを消費するクライアントは最初にコンテンツを提供するサーバーと同等の立場に置かれ、誰もがアップロード帯域幅を提供できるシステムを作成します。
PPSPP has been designed to provide short time-till-playback for the end user and to prevent disruption of the streams by malicious peers. Central in this design is a simple method of identifying content based on self-certification. In particular, content in PPSPP is identified by a single cryptographic hash that is the root hash in a Merkle hash tree calculated recursively from the content [MERKLE] [ABMRKL]. This self-certifying hash tree allows every peer to directly detect when a malicious peer tries to distribute fake content. The tree can be used for both static and live content. Moreover, it ensures only a small amount of information is needed to start a download and to verify incoming chunks of content, thus ensuring short start-up times.
PPSPPは、エンドユーザーに再生までの短い時間を提供し、悪意のあるピアによるストリームの中断を防ぐように設計されています。この設計の中心は、自己認証に基づいてコンテンツを識別する簡単な方法です。特に、PPPSPのコンテンツは、コンテンツ[MERKLE] [ABMRKL]から再帰的に計算されるマークルハッシュツリーのルートハッシュである単一の暗号化ハッシュによって識別されます。この自己認証ハッシュツリーにより、悪意のあるピアが偽のコンテンツを配信しようとしたときに、すべてのピアが直接検出できます。ツリーは静的コンテンツとライブコンテンツの両方に使用できます。さらに、ダウンロードを開始し、コンテンツの受信チャンクを検証するために必要な情報が少量であることを保証するため、起動時間が短くなります。
PPSPP has also been designed to be extensible for different transports and use cases. Hence, PPSPP is a generic protocol that can run directly on top of UDP, TCP, or other protocols. As such, PPSPP defines a common set of messages that make up the protocol, which can have different representations on the wire depending on the lower-level protocol used. When the lower-level transport allows, PPSPP can also use different congestion control algorithms.
PPSPPは、さまざまなトランスポートやユースケースに拡張できるように設計されています。したがって、PPPSPは、UDP、TCP、またはその他のプロトコルの上で直接実行できる汎用プロトコルです。したがって、PPPSPは、プロトコルを構成する共通のメッセージセットを定義します。これは、使用される下位レベルのプロトコルに応じて、回線上で異なる表現を持つことができます。低レベルのトランスポートが許可する場合、PPSPPはさまざまな輻輳制御アルゴリズムを使用することもできます。
At present, PPSPP is set to run on top of UDP using LEDBAT for congestion control [RFC6817]. Using LEDBAT enables PPSPP to serve the content after playback (seeding) without disrupting the user who may have moved to different tasks that use its network connection.
現在、PPPSPは、輻輳制御のためにLEDBATを使用してUDP上で実行するように設定されています[RFC6817]。 LEDBATを使用すると、PPSPPは、ネットワーク接続を使用する別のタスクに移動した可能性のあるユーザーを混乱させることなく、再生（シード）後にコンテンツを提供できます。
PPSPP is also flexible and extensible in the mechanisms it uses to promote client contribution and prevent freeriding, that is, how to deal with peers that only download content but never upload to others. It also allows different schemes for chunk addressing and content integrity protection, if the defaults are not fit for a particular use case. In addition, it can work with different peer discovery schemes, such as centralized trackers or fast Distributed Hash Tables [JIM11]. Finally, in this default setup, PPSPP maintains only a small amount of state per peer. A reference implementation of PPSPP over UDP is available [SWIFTIMPL].
PPSPPは、クライアントへの貢献を促進し、フリーライディングを防ぐために使用するメカニズム、つまり、コンテンツをダウンロードするだけで他人にはアップロードしないピアに対処する方法にも柔軟で拡張性があります。また、デフォルトが特定のユースケースに適合しない場合は、チャンクアドレッシングとコンテンツの整合性保護のためのさまざまなスキームを使用できます。さらに、集中型トラッカーや高速分散ハッシュテーブル[JIM11]などのさまざまなピア検出スキームと連携できます。最後に、このデフォルト設定では、PPSPPはピアごとに少量の状態のみを維持します。 PPSPP over UDPのリファレンス実装が利用可能です[SWIFTIMPL]。
The protocol defined in this document assumes that a peer has already discovered a list of (initial) peers using, for example, a centralized tracker [PPSP-TP]. Once a peer has this list of peers, PPSPP allows the peer to connect to other peers, request chunks of content, and discover other peers disseminating the same content.
このドキュメントで定義されているプロトコルは、ピアが、たとえば集中型トラッカー[PPSP-TP]を使用して（初期）ピアのリストをすでに発見していることを前提としています。ピアがこのピアのリストを取得すると、PPSPPは、ピアが他のピアに接続し、コンテンツのチャンクを要求し、同じコンテンツを広める他のピアを発見できるようにします。
The design of PPSPP is based on our research into making BitTorrent [BITTORRENT] suitable for streaming content [P2PWIKI]. Most PPSPP messages have corresponding BitTorrent messages and vice versa. However, PPSPP is specifically targeted towards streaming audio/video content and optimizes time-till-playback. It was also designed to be more flexible and extensible.
PPSPPの設計は、BitTorrent [BITTORRENT]をコンテンツのストリーミング[P2PWIKI]に適したものにするという私たちの研究に基づいています。ほとんどのPPSPPメッセージには対応するBitTorrentメッセージがあり、その逆も同様です。ただし、PPPSPは特にオーディオ/ビデオコンテンツのストリーミングを対象としており、再生までの時間を最適化します。また、より柔軟で拡張可能なように設計されました。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
message The basic unit of PPSPP communication. A message will have different representations on the wire depending on the transport protocol used. Messages are typically multiplexed into a datagram for transmission.
メッセージPPSPP通信の基本単位。メッセージは、使用されるトランスポートプロトコルに応じて、回線上で異なる表現になります。メッセージは通常、送信のためにデータグラムに多重化されます。
datagram A sequence of messages that is offered as a unit to the underlying transport protocol (UDP, etc.). The datagram is PPSPP's Protocol Data Unit (PDU).
データグラム基礎となるトランスポートプロトコル（UDPなど）に1つの単位として提供される一連のメッセージ。データグラムはPPSPPのプロトコルデータユニット（PDU）です。
content Either a live transmission or a prerecorded multimedia file.
コンテンツライブ送信または事前に記録されたマルチメディアファイル。
chunk The basic unit in which the content is divided. For example, a block of N kilobytes. A chunk may be of variable size.
チャンクコンテンツが分割される基本単位。たとえば、Nキロバイトのブロック。チャンクは可変サイズになる場合があります。
chunk ID Unique identifier for a chunk of content (e.g., an integer). Its type depends on the chunk addressing scheme used.
チャンクIDコンテンツのチャンクの一意の識別子（整数など）。そのタイプは、使用されるチャンクアドレッシングスキームによって異なります。
chunk specification An expression that denotes one or more chunk IDs.
チャンク仕様1つ以上のチャンクIDを表す式。
chunk addressing scheme Scheme for identifying chunks and expressing the chunk availability map of a peer in a compact fashion.
チャンクアドレッシングスキームチャンクを識別し、ピアのチャンク可用性マップをコンパクトに表現するためのスキーム。
chunk availability map The set of chunks a peer has successfully downloaded and checked the integrity of.
チャンク可用性マップピアが正常にダウンロードして整合性をチェックしたチャンクのセット。
bin A number denoting a specific binary interval of the content (i.e., one or more consecutive chunks) in the bin numbers chunk addressing scheme (see Section 4).
binビン番号チャンクアドレッシングスキーム（セクション4を参照）のコンテンツの特定のバイナリ間隔（つまり、1つ以上の連続したチャンク）を示す番号。
content integrity protection scheme Scheme for protecting the integrity of the content while it is being distributed via the peer-to-peer network. That is, methods for receiving peers to detect whether a requested chunk has been modified, either maliciously by the sending peer or accidentally in transit.
コンテンツの整合性保護スキームピアツーピアネットワーク経由で配信されているコンテンツの整合性を保護するためのスキーム。つまり、要求されたチャンクが送信側のピアによって悪意を持って変更されたか、誤って転送中に変更されたかを検出するために受信側のピアがメソッドを使用します。
hash The result of applying a cryptographic hash function, more specifically a Modification Detection Code (MDC) [HAC01], such as SHA-256 [FIPS180-4], to a piece of data.
hash暗号化ハッシュ関数、より具体的にはSHA-256 [FIPS180-4]などの修正検出コード（MDC）[HAC01]をデータに適用した結果。
Merkle hash tree A tree of hashes whose base is formed by the hashes of the chunks of content, and its higher nodes are calculated by recursively computing the hash of the concatenation of the two child hashes (see Section 5.1).
マークルハッシュツリーコンテンツのチャンクのハッシュによってベースが形成されるハッシュのツリー。2つ以上の子ハッシュの連結のハッシュを再帰的に計算することにより、その上位ノードが計算されます（セクション5.1を参照）。
root hash The root in a Merkle hash tree calculated recursively from the content (see Section 5.1).
ルートハッシュコンテンツから再帰的に計算されたマークルハッシュツリーのルート（セクション5.1を参照）。
munro hash The hash of a subtree that is the unit of signing in the Unified Merkle Tree content authentication scheme for live streaming (see Section 6.1.2.1).
munroハッシュライブストリーミング用のUnified Merkle Treeコンテンツ認証方式での署名の単位であるサブツリーのハッシュ（セクション6.1.2.1を参照）。
swarm A group of peers participating in the distribution of the same content.
群れ同じコンテンツの配信に参加しているピアのグループ。
swarm ID Unique identifier for a swarm of peers, in PPSPP a sequence of bytes. For video on demand with content integrity protection enabled, the identifier is the so-called root hash of a Merkle hash tree over the content. For live streaming, the swarm ID is a public key.
swarm IDピアのスウォームの一意の識別子。PPSPPでは一連のバイト。コンテンツの整合性保護が有効になっているビデオオンデマンドの場合、識別子は、コンテンツ上のマークルハッシュツリーのいわゆるルートハッシュです。ライブストリーミングの場合、スウォームIDは公開鍵です。
tracker An entity that records the addresses of peers participating in a swarm, usually for a set of swarms, and makes this membership information available to other peers on request.
トラッカー群に参加しているピアのアドレスを記録するエンティティ。通常は一連の群のために、このメンバーシップ情報を要求に応じて他のピアが利用できるようにします。
choking When Peer A is choking Peer B, it means that A is currently not willing to accept requests for content from B.
ピアAがピアBをチョークしている場合、Aは現在、Bからのコンテンツの要求を受け入れる用意がないことを意味します。
seeding Peer A is said to be seeding when A has downloaded a static content file completely and is now offering it for others to download.
シードするピアAは、Aが静的コンテンツファイルを完全にダウンロードし、他の人がダウンロードできるように提供しているときにシードすると言います。
leeching Peer A is said to be leeching when A has not completely downloaded a static content file yet or is not offering to upload it to others.
ピアAのリーチは、Aが静的コンテンツファイルをまだ完全にダウンロードしていないか、他のユーザーにアップロードすることを提案していない場合にリーチしていると言われます。
channel A logical connection between two peers. The channel concept allows peers to use the same transport address for communicating with different peers.
チャネル2つのピア間の論理接続。チャネルの概念により、ピアは同じトランスポートアドレスを使用して異なるピアと通信できます。
channel ID Unique, randomly chosen identifier for a channel, local to each peer. So the two peers logically connected by a channel each have a different channel ID for that channel.
チャネルID各ピアにローカルなチャネルの一意のランダムに選択された識別子。したがって、チャネルによって論理的に接続された2つのピアはそれぞれ、そのチャネルの異なるチャネルIDを持っています。
heavy payload A datagram has a heavy payload when it contains DATA messages, SIGNED_INTEGRITY messages, or a large number of smaller messages.
重いペイロードDATAメッセージ、SIGNED_INTEGRITYメッセージ、または多数の小さいメッセージが含まれている場合、データグラムには重いペイロードがあります。
In this document the prefixes kilo-, mega-, etc., denote base 1024.
このドキュメントでは、接頭辞キロ、メガなどはベース1024を示します。
The basic unit of communication in PPSPP is the message. Multiple messages are multiplexed into a single datagram for transmission. A datagram (and hence the messages it contains) will have different representations on the wire depending on the transport protocol used (see Section 8).
PPSPPの通信の基本単位はメッセージです。複数のメッセージが単一のデータグラムに多重化されて送信されます。データグラム（およびそれに含まれるメッセージ）は、使用されるトランスポートプロトコル（セクション8を参照）に応じて、回線上で異なる表現になります。
The overall operation of PPSPP is illustrated in the following examples. The examples assume that the content distributed is static, UDP is used for transport, the Merkle Hash Tree scheme is used for content integrity protection, and that a specific policy is used for selecting which chunks to download.
PPSPPの全体的な動作を次の例に示します。例では、配信されるコンテンツが静的であり、UDPがトランスポートに使用され、Merkle Hash Treeスキームがコンテンツの整合性保護に使用され、特定のポリシーがどのチャンクをダウンロードするかを選択するために使用されると想定しています。
Consider a user who wants to watch a video. To play the video, the user clicks on the play button of a HTML5 <video> element shown in his PPSPP-enabled browser. Imagine this element has a PPSPP URL (to be defined elsewhere) identifying the video as its source. The browser passes this URL to its peer-to-peer streaming protocol handler. Let's call this protocol handler Peer A. Peer A parses the URL to retrieve the transport address of a peer-to-peer streaming protocol tracker and swarm metadata of the content. The tracker address may be optional in the presence of a decentralized tracking mechanism. The mechanisms for tracking peers are outside of the scope of this document.
ビデオを見たいユーザーを考えてみましょう。ビデオを再生するには、ユーザーはPPSPP対応のブラウザーに表示されているHTML5 <video>要素の再生ボタンをクリックします。この要素に、ビデオをソースとして識別するPPSPP URL（別の場所で定義される）があるとします。ブラウザはこのURLをピアツーピアストリーミングプロトコルハンドラに渡します。このプロトコルハンドラーをピアAと呼びましょう。ピアAは、URLを解析して、ピアツーピアストリーミングプロトコルトラッカーのトランスポートアドレスとコンテンツの群れメタデータを取得します。分散型追跡メカニズムが存在する場合、トラッカーアドレスはオプションになります。ピアを追跡するメカニズムは、このドキュメントの範囲外です。
Peer A now registers with the tracker following the peer-to-peer streaming protocol tracker specification [PPSP-TP] and receives the IP address and port of peers already in the swarm, say, Peers B, C, and D. At this point, the PPSPP starts operating. Peer A now sends a datagram containing a PPSPP HANDSHAKE message to Peers B, C, and D. This message conveys protocol options. In particular, Peer A includes the ID of the swarm (part of the swarm metadata) as a protocol option because the destination peers can listen for multiple swarms on the same transport address.
これで、ピアAは、ピアツーピアストリーミングプロトコルトラッカー仕様[PPSP-TP]に従ってトラッカーに登録し、スウォームにすでにあるピア（ピアB、C、Dなど）のIPアドレスとポートを受信します。この時点で、PPPSPが動作を開始します。ピアAはPPSPP HANDSHAKEメッセージを含むデータグラムをピアB、C、およびDに送信します。このメッセージはプロトコルオプションを伝えます。特に、宛先ピアは同じトランスポートアドレスで複数のスウォームをリッスンできるため、ピアAには、スウォームのID（スウォームメタデータの一部）がプロトコルオプションとして含まれています。
Peers B and C respond with datagrams containing a PPSPP HANDSHAKE message and one or more HAVE messages. A HAVE message conveys (part of) the chunk availability of a peer; thus, it contains a chunk specification that denotes what chunks of the content Peers B and C have, respectively. Peer D sends a datagram with a HANDSHAKE and HAVE messages, but also with a CHOKE message. The latter indicates that Peer D is not willing to upload chunks to Peer A at present.
ピアBとCは、PPPSP HANDSHAKEメッセージと1つ以上のHAVEメッセージを含むデータグラムで応答します。 HAVEメッセージは、ピアのチャンク可用性（の一部）を伝えます。したがって、ピアBとピアCのコンテンツのチャンクをそれぞれ示すチャンク仕様が含まれています。ピアDは、HANDSHAKEおよびHAVEメッセージとともにデータグラムを送信しますが、CHOKEメッセージも送信します。後者は、ピアDが現在、チャンクをピアAにアップロードする意思がないことを示しています。
In response to Peers B and C, Peer A sends new datagrams to Peers B and C containing REQUEST messages. A REQUEST message indicates the chunks that a peer wants to download; thus, it contains a chunk specification. The REQUEST messages to Peers B and C refer to disjoint sets of chunks. Peers B and C respond with datagrams containing HAVE, DATA, and, in this example, INTEGRITY messages. In the Merkle hash tree content protection scheme (see Section 5.1), the INTEGRITY messages contain all cryptographic hashes that Peer A needs to verify the integrity of the content chunk sent in the DATA message. Using these hashes, Peer A verifies that the chunks received from Peers B and C are correct against the trusted swarm ID. Peer A also updates the chunk availability of Peers B and C using the information in the received HAVE messages. In addition, it passes the chunks of video to the user's browser for rendering.
ピアBとピアCに応答して、ピアAはREQUESTメッセージを含む新しいデータグラムをピアBとピアCに送信します。 REQUESTメッセージは、ピアがダウンロードしたいチャンクを示します。したがって、チャンク仕様が含まれています。ピアBとピアCへのREQUESTメッセージは、チャンクの互いに素なセットを参照しています。ピアBおよびCは、HAVE、DATA、およびこの例ではINTEGRITYメッセージを含むデータグラムで応答します。マークルハッシュツリーコンテンツ保護スキーム（セクション5.1を参照）では、INTEGRITYメッセージには、ピアAがDATAメッセージで送信されたコンテンツチャンクの整合性を検証するために必要なすべての暗号化ハッシュが含まれます。ピアAはこれらのハッシュを使用して、ピアBおよびピアCから受信したチャンクが信頼されたスウォームIDに対して正しいことを確認します。ピアAは、受信したHAVEメッセージの情報を使用して、ピアBおよびCのチャンクの可用性も更新します。さらに、ビデオのチャンクをレンダリングのためにユーザーのブラウザーに渡します。
After processing, Peer A sends a datagram containing HAVE messages for the chunks it just received to all its peers. In the datagram to Peers B and C, it includes an ACK message acknowledging the receipt of the chunks and adds REQUEST messages for new chunks. ACK messages are not used when a reliable transport protocol is used. When, for example, Peer C finds that Peer A obtained a chunk (from Peer B) that Peer C did not yet have, Peer C's next datagram includes a REQUEST for that chunk.
処理後、ピアAは、受信したチャンクのHAVEメッセージを含むデータグラムをすべてのピアに送信します。ピアBおよびピアCへのデータグラムには、チャンクの受信を確認するACKメッセージが含まれ、新しいチャンクのREQUESTメッセージが追加されます。信頼性の高いトランスポートプロトコルが使用されている場合、ACKメッセージは使用されません。たとえば、ピアCが、ピアAがまだ持っていないチャンクを（ピアBから）取得したことを発見すると、ピアCの次のデータグラムには、そのチャンクのREQUESTが含まれます。
Peer D also sends HAVE messages to Peer A when it downloads chunks from other peers. When Peer D is willing to accept REQUESTs from Peer A, Peer D sends a datagram with an UNCHOKE message to inform Peer A. If Peer B or C decides to choke Peer A, they send a CHOKE message and Peer A should then re-request from other peers. Peers B and C may continue to send HAVE, REQUEST, or periodic keep-alive messages such that Peer A keeps sending them HAVE messages.
ピアDは、他のピアからチャンクをダウンロードするときに、HAVEメッセージをピアAに送信します。ピアDがピアAからの要求を受け入れる用意がある場合、ピアDはUNCHOKEメッセージを含むデータグラムを送信してピアAに通知します。ピアBまたはCがピアAをチョークすることを決定した場合、それらはCHOKEメッセージを送信し、ピアAは再リクエストする必要があります他のピアから。ピアBとピアCは、ピアAがHAVEメッセージを送信し続けるように、HAVE、REQUEST、または定期的なキープアライブメッセージを送信し続けることができます。
Once Peer A has received all content (video-on-demand use case), it stops sending messages to all other peers that have all content (a.k.a. seeders). Peer A can also contact the tracker or another source again to obtain more peer addresses.
ピアAがすべてのコンテンツを受信すると（ビデオオンデマンドの使用例）、すべてのコンテンツを持つ他のすべてのピア（別名シーダー）へのメッセージの送信を停止します。ピアAは、トラッカーまたは別のソースに再度接続して、さらにピアアドレスを取得することもできます。
To leave a swarm in a graceful way, Peer A sends a specific HANDSHAKE message to all its peers (see Section 8.4) and deregisters from the tracker following the tracker specification [PPSP-TP]. Peers receiving the datagram should remove Peer A from their current peer list. If Peer A crashes ungracefully, peers should remove Peer A from their peer list when they detect it no longer sends messages (see Section 3.12).
正常な方法で群れを離れるために、ピアAは特定のHANDSHAKEメッセージをそのすべてのピアに送信し（セクション8.4を参照）、トラッカー仕様[PPSP-TP]に従ってトラッカーから登録解除します。データグラムを受信するピアは、ピアAを現在のピアリストから削除する必要があります。ピアAが異常にクラッシュした場合、ピアはメッセージを送信しなくなったことを検出したときに、ピアリストからピアAを削除する必要があります（セクション3.12を参照）。
No error codes or responses are used in the protocol; absence of any response indicates an error. Invalid messages are discarded, and further communication with the peer SHOULD be stopped. The rationale is that it is sufficient to classify peers as either good or bad and only use the good ones. A good peer is a peer that responds with chunks; a peer that does not respond, or does not respond in time is classified as bad. The idea is that, in PPSPP, the content is available from multiple sources (unlike HTTP), so a peer should not invest too much effort in trying to obtain it from a particular source. This classification in good or bad allows a peer to deal with slow, crashed, and (silent) malicious peers.
プロトコルではエラーコードや応答は使用されません。応答がない場合はエラーを示します。無効なメッセージは破棄され、ピアとの以降の通信は停止する必要があります（SHOULD）。理論的根拠は、ピアを良好または不良のいずれかに分類し、良好なもののみを使用することで十分であるということです。良いピアとは、チャンクで応答するピアです。応答しない、または時間内に応答しないピアは、不良として分類されます。 PPSPPでは、コンテンツは（HTTPとは異なり）複数のソースから利用できるため、ピアは特定のソースからコンテンツを取得しようとすることに多大な労力を費やすべきではありません。この良いか悪いかの分類により、ピアは低速で、クラッシュした、（サイレント）悪意のあるピアに対処できます。
Multiple messages MUST be multiplexed into a single datagram for transmission. Messages in a single datagram MUST be processed in the strict order in which they appear in the datagram. If an invalid message is found in a datagram, the remaining messages MUST be discarded.
複数のメッセージは、送信のために単一のデータグラムに多重化されなければなりません。単一のデータグラム内のメッセージは、データグラムに表示される厳密な順序で処理する必要があります。データグラムで無効なメッセージが見つかった場合は、残りのメッセージを破棄する必要があります。
For the sake of simplicity, one swarm of peers deals with one content file or stream only. There is a single division of the content into chunks that all peers in the swarm adhere to, determined by the content publisher. Distribution of a collection of files can be done either by using multiple swarms or by using an external storage mapping from the linear byte space of a single swarm to different files, transparent to the protocol. In other words, the audio/video container format used is outside the scope of this document.
簡単にするために、ピアの1つの群れは1つのコンテンツファイルまたはストリームのみを扱います。コンテンツのチャンクへの単一の分割があり、スウォームのすべてのピアは、コンテンツパブリッシャーによって決定されます。ファイルのコレクションの配布は、複数のスウォームを使用するか、単一のスウォームの線形バイトスペースから異なるファイルへの外部ストレージマッピングを使用して、プロトコルに対して透過的に行うことができます。言い換えると、使用されるオーディオ/ビデオコンテナー形式は、このドキュメントの範囲外です。
For Peer P to establish communication with Peer Q in Swarm S, the peers must first exchange HANDSHAKE messages by means of a handshake procedure. The initiating Peer P needs to know the metadata of Swarm S, which consists of:
ピアPがスウォームSのピアQとの通信を確立するには、ピアは最初にハンドシェイク手順を使用してHANDSHAKEメッセージを交換する必要があります。開始側のピアPは、以下で構成されるSwarm Sのメタデータを知る必要があります。
(a) the swarm ID of the content (see Sections 5.1 and 6),
（a）コンテンツの群ID（セクション5.1および6を参照）、
(b) the chunk size used,
（b）使用されるチャンクサイズ、
(c) the chunk addressing method used,
（c）使用されるチャンクアドレス指定方法
(d) the content integrity protection method used, and
（d）使用されるコンテンツの完全性保護方法、および
(e) the Merkle hash tree function used (if applicable).
（e）使用されるマークルハッシュツリー関数（該当する場合）。
(f) If automatic content size detection (see Section 5.6) is not used, the content length is also part of the metadata (for static content.)
（f）自動コンテンツサイズ検出（セクション5.6を参照）を使用しない場合、コンテンツの長さもメタデータの一部になります（静的コンテンツの場合）。
This document assumes the swarm metadata is obtained from a trusted source. In addition, Peer P needs to know a transport address for Peer Q, obtained from a peer discovery/tracking protocol.
このドキュメントは、swarmメタデータが信頼できるソースから取得されていることを前提としています。さらに、ピアPは、ピア発見/追跡プロトコルから取得したピアQのトランスポートアドレスを知る必要があります。
The payload of the HANDSHAKE message contains a sequence of protocol options. The protocol options encode the swarm metadata just described to enable an end-to-end check to see whether the peers are in the right swarm. Additionally, the options encode a number of per-peer configuration parameters. The complete set of protocol options are specified in Section 7. The HANDSHAKE message also contains a channel ID for multiplexing communication and security (see Sections 3.11 and 12.1). A HANDSHAKE message MUST always be the first message in a datagram.
HANDSHAKEメッセージのペイロードには、一連のプロトコルオプションが含まれています。プロトコルオプションは、ピアが正しい群れにあるかどうかを確認するためのエンドツーエンドのチェックを可能にするために、今説明した群れのメタデータをエンコードします。さらに、オプションは、ピアごとの構成パラメーターの数をエンコードします。プロトコルオプションの完全なセットは、セクション7で指定されています。HANDSHAKEメッセージには、通信とセキュリティを多重化するためのチャネルIDも含まれています（セクション3.11および12.1を参照）。 HANDSHAKEメッセージは、常にデータグラムの最初のメッセージでなければなりません。
The handshake procedure for a peer, Peer P, to start communication with another peer, Peer Q, in Swarm S is now as follows.
Swarm SでピアPeer Pが別のピアPeer Qと通信を開始するためのハンドシェイク手順は次のとおりです。
1. The first datagram the initiating Peer P sends to Peer Q MUST start with a HANDSHAKE message. This HANDSHAKE message MUST contain:
1. 開始ピアPがピアQに送信する最初のデータグラムは、ハンドシェイクメッセージで始まる必要があります。このHANDSHAKEメッセージには、以下が含まれている必要があります。
* A channel ID, chanP, randomly chosen as specified in Section 12.1.
* セクション12.1で指定されているようにランダムに選択されたチャネルID chanP。
* The metadata of Swarm S, encoded as protocol options, as specified in Section 7. In particular, the initiating Peer P MUST include the swarm ID.
* セクション7で指定されているように、プロトコルオプションとしてエンコードされたSwarm Sのメタデータ。特に、開始ピアPは、Swarm IDを含める必要があります。
* The capabilities of Peer P, in particular, its supported protocol versions, "Live Discard Window" (in case of a live swarm) and "Supported Messages", encoded as protocol options.
* ピアPの機能、特に、サポートされているプロトコルバージョンである「ライブ破棄ウィンドウ」（ライブスウォームの場合）および「サポートされているメッセージ」は、プロトコルオプションとしてエンコードされています。
This first datagram MUST be prefixed with the (destination) channel ID 0; see Section 3.11. Hence, the datagram contains two channel IDs: the destination channel ID prefixed to the datagram and the channel ID chanP included in the HANDSHAKE message inside the datagram. This datagram MAY also contain some minor additional payload, e.g., HAVE messages to indicate Peer P's current progress, but it MUST NOT include any heavy payload (defined in Section 1.3), such as a DATA message. Allowing minor
この最初のデータグラムには、（宛先）チャネルID 0をプレフィックスとして付ける必要があります。セクション3.11を参照してください。したがって、データグラムには2つのチャネルIDが含まれています。データグラムの前に付けられる宛先チャネルIDと、データグラム内のHANDSHAKEメッセージに含まれるチャネルID chanPです。このデータグラムには、ピアPの現在の進行状況を示すHAVEメッセージなどのマイナーな追加ペイロードも含まれる場合がありますが、DATAメッセージなどの重いペイロード（セクション1.3で定義）を含めることはできません。未成年者を許可する
payload minimizes the number of initialization round trips, thus improving time-till-playback. Forbidding heavy payload prevents an amplification attack (see Section 12.1).
ペイロードは、初期化のラウンドトリップの数を最小限に抑え、再生までの時間を改善します。重いペイロードを禁止すると、増幅攻撃を防止できます（セクション12.1を参照）。
2. The receiving Peer Q checks the HANDSHAKE message from Peer P. If any check by Peer Q fails, or if Peers P and Q are not in the same swarm, Peer Q MUST NOT send a HANDSHAKE (or any other) message back, as the message from Peer P may have been spoofed (see Section 12.1). Otherwise, if Peer Q is interested in communicating with Peer P, Peer Q MUST send a datagram to Peer P that starts with a HANDSHAKE message. This reply HANDSHAKE MUST contain:
2. 受信側のピアQは、ピアPからのハンドシェイクメッセージをチェックします。ピアQによるチェックが失敗した場合、またはピアPとQが同じスウォームにない場合、ピアQは、ハンドシェイク（またはその他の）メッセージを送信しないでください。ピアPからのメッセージが偽装されている可能性があります（セクション12.1を参照）。それ以外の場合、ピアQがピアPとの通信に関心がある場合、ピアQは、ハンドシェイクメッセージで始まるデータグラムをピアPに送信する必要があります。この応答HANDSHAKEには、以下が含まれている必要があります。
* A channel ID, chanQ, randomly chosen as specified in Section 12.1.
* セクション12.1で指定されているようにランダムに選択されたチャネルID chanQ。
* The metadata of Swarm S, encoded as protocol options, as specified in Section 7. In particular, the responding Peer Q MAY include the swarm ID.
* セクション7で指定されているように、プロトコルオプションとしてエンコードされたSwarm Sのメタデータ。特に、応答するピアQには、Swarm IDが含まれる場合があります。
* The capabilities of Peer Q, in particular, its supported protocol versions, its "Live Discard Window" (in case of a live swarm) and "Supported Messages", encoded as protocol options.
* Peer Qの機能、特に、サポートされているプロトコルバージョン、その「ライブ破棄ウィンドウ」（ライブスウォームの場合）、およびプロトコルオプションとしてエンコードされた「サポートされているメッセージ」。
This reply datagram MUST be prefixed with the channel ID chanP sent by Peer P in the first HANDSHAKE message (see Section 3.11). This reply datagram MAY also contain some minor additional payload, e.g., HAVE messages to indicate Peer Q's current progress, or REQUEST messages (see Section 3.7), but it MUST NOT include any heavy payload.
この応答データグラムには、最初のHANDSHAKEメッセージでピアPから送信されたチャネルID chanPをプレフィックスとして付ける必要があります（セクション3.11を参照）。この応答データグラムには、ピアQの現在の進行状況を示すHAVEメッセージ、またはREQUESTメッセージ（セクション3.7を参照）などのマイナーな追加ペイロードも含まれる場合がありますが、重いペイロードを含めてはなりません（MUST NOT）。
3. The initiating Peer P checks the reply datagram from Peer Q. If the reply datagram is not prefixed with (destination) channel ID chanP, Peer P MUST discard the datagram. Peer P SHOULD continue to process datagrams from Peer Q that do meet this requirement. This check prevents interference by spoofing, see Section 12.1. If Peer P's channel ID is echoed correctly, the initiator Peer P knows that the addressed Peer Q really responds.
3. 開始ピアPは、ピアQからの応答データグラムをチェックします。応答データグラムの前に（宛先）チャネルID chanPが付いていない場合、ピアPはデータグラムを破棄する必要があります。ピアPは、この要件を満たしているピアQからのデータグラムを引き続き処理する必要があります（SHOULD）。このチェックは、なりすましによる干渉を防ぎます。セクション12.1を参照してください。ピアPのチャネルIDが正しくエコーされる場合、イニシエーターピアPは、アドレス指定されたピアQが実際に応答することを認識しています。
4. Next, Peer P checks the HANDSHAKE message in the datagram from Peer Q. If any check by Peer P fails, or Peer P is no longer interested in communicating with Peer Q, Peer P MAY send a HANDSHAKE message to inform Peer Q it will cease communication. This closing HANDSHAKE message MUST contain an all zeros channel ID and a list of protocol options. The list MUST either be empty or contain the maximum version number Peer P supports, following the min/max versioning scheme defined in [RFC6709], Section 4.1.
4. 次に、ピアPは、ピアQからのデータグラム内のHANDSHAKEメッセージをチェックします。ピアPによるチェックが失敗した場合、またはピアPがピアQとの通信に関心を持たなくなった場合、ピアPは、ハンドシェイクメッセージを送信してピアQに通知を中止することができます。コミュニケーション。この終了HANDSHAKEメッセージには、すべてゼロのチャネルIDとプロトコルオプションのリストが含まれている必要があります。 [RFC6709]のセクション4.1で定義されている最小/最大バージョン管理スキームに従って、リストは空であるか、ピアPがサポートする最大バージョン番号を含んでいる必要があります。
The datagram containing this closing HANDSHAKE message MUST be prefixed with the (destination) channel ID chanQ. Peer P MAY also simply cease communication.
この終了HANDSHAKEメッセージを含むデータグラムには、（宛先）チャネルID chanQをプレフィックスとして付ける必要があります。ピアPも単に通信を停止する場合があります。
5. If the addressed peer, Peer Q, does not respond to initiating Peer P's first datagram, Peer P MAY resend that datagram until Peer Q is considered dead, according to the rules specified in Section 3.12.
5. アドレス指定されたピア、ピアQがピアPの最初のデータグラムの開始に応答しない場合、ピアPは、セクション3.12で指定されたルールに従って、ピアQがデッドと見なされるまでそのデータグラムを再送信できます（MAY）。
6. If the reply datagram by Peer Q does pass the checks by Peer P, and Peer P wants to continue interacting with Peer Q, Peer P can now send REQUEST, PEX_REQ, and other messages to Peer Q. Datagrams carrying these messages MUST be prefixed with the channel ID chanQ sent by Peer Q. More specifically, because Peer P knows that Peer Q really responds, Peer P MAY start sending Peer Q messages with heavy payload. That means that Peer P MAY start responding to any REQUEST messages that Peer Q may have sent in this first reply datagram with DATA messages. Hence, transfer of chunks can start soon in PPSPP.
6. ピアQによる応答データグラムがピアPによるチェックに合格し、ピアPがピアQとの対話を継続したい場合、ピアPはREQUEST、PEX_REQ、およびその他のメッセージをピアQに送信できます。これらのメッセージを運ぶデータグラムの前により具体的には、Peer PはPeer Qが実際に応答することを知っているので、Peer Pは重いペイロードのあるPeer Qメッセージの送信を開始できます（MAY）。これは、ピアPが、ピアQがDATAメッセージを含むこの最初の応答データグラムで送信した可能性のあるすべてのREQUESTメッセージに応答し始める可能性があることを意味します。したがって、PPPSPではチャンクの転送がすぐに開始されます。
7. If Peer Q receives any datagram (apparently) from Peer P that does not contain channel ID chanQ, Peer Q MUST discard the datagram but SHOULD continue to process datagrams from Peer P that do meet this requirement. Once Peer Q receives a datagram from Peer P that does contain the channel ID chanQ, Peer Q knows that Peer P really received its reply datagram, and the three-way handshake and channel establishment is complete. Peer Q MAY now also start sending messages with heavy payload to Peer P.
7. ピアQがチャネルID chanQを含まないデータグラムをピアPから（明らかに）受信した場合、ピアQはデータグラムを破棄する必要がありますが、この要件を満たすピアPからのデータグラムの処理を続行する必要があります（SHOULD）。ピアQがチャネルID chanQを含むデータグラムをピアPから受信すると、ピアQはピアPが実際に応答データグラムを受信したことを認識し、3ウェイハンドシェイクとチャネルの確立が完了します。ピアQは、ペイロードが重いメッセージをピアPに送信することもできるようになりました。
8. If Peer P decides it no longer wants to communicate with Peer Q, or vice versa, the peer SHOULD send a closing HANDSHAKE message to the other, as described above.
8. ピアPがピアQとの通信をもう必要としないと決定した場合、またはその逆の場合、ピアは、上記のように、クローズHANDSHAKEメッセージを他方に送信する必要があります（SHOULD）。
The HAVE message is used to convey which chunks a peer has available for download. The set of chunks it has available may be expressed using different chunk addressing and availability map compression schemes, described in Section 4. HAVE messages can be used both for sending a complete overview of a peer's chunk availability as well as for updates to that set.
HAVEメッセージは、ピアがダウンロードできるチャンクを伝えるために使用されます。使用可能なチャンクのセットは、セクション4で説明されているように、さまざまなチャンクアドレッシングと可用性マップの圧縮スキームを使用して表現できます。HAVEメッセージは、ピアのチャンクの可用性の完全な概要の送信とそのセットの更新の両方に使用できます。
In particular, whenever a receiving Peer P has successfully checked the integrity of a chunk, or interval of chunks, it MUST send a HAVE message to all peers Q1..Qn it wants to allow to download those chunks. A policy in Peer P determines when the HAVE is sent. Peer P may send it directly, or Peer P may wait either until it has other data to send to Peer Qi or until it has received and checked multiple chunks. The policy will depend on how urgent it is to distribute this information to the other peers. This urgency is generally determined in turn by the chunk picking policy (see Section 9.1). In general, the HAVE messages can be piggybacked onto other messages. Peers that do not receive HAVE messages are effectively prevented from downloading the newly available chunks; hence, the HAVE message can be used as a method of choking.
特に、受信側のピアPがチャンクの整合性またはチャンクの間隔のチェックに成功した場合は常に、それらのチャンクのダウンロードを許可するすべてのピアQ1..QnにHAVEメッセージを送信する必要があります。ピアPのポリシーは、HAVEが送信されるタイミングを決定します。ピアPはそれを直接送信するか、ピアPがピアチーに送信する他のデータがあるか、複数のチャンクを受信して確認するまで待機します。ポリシーは、この情報を他のピアに配布することがいかに緊急であるかに依存します。この緊急度は、通常、チャンクピッキングポリシーによって決定されます（セクション9.1を参照）。一般に、HAVEメッセージは他のメッセージに便乗することができます。 HAVEメッセージを受信しないピアは、新しく利用可能なチャンクをダウンロードすることが事実上防止されます。したがって、HAVEメッセージは窒息の方法として使用できます。
The HAVE message MUST contain the chunk specification of the received and verified chunks. A receiving peer MUST NOT send a HAVE message to peers for which the handshake procedure is still incomplete, see Section 12.1. A peer SHOULD NOT send a HAVE message to peers that have the complete content already (e.g., in video-on-demand scenarios).
HAVEメッセージには、受信および検証されたチャンクのチャンク仕様が含まれている必要があります。受信側のピアは、ハンドシェイク手順がまだ完了していないピアにHAVEメッセージを送信してはなりません（セクション12.1を参照）。ピアは、完全なコンテンツをすでに持っているピアにHAVEメッセージを送信してはなりません（SHOULD NOT）（たとえば、ビデオオンデマンドシナリオの場合）。
The DATA message is used to transfer chunks of content. The DATA message MUST contain the chunk ID of the chunk and chunk itself. A peer MAY send the DATA messages for multiple chunks in the same datagram. The DATA message MAY contain additional information if needed by the specific congestion control mechanism used. At present, PPSPP uses LEDBAT [RFC6817] for congestion control, which requires the current system time to be sent along with the DATA message, so the current system time MUST be included.
DATAメッセージは、コンテンツのチャンクを転送するために使用されます。 DATAメッセージには、チャンクのチャンクIDとチャンク自体が含まれている必要があります。ピアは、同じデータグラム内の複数のチャンクのDATAメッセージを送信できます（MAY）。使用される特定の輻輳制御メカニズムで必要な場合、DATAメッセージに追加情報が含まれる場合があります。現在、PPSPPは輻輳制御にLEDBAT [RFC6817]を使用しており、現在のシステム時刻をDATAメッセージと共に送信する必要があるため、現在のシステム時刻を含める必要があります。
ACK messages MUST be sent to acknowledge received chunks if PPSPP is run over an unreliable transport protocol. ACK messages MAY be sent if a reliable transport protocol is used. In the former case, a receiving peer that has successfully checked the integrity of a chunk, or interval of chunks C, MUST send an ACK message containing a chunk specification for C. As LEDBAT is used, an ACK message MUST contain the one-way delay, computed from the peer's current system time received in the DATA message. A peer MAY delay sending ACK messages as defined in the LEDBAT specification [RFC6817].
PPSPPが信頼できないトランスポートプロトコルで実行されている場合は、受信したチャンクを確認するためにACKメッセージを送信する必要があります。信頼性の高いトランスポートプロトコルが使用されている場合は、ACKメッセージを送信できます。前者の場合、チャンクの整合性またはチャンクの間隔Cを正常にチェックした受信ピアは、Cのチャンク仕様を含むACKメッセージを送信する必要があります。LEDBATが使用されるため、ACKメッセージには一方向が含まれている必要がありますDATAメッセージで受信したピアの現在のシステム時間から計算された遅延。ピアは、LEDBAT仕様[RFC6817]で定義されているように、ACKメッセージの送信を遅延させる場合があります。
The INTEGRITY message carries information required by the receiver to verify the integrity of a chunk. Its payload depends on the content integrity protection scheme used. When the Merkle Hash Tree scheme is used, an INTEGRITY message MUST contain a cryptographic hash of a subtree of the Merkle hash tree and the chunk specification that identifies the subtree.
INTEGRITYメッセージは、受信者がチャンクの整合性を検証するために必要な情報を伝達します。そのペイロードは、使用されるコンテンツ整合性保護スキームに依存します。マークルハッシュツリースキームを使用する場合、INTEGRITYメッセージには、マークルハッシュツリーのサブツリーの暗号化ハッシュと、サブツリーを識別するチャンク仕様を含める必要があります。
As a typical example, when a peer wants to send a chunk and Merkle hash trees are used, it creates a datagram that consists of several INTEGRITY messages containing the hashes the receiver needs to verify the chunk and the actual chunk itself encoded in a DATA message. What are the necessary hashes and the exact rules for encoding them into datagrams is specified in Sections 5.3, and 5.4, respectively.
典型的な例として、ピアがチャンクを送信する必要があり、マークルハッシュツリーが使用されている場合、ピアは、チャンクを検証するために必要なハッシュとDATAメッセージにエンコードされた実際のチャンク自体を含む複数のINTEGRITYメッセージで構成されるデータグラムを作成します。必要なハッシュとそれらをデータグラムにエンコードするための正確なルールは、セクション5.3と5.4でそれぞれ指定されています。
The SIGNED_INTEGRITY message carries digitally signed information required by the receiver to verify the integrity of a chunk in live streaming. It logically contains a chunk specification, a timestamp, and a digital signature. Its exact payload depends on the live content integrity protection scheme used, see Section 6.1.
SIGNED_INTEGRITYメッセージは、ライブストリーミングでチャンクの整合性を検証するために受信者が必要とするデジタル署名された情報を伝達します。論理的には、チャンク仕様、タイムスタンプ、およびデジタル署名が含まれています。その正確なペイロードは、使用されるライブコンテンツの整合性保護スキームに依存します。セクション6.1を参照してください。
While bulk download protocols normally do explicit requests for certain ranges of data (i.e., use a pull model, for example, BitTorrent [BITTORRENT]), live streaming protocols quite often use a push model without requests to save round trips. PPSPP supports both models of operation.
一括ダウンロードプロトコルは通常、特定の範囲のデータに対して明示的な要求を行います（つまり、BitTorrent [BITTORRENT]などのプルモデルを使用します）が、ライブストリーミングプロトコルは、ラウンドトリップを節約する要求のないプッシュモデルを使用することがよくあります。 PPSPPは両方の動作モデルをサポートしています。
The REQUEST message is used to request one or more chunks from another peer. A REQUEST message MUST contain the specification of the chunks the requester wants to download. A peer receiving a REQUEST message MAY send out the requested chunks (by means of DATA messages). When Peer Q receives multiple REQUESTs from the same Peer P, Peer Q SHOULD process the REQUESTs in the order received. Multiple REQUEST messages MAY be sent in one datagram, for example, when a peer wants to request several rare chunks at once.
REQUESTメッセージは、別のピアに1つ以上のチャンクを要求するために使用されます。 REQUESTメッセージには、リクエスターがダウンロードしたいチャンクの仕様が含まれている必要があります。 REQUESTメッセージを受信するピアは、（DATAメッセージを使用して）要求されたチャンクを送信できます（MAY）。ピアQが同じピアPから複数の要求を受信すると、ピアQは受信した順序で要求を処理する必要があります（SHOULD）。たとえば、ピアがいくつかのまれなチャンクを一度に要求したい場合など、複数のREQUESTメッセージを1つのデータグラムで送信できます。
When live streaming via a push model, a peer receiving REQUESTs also MAY send some other chunks in case it runs out of requests or for some other reason. In that case, the only purpose of REQUEST messages is to provide hints and coordinate peers to avoid unnecessary data retransmission.
プッシュモデルを介したライブストリーミングの場合、REQUESTを受信するピアは、リクエストが不足した場合やその他の理由で、他のチャンクを送信する場合があります。その場合、REQUESTメッセージの唯一の目的は、不要なデータの再送信を回避するためのヒントを提供し、ピアを調整することです。
When downloading on-demand or live streaming content, a peer can request urgent data from multiple peers to increase the probability of it being delivered on time. In particular, when the specific chunk picking algorithm (see Section 9.1), detects that a request for urgent data might not be served on time, a request for the same data can be sent to a different peer. When a Peer P decides to request urgent data from a Peer Q, Peer P SHOULD send a CANCEL message to all the peers to which the data has been previously requested. The CANCEL message contains the specification of the chunks Peer P no longer wants to request. In addition, when Peer Q receives a HAVE message for the urgent data from Peer P, Peer Q MUST also cancel the previous REQUEST(s) from Peer P. In other words, the HAVE message acts as an implicit CANCEL.
オンデマンドまたはライブストリーミングコンテンツをダウンロードするとき、ピアは複数のピアに緊急データを要求して、時間どおりに配信される確率を高めることができます。特に、特定のチャンクピッキングアルゴリズム（セクション9.1を参照）が、緊急データの要求が時間どおりに処理されない可能性があることを検出すると、同じデータの要求を別のピアに送信できます。ピアPがピアQに緊急データを要求することを決定した場合、ピアPは、データが以前に要求されたすべてのピアにCANCELメッセージを送信する必要があります（SHOULD）。 CANCELメッセージには、ピアPが要求したくないチャンクの仕様が含まれています。さらに、ピアQがピアPから緊急データのHAVEメッセージを受信すると、ピアQはピアPからの以前の要求もキャンセルする必要があります。つまり、HAVEメッセージは暗黙的なキャンセルとして機能します。
Peer A can send a CHOKE message to Peer B to signal it will no longer be responding to REQUEST messages from Peer B, for example, because Peer A's upload capacity is exhausted. Peer A MAY send a subsequent UNCHOKE message to signal that it will respond to new REQUESTs from Peer B again (Peer A SHOULD discard old requests). When Peer B receives a CHOKE message from Peer A, it MUST NOT send new REQUEST messages and it cannot expect answers to any outstanding ones, as the transfer of chunks is choked. When Peer B is choked but receives a HAVE message from Peer A, it is not automatically unchoked and MUST NOT send any new REQUEST messages. The CHOKE and UNCHOKE messages are informational as responding to REQUESTs is OPTIONAL, see Section 3.7.
ピアAはCHOKEメッセージをピアBに送信して、ピアBからのREQUESTメッセージに応答しないことを通知できます。たとえば、ピアAのアップロード容量がなくなったためです。ピアAは、後続のUNCHOKEメッセージを送信して、ピアBからの新しい要求に再度応答することを通知できます（ピアAは古い要求を破棄する必要があります）。ピアBがピアAからCHOKEメッセージを受信すると、チャンクの転送が制限されるため、新しいREQUESTメッセージを送信してはならず、未解決のメッセージに対する応答を期待することはできません。ピアBがチョークされているがピアAからHAVEメッセージを受信した場合、それは自動的にチョークされず、新しいREQUESTメッセージを送信してはならない（MUST NOT）。リクエストへの応答はオプションであるため、CHOKEおよびUNCHOKEメッセージは情報メッセージです。セクション3.7を参照してください。
Peer Exchange (PEX) messages are common in many peer-to-peer protocols. They allow peers to exchange the transport addresses of the peers they are currently interacting with, thereby reducing the need to contact a central tracker (or Distributed Hash Table) to discovery new peers. The strength of this mechanism is therefore that it enables decentralized peer discovery: after an initial bootstrap, a central tracker is no longer needed. Its weakness is that it enables a number of attacks, so it should not be used on the Internet unless extra security measures are in place.
ピアエクスチェンジ（PEX）メッセージは、多くのピアツーピアプロトコルで一般的です。これにより、ピアは現在対話しているピアのトランスポートアドレスを交換できるため、中央のトラッカー（または分散ハッシュテーブル）に連絡して新しいピアを検出する必要がなくなります。したがって、このメカニズムの強みは、分散型ピア検出が可能になることです。最初のブートストラップの後、中央のトラッカーは不要になります。その弱点は、多くの攻撃を可能にすることです。そのため、追加のセキュリティ対策が講じられていない限り、インターネット上で使用しないでください。
PPSPP supports peer-address exchange on the Internet and in benign private networks as an OPTIONAL feature (not mandatory to implement) under certain conditions. The general mechanism works as follows. To obtain some peer addresses, a Peer A MAY send a PEX_REQ message to Peer B. Peer B MAY respond with one or more PEX_REScert messages. Logically, a PEX_REScert reply message contains the address of a single peer Ci. Peer B MUST have exchanged messages with Peer Ci in the last 60 seconds to guarantee liveliness. Upon receipt, Peer A may contact any or none of the returned peers Ci. Alternatively, peers MAY ignore PEX_REQ and PEX_REScert messages if uninterested in obtaining new peers or because of security considerations (rate limiting) or any other reason. The PEX messages can be used to construct a dedicated tracker peer.
PPSPPは、特定の条件下でのオプション機能（実装は必須ではない）として、インターネットおよび無害なプライベートネットワークでのピアアドレス交換をサポートします。一般的なメカニズムは次のように機能します。一部のピアアドレスを取得するには、ピアAがPEX_REQメッセージをピアBに送信してもよい（MAY）。ピアBは、1つ以上のPEX_REScertメッセージで応答してもよい（MAY）。論理的には、PEX_REScert応答メッセージには、単一のピアCiのアドレスが含まれています。ピアBは、生存を保証するために、過去60秒間にピアCiとメッセージを交換する必要があります。受信すると、ピアAは、返されたピアCiのいずれかに連絡することも、まったく連絡しないこともあります。あるいは、ピアは、新しいピアの取得に関心がない場合、またはセキュリティの考慮事項（レート制限）またはその他の理由により、PEX_REQおよびPEX_REScertメッセージを無視する場合があります。 PEXメッセージを使用して、専用のトラッカーピアを構築できます。
To use PEX in PPSPP on the Internet, two conditions must be met:
インターネット上のPPSSPPでPEXを使用するには、2つの条件を満たす必要があります。
1. Peer transport addresses must be relatively stable.
1. ピアトランスポートアドレスは比較的安定している必要があります。
2. A peer must not obtain all its peer addresses through PEX.
2. ピアは、PEXを通じてすべてのピアアドレスを取得することはできません。
The full security analysis for PEX messages can be found in Section 12.2. Physically, a PEX_REScert message carries a swarm-membership certificate rather than an IP address and port. A membership certificate for Peer C states that Peer C at address (ipC,portC) is part of Swarm S at Time T and is cryptographically signed by an issuer. The receiver Peer A can check the certificate for a valid signature by a trusted issuer, the right swarm, and liveliness and only then consider contacting C. These swarm-membership certificates correspond to signed node descriptors in secure decentralized peer sampling services [SPS].
PEXメッセージの完全なセキュリティ分析については、セクション12.2を参照してください。物理的には、PEX_REScertメッセージは、IPアドレスとポートではなく、Swarmメンバーシップ証明書を伝達します。ピアCのメンバーシップ証明書には、アドレス（ipC、portC）のピアCが時間TのスウォームSの一部であり、発行者によって暗号で署名されていることが記載されています。受信者のピアAは、信頼できる発行者、正しい群れ、および活性度による有効な署名について証明書をチェックし、その後Cに連絡することを検討できます。これらの群れメンバーシップ証明書は、安全な分散型ピアサンプリングサービス[SPS]の署名済みノード記述子に対応します。
Several designs are possible for the security environment for these membership certificates. That is, there are different designs possible for who signs the membership certificates and how public keys are distributed. Section 12.2.2 describes an example where a central tracker acts as the Certification Authority.
これらのメンバーシップ証明書のセキュリティ環境では、いくつかの設計が可能です。つまり、誰がメンバーシップ証明書に署名するか、および公開鍵がどのように配布されるかについて、さまざまな設計が可能です。セクション12.2.2では、中央トラッカーが認証局として機能する例について説明します。
In a hostile environment, such as the Internet, peers must also ensure that they do not end up interacting only with malicious peers when using the peer-address exchange feature. To this extent, peers MUST ensure that part of their connections are to peers whose addresses came from a trusted and secured tracker (see Section 12.2.3).
インターネットなどの敵対的な環境では、ピアは、ピアアドレス交換機能を使用するときに悪意のあるピアとのみ対話しないようにする必要もあります。この点で、ピアは、その接続の一部が、信頼できる安全なトラッカー（セクション12.2.3を参照）からのアドレスを持つピアへの接続であることを確認する必要があります。
In addition to the PEX_REScert, there are two other PEX reply messages. The PEX_RESv4 message contains a single IPv4 address and port. The PEX_RESv6 message contains a single IPv6 address and port. They MUST only be used in a benign environment, such as a private network, as they provide no guarantees that the host addressed actually participates in a PPSPP swarm.
PEX_REScertに加えて、他に2つのPEX応答メッセージがあります。 PEX_RESv4メッセージには、単一のIPv4アドレスとポートが含まれています。 PEX_RESv6メッセージには、単一のIPv6アドレスとポートが含まれています。これらは、アドレス指定されたホストが実際にPPSPPスウォームに参加していることを保証しないため、プライベートネットワークなどの無害な環境でのみ使用する必要があります。
Once a PPSPP implementation has obtained a list of peers (either via PEX, from a central tracker, or via a Distributed Hash Table (DHT)), it has to determine which peers to actually contact. In this process, a PPSPP implementation can benefit from information by network or content providers to help improve network usage and boost PPSPP performance. How a peer-to-peer (P2P) system like PPSPP can perform these optimizations using the Application-Layer Traffic Optimization (ALTO) protocol is described in detail in [RFC7285], Section 7.
PPSPP実装がピアのリストを取得すると（PEXを介して、中央トラッカーから、または分散ハッシュテーブル（DHT）を介して）、実際に接続するピアを決定する必要があります。このプロセスでは、PPSPP実装は、ネットワークまたはコンテンツプロバイダーによる情報の恩恵を受けて、ネットワークの使用を改善し、PPSPPのパフォーマンスを向上させることができます。 PPSPPのようなピアツーピア（P2P）システムがアプリケーション層トラフィック最適化（ALTO）プロトコルを使用してこれらの最適化を実行する方法については、[RFC7285]のセクション7で詳しく説明しています。
It is increasingly complex for peers to enable communication between each other due to NATs and firewalls. Therefore, PPSPP uses a multiplexing scheme, called channels, to allow multiple swarms to use the same transport address. Channels loosely correspond to TCP connections and each channel belongs to a single swarm, as illustrated in Figure 1. As with TCP connections, a channel is identified by a unique identifier local to the peer at each end of the connection (cf. TCP port), which MUST be randomly chosen. In other words, the two peers connected by a channel use different IDs to denote the same channel. The IDs are different and random for security reasons, see Section 12.1.
NATとファイアウォールにより、ピア間の相互通信を可能にすることはますます複雑になっています。したがって、PPPSPは、チャネルと呼ばれる多重化スキームを使用して、複数のスウォームが同じトランスポートアドレスを使用できるようにします。図1に示すように、チャネルはTCP接続に緩やかに対応し、各チャネルは単一のスウォームに属しています。TCP接続と同様に、チャネルは、接続の両端のピアにローカルな一意の識別子によって識別されます（TCPポートを参照）。 、ランダムに選択する必要があります。つまり、チャネルで接続された2つのピアは、異なるIDを使用して同じチャネルを示します。セキュリティ上の理由から、IDは異なり、ランダムです。セクション12.1を参照してください。
In the PPSP-over-UDP encapsulation (Section 8.3), when a Channel C has been established between Peer A and Peer B, the datagrams containing messages from Peer A to Peer B are prefixed with the four-byte channel ID allocated by Peer B, and vice versa for datagrams from Peer B to A. The channel IDs used are exchanged as part of the handshake procedure, see Section 8.4. In that procedure, the channel ID with value 0 is used for the datagram that initiates the handshake. PPSPP can be used in combination with Session Traversal Utilities for NAT (STUN) [RFC5389].
PPSP-over-UDPカプセル化（セクション8.3）では、ピアAとピアBの間にチャネルCが確立されている場合、ピアAからピアBへのメッセージを含むデータグラムには、ピアBによって割り当てられた4バイトのチャネルIDがプレフィックスとして付加されます。ピアBからAへのデータグラムの場合はその逆です。使用されるチャネルIDは、ハンドシェイク手順の一部として交換されます。セクション8.4を参照してください。その手順では、値0のチャネルIDが、ハンドシェイクを開始するデータグラムに使用されます。 PPSPPは、NAT用セッショントラバーサルユーティリティ（STUN）[RFC5389]と組み合わせて使用できます。
_________ _________ _________
| | | | | |
| Swarm | | Swarm | | Swarm |
| Mgr | | A | | B |
|_______| |_______| |_______|
| | / \
| | / \
____|____ ____|____ ______/__ _\_______
| | | | | | | |
| Chan | | Chan | | Chan | | Chan |
| 0 | | 481 | | 836 | | 372 |
|_______| |_______| |_______| |_______|
| | | |
| | | |
____|____________|____________|____________|____
| |
| UDP |
| port 6778 |
|______________________________________________|
Network stack of a PPSPP peer that is reachable on UDP port 6778 and is connected via channel 481 to one peer in Swarm A and two peers in Swarm B via channels 836 and 372, respectively. Channel ID 0 is special and is used for handshaking.
UDPポート6778で到達可能なPPSPPピアのネットワークスタック。チャネル481を介してSwarm Aの1つのピアとSwarm Bの2つのピアに、それぞれチャネル836と372を介して接続されます。チャネルID 0は特別であり、ハンドシェイクに使用されます。
Figure 1
図1
A peer SHOULD send a "keep alive" message periodically to each peer it is interested in, but has no other messages to send to them at present. The goal of the keep alives is to keep a signaling channel open to peers that are of interest. Which peers those are is determined by a policy that decides which peers are of interest now and in the near future. This document does not prescribe a policy, but examples of interesting peers are (a) peers that have chunks on offer that this client needs or (b) peers that currently do not have interesting chunks on offer (because they are still downloading themselves, or in live streaming) but gave good performance in the past. When these peers have new chunks to offer, the peer that kept a signaling channel open can use them again. Periodically sending "keep alive" messages prevents other peers declaring the peer dead. A guideline for declaring a peer dead when using UDP consists of a three minute delay since that last packet has been received from that peer and at least three datagrams having been sent to that peer during the same period. When a peer is declared dead, the channel to it is closed, no more messages will be sent to that peer and the local administration about the peer is discarded. Busy servers can force idle clients to disconnect by not sending keep alives. PPSPP does not define an explicit message type for "keep alive" messages. In the PPSP-over-UDP encapsulation they are implemented as simple datagrams consisting of a four-byte channel ID only, see Sections 8.3 and 8.4.
ピアは、関心のある各ピアに「キープアライブ」メッセージを定期的に送信する必要がありますが、現時点では他に送信するメッセージはありません。キープアライブの目的は、関心のあるピアに対してシグナリングチャネルを開いたままにすることです。それらがどのピアであるかは、どのピアが現在および近い将来に関心があるかを決定するポリシーによって決定されます。このドキュメントはポリシーを規定していませんが、興味深いピアの例は、（a）このクライアントが必要とする提供中のチャンクを持つピア、または（b）現在提供中の興味深いチャンクを持っていないピア（まだ自分自身をダウンロードしているため）、またはライブストリーミングでは）、過去には良好なパフォーマンスを示しました。これらのピアに提供する新しいチャンクがある場合、シグナリングチャネルを開いたままにしていたピアは、それらを再び使用できます。 「キープアライブ」メッセージを定期的に送信することで、他のピアがピアの停止を宣言することを防ぎます。 UDPを使用しているときにピアがデッドであることを宣言するためのガイドラインは、その最後のパケットがそのピアから受信されてから3分の遅延と、同じ期間中に少なくとも3つのデータグラムがそのピアに送信されていることです。ピアが無効であると宣言されると、そのピアへのチャネルが閉じられ、それ以上メッセージがそのピアに送信されなくなり、ピアに関するローカル管理が破棄されます。ビジー状態のサーバーは、キープアライブを送信しないことにより、アイドル状態のクライアントを強制的に切断できます。 PPSPPは、「キープアライブ」メッセージの明示的なメッセージタイプを定義していません。 PPSP-over-UDPカプセル化では、それらは4バイトのチャネルIDのみで構成される単純なデータグラムとして実装されます。セクション8.3および8.4を参照してください。
PPSPP can use different methods of chunk addressing, that is, support different ways of identifying chunks and different ways of expressing the chunk availability map of a peer in a compact fashion.
PPSSPPは、さまざまなチャンクアドレス指定方法を使用できます。つまり、さまざまな方法でチャンクを識別し、ピアのチャンク可用性マップをコンパクトに表現するさまざまな方法をサポートできます。
All peers in a swarm MUST use the same chunk addressing method.
スウォーム内のすべてのピアは、同じチャンクアドレス指定方法を使用する必要があります。
A chunk specification consists of a single (start specification,end specification) pair that identifies a range of chunks (end inclusive). The start and end specifications can use one of multiple addressing schemes. Two schemes are currently defined: chunk ranges and byte ranges.
チャンク仕様は、チャンクの範囲（両端を含む）を識別する単一の（開始仕様、終了仕様）ペアで構成されます。開始と終了の指定では、複数のアドレッシング方式のいずれかを使用できます。現在、2つのスキーマが定義されています。チャンク範囲とバイト範囲です。
The start and end specification are both chunk identifiers. Chunk identifiers are 32-bit or 64-bit unsigned integers. A PPSPP peer MUST support this scheme.
開始と終了の指定はどちらもチャンク識別子です。チャンク識別子は、32ビットまたは64ビットの符号なし整数です。 PPSPPピアはこのスキームをサポートする必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Start chunk (32 or 64) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ End chunk (32 or 64) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The start and end specification are 64-bit byte offsets in the content. The support for this scheme is OPTIONAL.
開始と終了の指定は、コンテンツ内の64ビットのバイトオフセットです。このスキームのサポートはオプションです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start byte offset (64) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End byte offset (64) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PPSPP introduces a novel method of addressing chunks of content called "bin numbers" (or "bins" for short). Bin numbers allow the addressing of a binary interval of data using a single integer. This reduces the amount of state that needs to be recorded per peer and the space needed to denote intervals on the wire, making the protocol lightweight. In general, this numbering system allows PPSPP to work with simpler data structures, e.g., to use arrays instead of binary trees, thus reducing complexity. The support for this scheme is OPTIONAL.
PPSPPは、「ビン番号」（または略して「ビン」）と呼ばれるコンテンツのチャンクに対処する新しい方法を導入します。ビン番号を使用すると、単一の整数を使用してデータのバイナリ間隔をアドレス指定できます。これにより、ピアごとに記録する必要がある状態の量と、回線上の間隔を示すために必要なスペースが削減され、プロトコルが軽量になります。一般に、この番号付けシステムにより、PPPSPはより単純なデータ構造で作業できます。たとえば、バイナリツリーの代わりに配列を使用して、複雑さを軽減できます。このスキームのサポートはオプションです。
In bin addressing, the smallest binary interval is a single chunk (e.g., a block of bytes that may be of variable size), the largest interval is a complete range of 2**63 chunks. In a novel addition to the classical scheme, these intervals are numbered in a way that lays them out into a vector nicely, which is called bin numbering, as follows. Consider a chunk interval of width W. To derive the bin numbers of the complete interval and the subintervals, a minimal balanced binary tree is built that is at least W chunks wide at the base. The leaves from left-to-right correspond to the chunks 0..W-1 in the interval, and have bin number I*2 where I is the index of the chunk (counting beyond W-1 to balance the tree). The bin number of higher-level node P in the tree is calculated as follows:
ビンアドレス指定では、最小のバイナリ間隔は単一のチャンク（たとえば、可変サイズのバイトのブロック）であり、最大の間隔は2 ** 63チャンクの完全な範囲です。古典的なスキームへの新しい追加では、これらの間隔は、次のように、ビン番号付けと呼ばれるベクトルにうまく配置する方法で番号が付けられます。幅Wのチャンク間隔を考えてみます。完全な間隔とサブ間隔のビン番号を導出するために、ベースで少なくともWチャンク幅の最小バランスバイナリツリーが構築されます。左から右への葉は区間のチャンク0..W-1に対応し、ビン番号I * 2を持ちます。ここで、Iはチャンクのインデックスです（ツリーのバランスをとるためにW-1を超えて数えます）。ツリー内の上位ノードPのビン番号は、次のように計算されます。
binP = (binL + binR) / 2
where binL is the bin of node P's left-hand child and binR is the bin of node P's right-hand child. Given that each node in the tree represents a subinterval of the original interval, each such subinterval now is addressable by a bin number, a single integer. The bin number tree of an interval of width W=8 looks like this:
ここで、binLはノードPの左側の子のビンで、binRはノードPの右側の子のビンです。ツリーの各ノードが元の間隔のサブインターバルを表すとすると、そのような各サブインターバルは、単一の整数であるビン番号でアドレス指定できるようになります。幅がW = 8の区間のビン番号ツリーは、次のようになります。
7
/ \
/ \
/ \
/ \
3 11
/ \ / \
/ \ / \
/ \ / \
1 5 9 13
/ \ / \ / \ / \
0 2 4 6 8 10 12 14
C0 C1 C2 C3 C4 C5 C6 C7
C0 C1 C2 C3 C4 C5 C6 C7
The bin number tree of an interval of width W=8
幅W = 8の間隔のビン番号ツリー
Figure 2
図2
So bin 7 represents the complete interval, bin 3 represents the interval of chunk C0..C3, bin 1 represents the interval of chunks C0 and C1, and bin 2 represents chunk C1. The special numbers 0xFFFFFFFF (32-bit) or 0xFFFFFFFFFFFFFFFF (64-bit) stands for an empty interval, and 0x7FFF...FFF stands for "everything".
したがって、ビン7は完全な間隔を表し、ビン3はチャンクC0..C3の間隔を表し、ビン1はチャンクC0とC1の間隔を表し、ビン2はチャンクC1を表します。特別な番号0xFFFFFFFF（32ビット）または0xFFFFFFFFFFFFFFFF（64ビット）は空の間隔を表し、0x7FFF ... FFFは「すべて」を表します。
When bin numbering is used, the ID of a chunk is its corresponding (leaf) bin number in the tree, and the chunk specification in HAVE and ACK messages is equal to a single bin number (32-bit or 64-bit), as follows.
ビン番号付けを使用する場合、チャンクのIDは、ツリー内の対応する（リーフ）ビン番号であり、HAVEおよびACKメッセージのチャンク指定は、次のように単一のビン番号（32ビットまたは64ビット）と等しくなります。続く。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Bin number (32 or 64) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When a receiving peer has successfully checked the integrity of a chunk or interval of chunks, it MUST send a HAVE message to all peers it wants to allow download of those chunk(s) from. The ability to withhold HAVE messages allows them to be used as a method of choking. The HAVE message MUST contain the chunk specification of the biggest complete interval of all chunks the receiver has received and checked so far that fully includes the interval of chunks just received. So the chunk specification MUST denote at least the interval received, but the receiver is supposed to aggregate and acknowledge bigger intervals, when possible.
受信ピアがチャンクまたはチャンクの間隔の整合性を正常にチェックした場合、それらのチャンクのダウンロードを許可するすべてのピアにHAVEメッセージを送信する必要があります。 HAVEメッセージを保留する機能により、メッセージを窒息の方法として使用できます。 HAVEメッセージには、受信者が受信してチェックしたすべてのチャンクの最大の完全な間隔のチャンク仕様が含まれている必要があります。これにより、受信したチャンクの間隔が完全に含まれます。したがって、チャンクの仕様では、少なくとも受信した間隔を示す必要がありますが、受信側は、可能な場合は、より大きな間隔を集約して確認する必要があります。
As a result, every single chunk is acknowledged a logarithmic number of times. That provides some necessary redundancy of acknowledgements and sufficiently compensates for unreliable transport protocols.
その結果、すべてのチャンクが対数で確認されます。これにより、確認応答の必要な冗長性が提供され、信頼性の低いトランスポートプロトコルが十分に補正されます。
Implementation note:
実装上の注意：
To record which chunks a peer has in the state that an implementation keeps for each peer, an implementation MAY use the efficient "binmap" data structure, which is a hybrid of a bitmap and a binary tree, discussed in detail in [BINMAP].
実装がピアごとに保持する状態でピアがどのチャンクを保持するかを記録するために、実装は、[BINMAP]で詳細に説明されている、ビットマップとバイナリツリーのハイブリッドである効率的な「binmap」データ構造を使用できます。
PPSPP peers MUST use ACK messages to acknowledge received chunks if an unreliable transport protocol is used. When a receiving peer has successfully checked the integrity of a chunk or interval of chunks C, it MUST send an ACK message containing the chunk specification of its biggest, complete interval covering C to the sending peer (see HAVE).
PPSPPピアは、信頼できないトランスポートプロトコルが使用されている場合、受信したチャンクを確認するためにACKメッセージを使用する必要があります。受信ピアがチャンクの整合性またはチャンクCの間隔のチェックに成功した場合、Cをカバーする最大の完全な間隔のチャンク仕様を含むACKメッセージを送信ピアに送信する必要があります（HAVEを参照）。
PPSPP can use different methods for protecting the integrity of the content while it is being distributed via the peer-to-peer network. More specifically, PPSPP can use different methods for receiving peers to detect whether a requested chunk has been maliciously modified by the sending peer. In benign environments, content integrity protection can be disabled.
PPSPPは、ピアツーピアネットワークを介して配信されているコンテンツの整合性を保護するために、さまざまな方法を使用できます。より具体的には、PPPSPはさまざまな方法で受信ピアを使用して、要求されたチャンクが送信ピアによって悪意を持って変更されたかどうかを検出できます。害のない環境では、コンテンツの整合性保護を無効にすることができます。
For static content, PPSPP currently defines one method for protecting integrity, called the Merkle Hash Tree scheme. If PPSPP operates over the Internet, this scheme MUST be used. If PPSPP operates in a benign environment, this scheme MAY be used. So the scheme is mandatory to implement, to satisfy the requirement of strong security for an IETF protocol [RFC3365]. An extended version of the scheme is used to efficiently protect dynamically generated content (live streams), as explained below and in Section 6.1.
静的コンテンツの場合、PPPSPは現在、完全性を保護するための1つの方法（マークルハッシュツリースキーム）を定義しています。 PPSPPがインターネット上で動作する場合は、このスキームを使用する必要があります。 PPSPPが無害な環境で動作している場合、このスキームを使用できます。したがって、このスキームは、IETFプロトコル[RFC3365]の強力なセキュリティの要件を満たすために、実装する必要があります。スキームの拡張バージョンは、以下およびセクション6.1で説明するように、動的に生成されたコンテンツ（ライブストリーム）を効率的に保護するために使用されます。
The Merkle Hash Tree scheme can work with different chunk addressing schemes. All it requires is the ability to address a range of chunks. In the following description abstract node IDs are used to identify nodes in the tree. On the wire, these are translated to the corresponding range of chunks in the chosen chunk addressing scheme.
マークルハッシュツリー方式は、さまざまなチャンクアドレス指定方式で機能します。必要なのは、一連のチャンクに対処する機能だけです。以下の説明では、抽象ノードIDを使用してツリー内のノードを識別します。ネットワーク上では、これらは選択されたチャンクアドレス指定スキームの対応する範囲のチャンクに変換されます。
PPSPP uses a method of naming content based on self-certification. In particular, content in PPSPP is identified by a single cryptographic hash that is the root hash in a Merkle hash tree calculated recursively from the content [ABMRKL]. This self-certifying hash tree allows every peer to directly detect when a malicious peer tries to distribute fake content. It also ensures only a small the amount of information is needed to start a download (the root hash and some peer addresses). For live streaming, a dynamic tree and a public key are used, see below.
PPSPPは、自己認証に基づいてコンテンツに名前を付ける方法を使用します。特に、PPSPPのコンテンツは、コンテンツから再帰的に計算されたマークルハッシュツリーのルートハッシュである単一の暗号化ハッシュによって識別されます[ABMRKL]。この自己認証ハッシュツリーにより、悪意のあるピアが偽のコンテンツを配信しようとしたときに、すべてのピアが直接検出できます。また、ダウンロードを開始するために必要な情報（ルートハッシュといくつかのピアアドレス）が少量で済むようにします。ライブストリーミングでは、動的ツリーと公開キーが使用されます。以下を参照してください。
The Merkle hash tree of a content file that is divided into N chunks is constructed as follows. Note the construction does not assume chunks of content to be of a fixed size. Given a cryptographic hash function, more specifically an MDC [HAC01], such as SHA-256, the hashes of all the chunks of the content are calculated. Next, a binary tree of sufficient height is created. Sufficient height means that the lowest level in the tree has enough nodes to hold all chunk hashes in the set, as with bin numbering. The figure below shows the tree for a content file consisting of 7 chunks. As with the content addressing scheme, the leaves of the tree correspond to a chunk and, in this case, are assigned the hash of that chunk, starting at the leftmost leaf. As the base of the tree may be wider than the number of chunks, any remaining leaves in the tree are assigned an empty hash value of all zeros. Finally, the hash values of the higher levels in the tree are calculated, by concatenating the hash values of the two children (again left to right) and computing the hash of that aggregate. If the two children are empty hashes, the parent is an empty all-zeros hash as well (to save computation). This process ends in a hash value for the root node, which is called the "root hash". Note the root hash only depends on the content and any modification of the content will result in a different root hash.
N個のチャンクに分割されたコンテンツファイルのマークルハッシュツリーは、次のように構築されます。構造は、コンテンツのチャンクが固定サイズであると想定していないことに注意してください。暗号化ハッシュ関数、より具体的にはSHA-256などのMDC [HAC01]を指定すると、コンテンツのすべてのチャンクのハッシュが計算されます。次に、十分な高さのバイナリツリーが作成されます。十分な高さは、ビンの番号付けと同様に、ツリーの最下位レベルに、セット内のすべてのチャンクハッシュを保持するのに十分なノードがあることを意味します。次の図は、7つのチャンクで構成されるコンテンツファイルのツリーを示しています。コンテンツアドレッシング方式と同様に、ツリーの葉はチャンクに対応し、この場合、左端の葉から始まるそのチャンクのハッシュが割り当てられます。ツリーのベースはチャンクの数よりも広い場合があるため、ツリー内の残りのリーフにはすべてゼロの空のハッシュ値が割り当てられます。最後に、2つの子のハッシュ値を（左から右に）連結し、その集計のハッシュを計算することにより、ツリーの上位レベルのハッシュ値が計算されます。 2つの子が空のハッシュである場合、親も空のすべてゼロのハッシュです（計算を保存するため）。このプロセスは、「ルートハッシュ」と呼ばれるルートノードのハッシュ値で終了します。ルートハッシュはコンテンツにのみ依存し、コンテンツを変更すると異なるルートハッシュが生成されることに注意してください。
7 = root hash
/ \
/ \
/ \
/ \
3* 11
/ \ / \
/ \ / \
/ \ / \
1 5 9 13* = uncle hash
/ \ / \ / \ / \
0 2 4 6 8 10* 12 14
C0 C1 C2 C3 C4 C5 C6 E
=chunk index ^^ = empty hash
Merkle hash tree of a content file with N=7 chunks
N = 7チャンクのコンテンツファイルのマークルハッシュツリー
Figure 3
図3
Assuming a peer receives the root hash of the content it wants to download from a trusted source, it can check the integrity of any chunk of that content it receives as follows. It first calculates the hash of the chunk it received, for example, chunk C4 in the previous figure. Along with this chunk, it MUST receive the hashes required to check the integrity of that chunk. In principle, these are the hash of the chunk's sibling (C5) and that of its "uncles". A chunk's uncles are the sibling Y of its parent X, and the uncle of that Y, recursively until the root is reached. For chunk C4, the uncles are nodes 13 and 3 and the sibling is 10; all marked with a * in the figure. Using this information, the peer recalculates the root hash of the tree and compares it to the root hash it received from the trusted source. If they match, the chunk of content has been positively verified to be the requested part of the content. Otherwise, the sending peer sent either the wrong content or the wrong sibling or uncle hashes. For simplicity, the set of sibling and uncle hashes is collectively referred to as the "uncle hashes".
ピアがダウンロードするコンテンツのルートハッシュを信頼できるソースから受信すると想定すると、次のように、受信したコンテンツのチャンクの整合性をチェックできます。最初に、受信したチャンク（前の図のチャンクC4など）のハッシュを計算します。このチャンクとともに、そのチャンクの整合性をチェックするために必要なハッシュを受信する必要があります。原則として、これらはチャンクの兄弟（C5）のハッシュとその「アンクル」のハッシュです。チャンクの叔父は、親Xの兄弟Yであり、そのYの叔父は、ルートに到達するまで再帰的になります。チャンクC4の場合、叔父はノード13と3で、兄弟は10です。図ではすべて*でマークされています。この情報を使用して、ピアはツリーのルートハッシュを再計算し、それを信頼できるソースから受信したルートハッシュと比較します。それらが一致する場合、コンテンツのチャンクはコンテンツの要求された部分であることが明確に確認されています。それ以外の場合、送信側ピアは、間違ったコンテンツまたは間違った兄弟または叔父のハッシュを送信しました。簡単にするために、兄弟と叔父のハッシュのセットをまとめて「叔父のハッシュ」と呼びます。
In the case of live streaming, the tree of chunks grows dynamically and the root hash is undefined or, more precisely, transient, as long as new data is generated by the live source. Section 6.1.2 defines a method for content integrity verification for live streams that works with such a dynamic tree. Although the tree is dynamic, content verification works the same for both live and predefined content, resulting in a unified method for both types of streaming.
ライブストリーミングの場合、新しいデータがライブソースによって生成される限り、チャンクのツリーは動的に成長し、ルートハッシュは未定義または正確には一時的です。セクション6.1.2は、このような動的ツリーで動作するライブストリームのコンテンツ整合性検証の方法を定義しています。ツリーは動的ですが、コンテンツ検証はライブコンテンツと定義済みコンテンツの両方で同じように機能するため、両方のタイプのストリーミングで統一された方法になります。
As explained above, a datagram consists of a sequence of messages. Ideally, every datagram sent must be independent of other datagrams: each datagram SHOULD be processed separately, and a loss of one datagram must not disrupt the flow of datagrams between two peers. Thus, as a datagram carries zero or more messages, both messages and message interdependencies SHOULD NOT span over multiple datagrams.
上記で説明したように、データグラムは一連のメッセージで構成されます。理想的には、送信されるすべてのデータグラムは他のデータグラムから独立している必要があります。各データグラムは個別に処理する必要があり（SHOULD）、1つのデータグラムの損失が2つのピア間のデータグラムのフローを妨害してはなりません。したがって、データグラムがゼロ以上のメッセージを運ぶので、メッセージとメッセージの相互依存性の両方は、複数のデータグラムにまたがってはなりません。
This principle implies that as any chunk is verified using its uncle hashes, the necessary hashes SHOULD be put into the same datagram as the chunk's data. If this is not possible because of a limitation on datagram size, the necessary hashes MUST be sent first in one or more datagrams. As a general rule, if some additional data is still missing to process a message within a datagram, the message SHOULD be dropped.
この原則は、任意のチャンクがその叔父のハッシュを使用して検証されるため、必要なハッシュをチャンクのデータと同じデータグラムに入れる必要があることを意味します。データグラムサイズの制限によりこれが不可能な場合は、必要なハッシュを1つ以上のデータグラムで最初に送信する必要があります。一般的なルールとして、データグラム内のメッセージを処理するために追加のデータがまだ不足している場合は、メッセージを削除する必要があります（SHOULD）。
The hashes necessary to verify a chunk are, in principle, its sibling's hash and all its uncle hashes, but the set of hashes to send can be optimized. Before sending a packet of data to the receiver, the sender inspects the receiver's previous acknowledgements (HAVE or ACK) to derive which hashes the receiver already has for sure. Suppose the receiver had acknowledged chunks C0 and C1 (the first two chunks of the file), then it must already have uncle hashes 5, 11, and so on. That is because those hashes are necessary to check C0 and C1 against the root hash. Then, hashes 3, 7, and so on must also be known as they are calculated in the process of checking the uncle hash chain. Hence, to send chunk C7, the sender needs to include just the hashes for nodes 14 and 9, which let the data be checked against hash 11, which is already known to the receiver.
チャンクの検証に必要なハッシュは、原則として、兄弟のハッシュとそのすべての叔父のハッシュですが、送信するハッシュのセットは最適化できます。データのパケットを受信者に送信する前に、送信者は受信者の以前の確認応答（HAVEまたはACK）を検査して、受信者がすでに持っているハッシュを確実に導き出します。受信者がチャンクC0とC1（ファイルの最初の2つのチャンク）を確認したとすると、アンクルハッシュ5、11などが既にあるはずです。これは、ルートハッシュに対してC0およびC1をチェックするためにこれらのハッシュが必要だからです。次に、ハッシュ3、7なども、叔父のハッシュチェーンをチェックするプロセスで計算されるため、既知でなければなりません。したがって、チャンクC7を送信するには、送信者はノード14と9のハッシュだけを含める必要があります。これにより、受信者には既知のハッシュ11に対してデータをチェックできます。
The sender MAY optimistically skip hashes that were sent out in previous, still-unacknowledged datagrams. It is an optimization trade-off between redundant hash transmission and the possibility of collateral data loss in the case in which some necessary hashes were lost in the network so some delivered data cannot be verified and thus had to be dropped. In either case, the receiver builds the Merkle hash tree on-demand, incrementally, starting from the root hash, and uses it for data validation.
送信者は、以前の未確認のデータグラムで送信されたハッシュを楽観的にスキップしてもよい（MAY）。これは、ネットワークで必要なハッシュが失われたために配信されたデータの一部を検証できず、ドロップする必要があった場合に、冗長ハッシュ送信と付随的なデータ損失の可能性との間の最適化のトレードオフです。どちらの場合でも、受信者はルートハッシュから始めて、オンデマンドで段階的にマークルハッシュツリーを構築し、データ検証に使用します。
In short, the sender MUST put into the datagram the hashes he believes are necessary for the receiver to verify the chunk. The receiver MUST remember all the hashes it needs to verify missing chunks that it still wants to download. Note that the latter implies that a hardware-limited receiver MAY forget some hashes if it does not plan to announce possession of these chunks to others (i.e., does not plan to send HAVE messages.)
要するに、送信者は受信者がチャンクを検証するために必要であると彼が信じているハッシュをデータグラムに入れなければなりません。受信者は、まだダウンロードしたい欠落したチャンクを検証するために必要なすべてのハッシュを覚えていなければなりません。後者は、これらのチャンクの所有を他の人に通知することを計画していない場合（つまり、HAVEメッセージを送信する予定がない場合）、ハードウェア限定のレシーバーが一部のハッシュを忘れる可能性があることを意味します。
Concretely, a peer that wants to send a chunk of content creates a datagram that MUST consist of a list of INTEGRITY messages followed by a DATA message. If the INTEGRITY messages and DATA message cannot be put into a single datagram because of a limitation on datagram size, the INTEGRITY messages MUST be sent first in one or more datagrams. The list of INTEGRITY messages sent MUST contain an INTEGRITY message for each hash the receiver misses for integrity checking. An INTEGRITY message for a hash MUST contain the chunk specification corresponding to the node ID of the hash and the hash data itself. The chunk specification corresponding to a node ID is defined as the range of chunks formed by the leaves of the subtree rooted at the node. For example, node 3 in Figure 3 denotes chunks 0, 2, 4, and 6, so the chunk specification should denote that interval. The list of INTEGRITY messages MUST be sorted in order of the tree height of the nodes, descending (the leaves are at height 0). The DATA message MUST contain the chunk specification of the chunk and the chunk itself. A peer MAY send the required messages for multiple chunks in the same datagram, depending on the encapsulation.
具体的には、コンテンツのチャンクを送信したいピアは、INTEGRITYメッセージとそれに続くDATAメッセージのリストで構成する必要があるデータグラムを作成します。 INTEGRITYメッセージとDATAメッセージをデータグラムサイズの制限のために単一のデータグラムに入れることができない場合、INTEGRITYメッセージは最初に1つまたは複数のデータグラムで送信する必要があります。送信されるINTEGRITYメッセージのリストには、受信者が整合性チェックで見逃したハッシュごとのINTEGRITYメッセージが含まれている必要があります。ハッシュのINTEGRITYメッセージには、ハッシュのノードIDとハッシュデータ自体に対応するチャンク仕様が含まれている必要があります。ノードIDに対応するチャンク仕様は、ノードをルートとするサブツリーの葉によって形成されるチャンクの範囲として定義されます。たとえば、図3のノード3はチャンク0、2、4、6を示しているため、チャンクの仕様はその間隔を示す必要があります。 INTEGRITYメッセージのリストは、ノードのツリーの高さの降順にソートする必要があります（葉は高さ0にあります）。 DATAメッセージには、チャンクのチャンク仕様とチャンク自体が含まれている必要があります。ピアは、カプセル化に応じて、同じデータグラム内の複数のチャンクに必要なメッセージを送信できます。
The current method for protecting content integrity in BitTorrent [BITTORRENT] is not suited for streaming. It involves providing clients with the hashes of the content's chunks before the download commences by means of metadata files (called .torrent files in BitTorrent.) However, when chunks are small, as in the current UDP encapsulation of PPSPP, this implies having to download a large number of hashes before content download can begin. This, in turn, increases time-till-playback for end users, making this method unsuited for streaming.
BitTorrent [BITTORRENT]でコンテンツの整合性を保護する現在の方法は、ストリーミングには適していません。メタデータファイル（BitTorrentでは.torrentファイルと呼ばれます）を使用してダウンロードを開始する前に、コンテンツのチャンクのハッシュをクライアントに提供します。ただし、現在のPPSPPのUDPカプセル化のようにチャンクが小さい場合、これはダウンロードする必要があるコンテンツのダウンロードを開始する前の多数のハッシュ。これにより、エンドユーザーの再生までの時間は長くなり、この方法はストリーミングには適さなくなります。
The overhead of using Merkle hash trees is limited. The size of the hash tree expressed as the total number of nodes depends on the number of chunks the content is divided (and hence the size of chunks) following this formula:
マークルハッシュツリーを使用するオーバーヘッドは制限されています。ノードの総数として表されるハッシュツリーのサイズは、次の式に従って、コンテンツが分割されるチャンクの数（およびチャンクのサイズ）に依存します。
nnodes = math.pow(2,math.log(nchunks,2)+1)
In principle, the hash values of all these nodes will have to be sent to a peer once for it to verify all of the chunks. Hence, the maximum on-the-wire overhead is hashsize * nnodes. However, the actual number of hashes transmitted can be optimized as described in Section 5.3.
原則として、すべてのチャンクを検証するには、これらすべてのノードのハッシュ値をピアに1回送信する必要があります。したがって、送信中のオーバーヘッドの最大値はhashsize * nnodesです。ただし、送信されるハッシュの実際の数は、セクション5.3で説明するように最適化できます。
To see a peer can verify all chunks whilst receiving not all hashes, consider the example tree in Section 5.1. In the case of a simple progressive download, of chunks 0, 2, 4, 6, etc., the sending peer will send the following hashes:
ピアがすべてのハッシュではなくすべてのチャンクを検証できることを確認するには、セクション5.1のツリーの例を検討してください。チャンク0、2、4、6などの単純なプログレッシブダウンロードの場合、送信側ピアは次のハッシュを送信します。
+-------+---------------------------------------------+
| Chunk | Node IDs of hashes sent |
+-------+---------------------------------------------+
| 0 | 2,5,11 |
| 2 | - (receiver already knows all) |
| 4 | 6 |
| 6 | - |
| 8 | 10,13 (hash 3 can be calculated from 0,2,5) |
| 10 | - |
| 12 | 14 |
| 14 | - |
| Total | # hashes 7 |
+-------+---------------------------------------------+
Table 1: Overhead for the Example Tree
表1：サンプルツリーのオーバーヘッド
So the number of hashes sent in total (7) is less than the total number of hashes in the tree (16), as a peer does not need to send hashes that are calculated and verified as part of earlier chunks.
したがって、ピアは以前のチャンクの一部として計算および検証されたハッシュを送信する必要がないため、送信されるハッシュの総数（7）はツリー内のハッシュの総数（16）よりも少なくなります。
In PPSPP, the size of a static content file, such as a video file, can be reliably and automatically derived from information received from the network when fixed-size chunks are used. As a result, it is not necessary to include the size of the content file as the metadata of the content for such files. Implementations of PPSPP MAY use this automatic detection feature. Note this feature is the only feature of PPSPP that requires that a fixed-size chunk is used. This feature builds on the Merkle hash tree and the trusted root hash as swarm ID as follows.
PPSPPでは、固定サイズのチャンクが使用されている場合、ビデオファイルなどの静的コンテンツファイルのサイズを、ネットワークから受信した情報から確実かつ自動的に導き出すことができます。その結果、コンテンツファイルのサイズを、そのようなファイルのコンテンツのメタデータとして含める必要はありません。 PPSPPの実装は、この自動検出機能を使用する場合があります。この機能はPPSPPの唯一の機能であり、固定サイズのチャンクを使用する必要があることに注意してください。この機能は、次のように、マークルハッシュツリーと信頼されたルートハッシュをスウォームIDとして構築します。
The ability for a newcomer peer to detect the size of the content depends heavily on the concept of peak hashes. The concept of peak hashes depends on the concepts of filled and incomplete nodes. Recall that when constructing the binary trees for content verification and addressing the base of the tree may have more leaves than the number of chunks in the content. In the Merkle hash tree, these leaves were assigned empty all-zero hashes to be able to calculate the higher-level hashes. A filled node is now defined as a node that corresponds to an interval of leaves that consists only of hashes of content chunks, not empty hashes. Reversely, an incomplete (not filled) node corresponds to an interval that also contains empty hashes, typically, an interval that extends past the end of the file. In the following figure, nodes 7, 11, 13, and 14 are incomplete: the rest is filled.
新規のピアがコンテンツのサイズを検出できるかどうかは、ピークハッシュの概念に大きく依存します。ピークハッシュの概念は、塗りつぶされたノードと不完全なノードの概念に依存します。コンテンツの検証のためにバイナリツリーを構築し、ツリーのベースをアドレス指定する場合、コンテンツ内のチャンクの数よりも多くの葉がある可能性があることを思い出してください。マークルハッシュツリーでは、より高いレベルのハッシュを計算できるように、これらの葉に空のすべてゼロのハッシュが割り当てられていました。塗りつぶされたノードは、空のハッシュではなく、コンテンツチャンクのハッシュのみで構成されるリーフの間隔に対応するノードとして定義されます。逆に、不完全な（満たされていない）ノードは、空のハッシュも含む間隔に対応します。通常は、ファイルの終わりを超えて延びる間隔です。次の図では、ノード7、11、13、および14は不完全です。残りは塗りつぶされています。
Formally, a peak hash is the hash of a filled node in the Merkle hash tree, whose sibling is an incomplete node. Practically, suppose a file is 7162 bytes long and a chunk is 1 kilobyte. That file fits into 7 chunks, the tail chunk being 1018 bytes long. The Merkle hash tree for that file is shown in Figure 4. Following the definition, the peak hashes of this file are in nodes 3, 9, and 12, denoted with an *. E denotes an empty hash.
正式には、ピークハッシュは、その兄弟が不完全なノードであるマークルハッシュツリー内の塗りつぶされたノードのハッシュです。実際には、ファイルの長さが7162バイト、チャンクが1キロバイトであるとします。そのファイルは7つのチャンクに収まり、テールチャンクは1018バイトの長さです。そのファイルのマークルハッシュツリーを図4に示します。定義に従って、このファイルのピークハッシュはノード3、9、および12にあり、*で示されています。 Eは空のハッシュを示します。
7
/ \
/ \
/ \
/ \
3* 11
/ \ / \
/ \ / \
/ \ / \
1 5 9* 13
/ \ / \ / \ / \
0 2 4 6 8 10 12* 14
C0 C1 C2 C3 C4 C5 C6 E = 1018 bytes
C0 C1 C2 C3 C4 C5 C6 E = 1018バイト
Peak hashes in a Merkle hash tree
マークルハッシュツリーのピークハッシュ
Figure 4
図4
Peak hashes can be explained by the binary representation of the number of chunks the file occupies. The binary representation for 7 is 111. Every "1" in binary representation of the file's packet length corresponds to a peak hash. For this particular file, there are indeed three peaks: nodes 3, 9, and 12. Therefore, the number of peak hashes for a file is also, at most, logarithmic with its size.
ピークハッシュは、ファイルが占めるチャンクの数のバイナリ表現で説明できます。 7のバイナリ表現は111です。ファイルのパケット長のバイナリ表現のすべての「1」は、ピークハッシュに対応します。この特定のファイルの場合、実際にはノード3、9、および12の3つのピークがあります。したがって、ファイルのピークハッシュの数も、最大でもサイズと対数です。
A peer knowing which nodes contain the peak hashes for the file can therefore calculate the number of chunks it consists of; thus, it gets an estimate of the file size (given all chunks but the last are of a fixed size). Which nodes are the peaks can be securely communicated from one (untrusted) peer, Peer A, to another peer, Peer B, by letting Peer A send the peak hashes and their node IDs to Peer B. It can be shown that the root hash that Peer B obtained from a trusted source is sufficient to verify that these are indeed the right peak hashes, as follows.
したがって、ファイルのピークハッシュがどのノードに含まれるかを知っているピアは、ファイルが構成するチャンクの数を計算できます。したがって、ファイルサイズの推定値を取得します（最後のチャンクを除くすべてのチャンクは固定サイズです）。どのノードがピークであるかは、ピアAにピークハッシュとそのノードIDをピアBに送信させることにより、ピアAからピアAに安全に通信できます。ルートハッシュが次のように、信頼できるソースから取得したピアBは、これらが実際に正しいピークハッシュであることを確認するのに十分であること。
Lemma: Peak hashes can be checked against the root hash.
補題：ピークハッシュはルートハッシュに対してチェックできます。
Proof: (a) Any peak hash is always the left sibling. Otherwise, if it is the right sibling, its left neighbor/sibling must also be a filled node, because of the way chunks are laid out in the leaves, which contradicts the definition of a peak hash. (b) For the rightmost peak hash, its right sibling is zero. (c) For any peak hash, the right sibling might be calculated using peak hashes to the left and zeros for empty nodes. (d) Once the right sibling of the leftmost peak hash is calculated, its parent might be calculated. (e) Once that parent is calculated, we might trivially get to the root hash by concatenating the hash with zeros and hashing it repeatedly.
証明：（a）ピークハッシュは常に左側の兄弟です。そうでない場合、それが正しい兄弟である場合、チャンクがリーフに配置される方法がピークハッシュの定義と矛盾するため、その左隣/兄弟も塗りつぶされたノードでなければなりません。 （b）右端のピークハッシュの場合、その右兄弟はゼロです。 （c）ピークハッシュの場合、右側の兄弟は、左側のピークハッシュと空のノードのゼロを使用して計算されます。 （d）左端のピークハッシュの右兄弟が計算されると、その親が計算される場合があります。 （e）親が計算されると、ハッシュをゼロで連結し、繰り返しハッシュすることにより、ルートハッシュに簡単に到達できる場合があります。
Informally, the Lemma might be expressed as follows: peak hashes cover all data, so the remaining hashes are either trivial (zeros) or might be calculated from peak hashes and zero hashes.
非公式には、補題は次のように表現されます。ピークハッシュはすべてのデータをカバーするため、残りのハッシュは取るに足らない（ゼロ）か、ピークハッシュとゼロハッシュから計算されます。
Finally, once Peer B has obtained the number of chunks in the content, it can determine the exact file size as follows. Given that all chunks except the last are of a fixed size, Peer B just needs to know the size of the last chunk. Knowing the number of chunks, Peer B can calculate the node ID of the last chunk and download it. As always, Peer B verifies the integrity of this chunk against the trusted root hash. As there is only one chunk of data that leads to a successful verification, the size of this chunk must be correct. Peer B can then determine the exact file size as:
最後に、ピアBがコンテンツのチャンクの数を取得すると、次のように正確なファイルサイズを決定できます。最後のものを除くすべてのチャンクが固定サイズであることを考えると、ピアBは最後のチャンクのサイズを知る必要があるだけです。チャンクの数がわかると、ピアBは最後のチャンクのノードIDを計算してダウンロードできます。いつものように、ピアBは、信頼されたルートハッシュに対してこのチャンクの整合性を検証します。検証の成功につながるデータのチャンクは1つしかないため、このチャンクのサイズは正しい必要があります。ピアBは、次のように正確なファイルサイズを決定できます。
(number of chunks -1) * fixed chunk size + size of last chunk
A PPSPP implementation that wants to use automatic size detection MUST operate as follows. When Peer A sends a DATA message for the first time to Peer B, Peer A MUST first send all the peak hashes for the content, in INTEGRITY messages, unless Peer B has already signaled that it knows the peak hashes by having acknowledged any chunk. If they are needed, the peak hashes MUST be sent as an extra list of uncle hashes for the chunk, before the list of actual uncle hashes of the chunk as described in Section 5.3. The receiver, Peer B, MUST check the peak hashes against the root hash to determine the approximate content size. To obtain the definite content size, Peer B MUST download the last chunk of the content from any peer that offers it.
自動サイズ検出を使用する必要があるPPSPP実装は、次のように動作する必要があります。ピアAが初めてDATAメッセージをピアBに送信するとき、ピアBがチャンクを確認してピークハッシュを認識していることをすでに通知していない限り、ピアAは最初にコンテンツのすべてのピークハッシュをINTEGRITYメッセージで送信する必要があります。それらが必要な場合、セクション5.3で説明されているように、チャンクの実際のアンクルハッシュのリストの前に、ピークハッシュをチャンクのアンクルハッシュの追加リストとして送信する必要があります。受信者であるピアBは、ピークハッシュをルートハッシュと照合して、おおよそのコンテンツサイズを決定する必要があります。明確なコンテンツサイズを取得するには、ピアBがコンテンツの最後のチャンクを、それを提供するピアからダウンロードする必要があります。
As an example, let's consider a 7162-byte file, which fits in 7 chunks of 1 kilobyte, distributed by Peer A. Figure 4 shows the relevant Merkle hash tree. Peer B, which only knows the root hash of the file after successfully connecting to Peer A, requests the first chunk of data, C0 in Figure 4. Peer A replies to Peer B by including in the datagram the following messages in this specific order: first, the three peak hashes of this particular file, the hashes of nodes 3, 9, and 12; second, the uncle hashes of C0, followed by the DATA message containing the actual content of C0. Upon receiving the peak hashes, Peer B checks them against the root hash determining that the file is 7 chunks long. To establish the exact size of the file, Peer B needs to request and retrieve the last chunk containing data, C6 in Figure 4. Once the last chunk has been retrieved and verified, Peer B concludes that it is 1018 bytes long, hence determining that the file is exactly 7162 bytes long.
例として、ピアAによって配布された1キロバイトの7つのチャンクに収まる7162バイトのファイルを考えてみましょう。図4は、関連するマークルハッシュツリーを示しています。ピアBは、ピアAへの接続に成功した後でファイルのルートハッシュのみを認識し、データの最初のチャンク（図4のC0）を要求します。ピアAは、次のメッセージをこの特定の順序でデータグラムに含めることにより、ピアBに応答します。最初に、この特定のファイルの3つのピークハッシュ、ノード3、9、および12のハッシュ。次に、叔父がC0のハッシュを作成し、その後にC0の実際の内容を含むDATAメッセージが続きます。ピークハッシュを受信すると、ピアBはそれらをルートハッシュと照合して、ファイルの長さが7チャンクであると判断します。ファイルの正確なサイズを確立するために、ピアBはデータを含む最後のチャンク（図4のC6）を要求して取得する必要があります。最後のチャンクが取得されて確認されると、ピアBはそれが1018バイトであると結論付け、次のように判断します。ファイルは正確に7162バイトです。
The set of messages defined above can be used for live streaming as well. In a pull-based model, a live streaming injector can announce the chunks it generates via HAVE messages, and peers can retrieve them via REQUEST messages. Areas that need special attention are content authentication and chunk addressing (to achieve an infinite stream of chunks).
上記で定義したメッセージのセットは、ライブストリーミングにも使用できます。プルベースのモデルでは、ライブストリーミングインジェクターはHAVEメッセージを介して生成するチャンクをアナウンスし、ピアはREQUESTメッセージを介してそれらを取得できます。特に注意が必要な領域は、コンテンツ認証とチャンクアドレス指定です（チャンクの無限ストリームを実現するため）。
For live streaming, PPSPP supports two methods for a peer to authenticate the content it receives from another peer, called "Sign All" and "Unified Merkle Tree".
ライブストリーミングの場合、PPPSPは、ピアが別のピアから受信したコンテンツを認証するために、「すべて署名」と「統合マークルツリー」という2つの方法をサポートしています。
In the "Sign All" method, the live injector signs each chunk of content using a private key. Upon receiving the chunk, peers check the signature using the corresponding public key obtained from a trusted source. Support for this method is OPTIONAL.
「すべてに署名」メソッドでは、ライブインジェクターは、秘密鍵を使用してコンテンツの各チャンクに署名します。チャンクを受信すると、ピアは信頼できるソースから取得した対応する公開鍵を使用して署名を確認します。このメソッドのサポートはオプションです。
In the "Unified Merkle Tree" method, PPSPP combines the Merkle Hash Tree scheme for static content with signatures to unify the video-on-demand and live streaming scenarios. The use of Merkle hash trees reduces the number of signing and verification operations, hence providing a similar signature amortization to the approach described in [SIGMCAST]. If PPSPP operates over the Internet, the "Unified Merkle Tree" method MUST be used. If the protocol operates in a benign environment, the "Unified Merkle Tree" method MAY be used. So this method is mandatory to implement.
「統合されたマークルツリー」方式では、PPSPPは静的コンテンツのマークルハッシュツリー方式と署名を組み合わせて、ビデオオンデマンドとライブストリーミングのシナリオを統合します。マークルハッシュツリーを使用すると、署名および検証操作の数が減るため、[SIGMCAST]で説明されているアプローチと同様の署名償却が提供されます。 PPSPPがインターネット上で動作する場合は、「Unified Merkle Tree」メソッドを使用する必要があります。プロトコルが無害な環境で動作する場合は、「Unified Merkle Tree」メソッドを使用できます。したがって、このメソッドの実装は必須です。
In both methods, the swarm ID consists of a public key encoded as in a DNSSEC DNSKEY resource record without Base64 encoding [RFC4034].
どちらの方法でも、スウォームIDは、Base64エンコードなしのDNSSEC DNSKEYリソースレコードのようにエンコードされた公開鍵で構成されます[RFC4034]。
In particular, the swarm ID consists of a 1-byte Algorithm field that identifies the public key's cryptographic algorithm and determines the format of the Public Key field that follows. The value of this Algorithm field is one of the values in the "Domain Name System Security (DNSSEC) Algorithm Numbers" registry [IANADNSSECALGNUM]. The RSASHA1 [RFC4034], RSASHA256 [RFC5702], ECDSAP256SHA256 and ECDSAP384SHA384 [RFC6605] algorithms are mandatory to implement.
特に、スウォームIDは、公開鍵の暗号化アルゴリズムを識別し、その後に続く公開鍵フィールドの形式を決定する1バイトのアルゴリズムフィールドで構成されます。このアルゴリズムフィールドの値は、「ドメインネームシステムセキュリティ（DNSSEC）アルゴリズム番号」レジストリ[IANADNSSECALGNUM]の値の1つです。 RSASHA1 [RFC4034]、RSASHA256 [RFC5702]、ECDSAP256SHA256およびECDSAP384SHA384 [RFC6605]アルゴリズムの実装は必須です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algo Number(8)| ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ DNSSEC Public Key (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In the "Sign All" method, the live injector signs each chunk of content using a private key and peers, upon receiving the chunk, check the signature using the corresponding public key obtained from a trusted source. In particular, in PPSPP, the swarm ID of the live stream is that public key.
「すべて署名」メソッドでは、ライブインジェクターは秘密鍵を使用してコンテンツの各チャンクに署名し、チャンクを受信したら、信頼できるソースから取得した対応する公開鍵を使用して署名を確認します。特にPPSPPでは、ライブストリームのスウォームIDがその公開鍵です。
A peer that wants to send a chunk of content creates a datagram that MUST contain a SIGNED_INTEGRITY message with the chunk's signature, followed by a DATA message with the actual chunk. If the SIGNED_INTEGRITY message and DATA message cannot be contained into a single datagram, because of a limitation on datagram size, the SIGNED_INTEGRITY message MUST be sent first in a separate datagram. The SIGNED_INTEGRITY message consists of the chunk specification, the timestamp, and the digital signature.
コンテンツのチャンクを送信するピアは、チャンクの署名付きのSIGNED_INTEGRITYメッセージと、その後に続く実際のチャンク付きのDATAメッセージを含む必要があるデータグラムを作成します。データグラムサイズの制限のために、SIGNED_INTEGRITYメッセージとDATAメッセージを単一のデータグラムに含めることができない場合は、SIGNED_INTEGRITYメッセージを最初に別のデータグラムで送信する必要があります。 SIGNED_INTEGRITYメッセージは、チャンク指定、タイムスタンプ、およびデジタル署名で構成されています。
The digital signature algorithm that is used, is determined by the Live Signature Algorithm protocol option, see Section 7.7. The signature is computed over a concatenation of the on-the-wire representation of the chunk specification, a 64-bit timestamp in NTP Timestamp format [RFC5905], and the chunk, in that order. The timestamp is the time signature that was made at the injector in UTC.
使用されるデジタル署名アルゴリズムは、ライブ署名アルゴリズムプロトコルオプションによって決定されます。セクション7.7を参照してください。署名は、チャンク仕様のオンザワイヤー表現、NTPタイムスタンプ形式[RFC5905]の64ビットタイムスタンプ、チャンクをこの順序で連結して計算されます。タイムスタンプは、UTCのインジェクターで作成された拍子です。
In this method, the chunks of content are used as the basis for a Merkle hash tree as for static content. However, because chunks are continuously generated, this tree is not static, but dynamic. As a result, the tree does not have a root hash, or, more precisely, it has a transient root hash. Therefore, a public key serves as swarm ID of the content. It is used to digitally sign updates to the tree allowing peers to expand it based on trusted information using the following process.
この方法では、静的コンテンツの場合と同様に、コンテンツのチャンクがマークルハッシュツリーの基礎として使用されます。ただし、チャンクは継続的に生成されるため、このツリーは静的ではなく動的です。その結果、ツリーにはルートハッシュがありません。より正確には、一時的なルートハッシュがあります。したがって、公開鍵はコンテンツのスウォームIDとして機能します。これは、ツリーの更新にデジタル署名するために使用され、ピアが次のプロセスを使用して信頼できる情報に基づいてツリーを展開できるようにします。
The live injector generates a number of chunks, denoted NCHUNKS_PER_SIG, corresponding to fixed power of 2 (NCHUNKS_PER_SIG>=2), which are added as new leaves to the existing hash tree. As a result of this expansion, the hash tree contains a new subtree that is NCHUNKS_PER_SIG chunks wide at the base. The root of this new subtree is referred to as the munro of that subtree, and its hash as the munro hash of the subtree, illustrated in Figure 5. In this figure, node 5 is the new munro, labeled with a $ sign.
ライブインジェクターは、2の固定べき数（NCHUNKS_PER_SIG> = 2）に対応するNCHUNKS_PER_SIGで示される多数のチャンクを生成し、既存のハッシュツリーに新しいリーフとして追加されます。この拡張の結果、ハッシュツリーには、ベースでNCHUNKS_PER_SIGチャンク幅の新しいサブツリーが含まれます。この新しいサブツリーのルートは、そのサブツリーのマンロと呼ばれ、そのハッシュは、サブツリーのマンロハッシュと呼ばれます（図5を参照）。この図では、ノード5が新しいマンロであり、$記号が付いています。
3
/ \
/ \
/ \
1 5$
/ \ / \
0 2 4 6
Expanded live tree. With NCHUNKS_PER_SIG=2, node 5 is the munro for the new subtree spanning 4 and 6. Node 1 is the munro for the subtree spanning chunks 0 and 2, created in the previous iteration.
展開されたライブツリー。 NCHUNKS_PER_SIG = 2の場合、ノード5は4および6にまたがる新しいサブツリーのマンローです。ノード1は、前の反復で作成されたチャンク0および2にまたがるサブツリーのマンロです。
Figure 5
図5
Informally, the process now proceeds as follows. The injector signs only the munro hash of the new subtree using its private key. Next, the injector announces the existence of the new subtree to its peers using HAVE messages. When a peer, in response to the HAVE messages, requests a chunk from the new subtree, the injector first sends the signed munro hash corresponding to the requested chunk. Afterwards, similar to static content, the injector sends the uncle hashes necessary to verify that chunk, as in Section 5.1. In particular, the injector sends the uncle hashes necessary to verify the requested chunk against the munro hash. This differs from static content, where the verification takes places against the root hash. Finally, the injector sends the actual chunk.
非公式には、プロセスは次のように進行します。インジェクターは、秘密鍵を使用して新しいサブツリーのmunroハッシュにのみ署名します。次に、インジェクタはHAVEメッセージを使用して、ピアに新しいサブツリーの存在を通知します。ピアがHAVEメッセージに応答して新しいサブツリーからチャンクを要求すると、インジェクターは最初に、要求されたチャンクに対応する署名されたmunroハッシュを送信します。その後、静的コンテンツと同様に、インジェクターは、セクション5.1のように、そのチャンクを検証するために必要な叔父のハッシュを送信します。特に、インジェクターは、要求されたチャンクをmunroハッシュに対して検証するために必要な叔父のハッシュを送信します。これは、ルートハッシュに対して検証が行われる静的コンテンツとは異なります。最後に、インジェクターは実際のチャンクを送信します。
The receiving peer verifies the signature on the signed munro using the swarm ID (a public key) and updates its hash tree. As the peer now knows the munro hash is trusted, it can verify all chunks in the subtree against this munro hash, using the accompanying uncle hashes as in Section 5.1.
受信ピアは、スウォームID（公開鍵）を使用して、署名されたmunroの署名を検証し、そのハッシュツリーを更新します。ピアは、munroハッシュが信頼できることを知っているので、セクション5.1のように、付随するuncleハッシュを使用して、このmunroハッシュに対してサブツリー内のすべてのチャンクを検証できます。
To illustrate this procedure, lets consider the next iteration in the process. The injector has generated the current tree shown in Figure 5, and it is connected to several peers that currently have the same tree and all posses chunks 0, 2, 4, and 6. When the injector generates two new chunks, NCHUNKS_PER_SIG=2, the hash tree expands as shown in Figure 6. The two new chunks, 8 and 10, extend the tree on the right side, and to accommodate them, a new root is created: node 7. As this tree is wider at the base than the actual number of chunks, there are currently two empty leaves. The munro node for the new subtree is 9, labeled with a $ sign.
この手順を説明するために、プロセスの次の反復を考えてみましょう。インジェクターは図5に示す現在のツリーを生成し、現在同じツリーとすべてのpossesチャンク0、2、4、および6を持ついくつかのピアに接続されています。インジェクターが2つの新しいチャンク、NCHUNKS_PER_SIG = 2を生成すると、ハッシュツリーは、図6に示すように拡張されます。2つの新しいチャンク8と10は、ツリーを右側に拡張し、それらに対応するために、新しいルートが作成されます。ノード7。このツリーは、チャンクの実際の数。現在、2つの空の葉があります。新しいサブツリーのmunroノードは9で、$記号のラベルが付けられています。
7
/ \
/ \
/ \
/ \
3 11
/ \ / \
/ \ / \
/ \ / \
1 5 9$ 13
/ \ / \ / \ / \
0 2 4 6 8 10 E E
Expanded live tree. With NCHUNKS_PER_SIG=2, node 9 is the munro of the newly added subtree spanning chunks 8 and 10.
展開されたライブツリー。 NCHUNKS_PER_SIG = 2の場合、ノード9は、チャンク8と10にまたがる新しく追加されたサブツリーのマンローです。
Figure 6
図6
The injector now needs to inform its peers of the updated tree, communicating the addition of the new munro hash 9. Hence, it sends a HAVE message with a chunk specification for nodes 8 + 10 to its peers. As a response, Peer P requests the newly created chunk, e.g., chunk 8, from the injector by sending a REQUEST message. In reply, the injector sends the signed munro hash of node 9 as an INTEGRITY message with the hash of node 9, and a SIGNED_INTEGRITY message with the signature of the hash of node 9. These messages are followed by an INTEGRITY message with the hash of node 10 and a DATA message with chunk 8.
インジェクターは、更新されたツリーをピアに通知し、新しいmunroハッシュ9の追加を通知する必要があります。したがって、ノード8 + 10のチャンク指定を含むHAVEメッセージをピアに送信します。応答として、ピアPはREQUESTメッセージを送信することにより、新しく作成されたチャンク（例：チャンク8）をインジェクターに要求します。応答として、インジェクターはノード9のハッシュ付きのINTEGRITYメッセージとして、ノード9のハッシュ付きのINTEGRITYメッセージとして、ノード9のハッシュ付きのSIGNED_INTEGRITYメッセージとして送信します。ノード10とチャンク8のDATAメッセージ。
Upon receipt, Peer P verifies the signature of the munro and expands its view of the tree. Next, the peer computes the hash of chunk 8 and combines it with the received hash of node 10, computing the expected hash of node 9. He can then verify the content of chunk 8 by comparing the computed hash of node 9 with the munro hash of the same node he just received; hence, Peer P has successfully verified the integrity of chunk 8.
ピアPは、受信すると、munroの署名を検証して、ツリーのビューを拡大します。次に、ピアはチャンク8のハッシュを計算し、それをノード10の受信したハッシュと結合して、ノード9の予想ハッシュを計算します。次に、計算されたノード9のハッシュとマンロハッシュを比較して、チャンク8の内容を検証できます。彼が受け取ったのと同じノードの;したがって、ピアPはチャンク8の整合性の検証に成功しています。
This procedure requires just one signing operation for every NCHUNKS_PER_SIG chunks created, and one verification operation for every NCHUNKS_PER_SIG received, making it much cheaper than "Sign All". A receiving peer does additionally need to check one or more hashes per chunk via the Merkle Hash Tree scheme, but this has less hardware requirements than a signature verification for every chunk. This approach is similar to signature amortization via Merkle Tree Chaining [SIGMCAST]. The downside of this scheme is in an increased latency. A peer cannot download the new chunks until the injector has computed the signature and announced the subtree. A peer MUST check the signature before forwarding the chunks to other peers [POLLIVE].
この手順では、作成されたNCHUNKS_PER_SIGチャンクごとに1つの署名操作と、受信されたNCHUNKS_PER_SIGごとに1つの検証操作が必要なため、「Sign All」よりもはるかに安価です。受信ピアはさらに、マークルハッシュツリースキームを介してチャンクごとに1つ以上のハッシュをチェックする必要がありますが、これはすべてのチャンクの署名検証よりもハードウェア要件が少なくなります。このアプローチは、Merkle Tree Chaining [SIGMCAST]による署名の償却と似ています。この方式の欠点は、レイテンシが増加することです。ピアは、インジェクタが署名を計算してサブツリーをアナウンスするまで、新しいチャンクをダウンロードできません。ピアは、チャンクを他のピアに転送する前に署名を確認する必要があります[POLLIVE]。
The number of chunks per signature NCHUNKS_PER_SIG MUST be a fixed power of 2 for simplicity. NCHUNKS_PER_SIG MUST be larger than 1 for performance reasons. There are two related factors to consider when choosing a value for NCHUNKS_PER_SIG. First, the allowed CPU load on clients due to signature verifications, given the expected bitrate of the stream. To achieve a low CPU load in a high bitrate stream, NCHUNKS_PER_SIG should be high. Second, the effect on latency, which increases when NCHUNKS_PER_SIG gets higher, as just discussed. Note how the procedure does not preclude the use of variable-size chunks.
シグニチャごとのチャンクの数NCHUNKS_PER_SIGは、単純化するために2の固定べき乗でなければなりません。パフォーマンス上の理由から、NCHUNKS_PER_SIGは1より大きくなければなりません。 NCHUNKS_PER_SIGの値を選択する際に考慮すべき2つの関連要因があります。まず、予想されるストリームのビットレートを前提として、署名検証によるクライアントの許容CPU負荷。高いビットレートのストリームで低いCPU負荷を実現するには、NCHUNKS_PER_SIGを高くする必要があります。次に、先ほど説明したように、NCHUNKS_PER_SIGが高くなると増加するレイテンシへの影響。プロシージャが可変サイズのチャンクの使用を排除しないことに注意してください。
This method of integrity verification provides an additional benefit. If the system includes some peers that saved the complete broadcast, as soon as the broadcast ends, the content is available as a video-on-demand download using the now stabilized tree and the final root hash as swarm identifier. Peers that saved all the chunks, can now announce the root hash to the tracking infrastructure and instantly seed the content.
この整合性検証の方法には、追加の利点があります。完全なブロードキャストを保存したピアがシステムに含まれている場合、ブロードキャストが終了するとすぐに、コンテンツは、安定化したツリーと最終ルートハッシュをスウォーム識別子として使用するビデオオンデマンドダウンロードとして利用できます。すべてのチャンクを保存したピアは、ルートハッシュを追跡インフラストラクチャに通知し、コンテンツをすぐにシードできます。
The digital signature algorithm used is determined by the Live Signature Algorithm protocol option, see Section 7.7. The signature is computed over a concatenation of the on-the-wire representation of the chunk specification of the munro node (see Section 6.1.2.1), a timestamp in 64-bit NTP Timestamp format [RFC5905], and the hash associated with the munro node, in that order. The timestamp is the time signature that was made at the injector in UTC.
使用されるデジタル署名アルゴリズムは、ライブ署名アルゴリズムプロトコルオプションによって決定されます。セクション7.7を参照してください。署名は、munroノードのチャンク仕様（セクション6.1.2.1を参照）のオンザワイヤ表現、64ビットNTPタイムスタンプ形式[RFC5905]のタイムスタンプ、およびに関連付けられたハッシュを連結して計算されます。 munroノード、この順序で。タイムスタンプは、UTCのインジェクターで作成された拍子です。
Formally, the injector MUST NOT send a HAVE message for chunks in the new subtree until it has computed the signed munro hash for that subtree.
正式には、インジェクタは、新しいサブツリーの署名付きmunroハッシュを計算するまで、新しいサブツリーのチャンクにHAVEメッセージを送信してはなりません（MUST NOT）。
When Peer B requests a chunk C from Peer A (either the injector or another peer), and Peer A decides to reply, it must do so as follows. First, Peer A MUST send an INTEGRITY message with the chunk specification for the munro of chunk C and the munro's hash, followed by a SIGNED_INTEGRITY message with the chunk specification for the munro, timestamp, and its signature in a single datagram, unless Peer B indicated earlier in the exchange that it already possess a chunk with the same corresponding munro (by means of HAVE or ACK messages). Following these two messages (if any), Peer A MUST send the necessary missing uncles hashes needed for verifying the chunk against its munro hash, and the chunk itself, as described in Section 5.4, sharing datagrams if possible.
ピアBがチャンクCをピアA（インジェクターまたは別のピア）に要求し、ピアAが応答することにした場合、次のようにする必要があります。最初に、ピアAは、チャンクCのマンロのチャンク仕様とマンロのハッシュを含むINTEGRITYメッセージを送信しなければならず、ピアBを除き、マンロ、タイムスタンプ、およびその署名のチャンク仕様を含むSIGNED_INTEGRITYメッセージを単一のデータグラムで送信する必要があります。 （HAVEまたはACKメッセージによって）同じ対応するmunroを持つチャンクをすでに所有していることを交換の初期に示した。これらの2つのメッセージ（存在する場合）に続いて、ピアAは、チャンクをmunroハッシュと照合するために必要な欠落している叔父のハッシュと、チャンク自体を送信する必要があります（5.4で説明）。
When a peer tunes in to a live stream, it has to determine what is the last chunk the injector has generated. To facilitate this process in the Unified Merkle Tree scheme, each peer shares its knowledge about the injector's chunks with the others by exchanging their latest signed munro hashes, as follows.
ピアがライブストリームに同調するとき、インジェクタが生成した最後のチャンクが何であるかを判断する必要があります。統一マークルツリースキームでこのプロセスを容易にするために、各ピアは、次のように、最新の署名付きマンロハッシュを交換することにより、インジェクタのチャンクに関する知識を他のピアと共有します。
Recall that, in PPSPP, when Peer A initiates a channel with Peer B, Peer A sends a first datagram with a HANDSHAKE message, and Peer B responds with a second datagram also containing a HANDSHAKE message (see Section 3.1). When Peer A sends a third datagram to Peer B, and it is received by Peer B, both peers know that the other is listening on its stated transport address. Peer B is then allowed to send heavy payload like DATA messages in the fourth datagram. Peer A can already safely do that in the third datagram.
PPSPPでは、ピアAがピアBとのチャネルを開始すると、ピアAがHANDSHAKEメッセージで最初のデータグラムを送信し、ピアBがHANDSHAKEメッセージを含む2番目のデータグラムで応答することを思い出してください（セクション3.1を参照）。ピアAが3番目のデータグラムをピアBに送信し、ピアBがそれを受信すると、両方のピアは、他方が指定されたトランスポートアドレスでリッスンしていることを認識します。次に、ピアBは、4番目のデータグラムのDATAメッセージのような重いペイロードを送信できます。ピアAは3番目のデータグラムですでに安全にそれを行うことができます。
In the Unified Merkle Tree scheme, Peer A MUST send its rightmost signed munro hash to Peer B in the third datagram, and in any subsequent datagrams to Peer B, until Peer B indicates that it possess a chunk with the same corresponding munro or a more recent munro (by means of a HAVE or ACK message). Peer B may already have indicated this fact by means of HAVE messages in the second datagram. Conversely, when Peer B sends the fourth datagram or any subsequent datagram to Peer A, Peer B MUST send its rightmost signed munro hash, unless Peer A indicated knowledge of it or more recent munros. The rightmost signed munro hash of a peer is defined as the munro hash signed by the injector of the rightmost subtree of width NCHUNKS_PER_SIG chunks in the peer's Merkle hash tree. Peer A MUST NOT send the signed munro hash in the first datagram of the HANDSHAKE procedure and Peer B MUST NOT send it in the second datagram as it is considered heavy payload.
統合されたマークルツリースキームでは、ピアAは、3番目のデータグラムで右端の署名されたマンロハッシュをピアBに送信し、ピアBが同じ対応するマンロ以上のチャンクを持つことをピアBが示すまで、ピアBに送信する必要があります最近のmunro（HAVEまたはACKメッセージによる）。ピアBは、2番目のデータグラムのHAVEメッセージによってこの事実をすでに示している可能性があります。逆に、ピアBが4番目のデータグラムまたは後続のデータグラムをピアAに送信する場合、ピアAがそれまたはそれより最近のマンロの知識を示さない限り、ピアBは右端の署名されたマンロハッシュを送信する必要があります。ピアの右端の署名済みmunroハッシュは、ピアのMerkleハッシュツリー内の幅NCHUNKS_PER_SIGチャンクの右端のサブツリーのインジェクターによって署名されたmunroハッシュとして定義されます。ピアAはHANDSHAKEプロシージャの最初のデータグラムで署名されたmunroハッシュを送信してはならず（MUST）、ピアBは2番目のデータグラムでそれを送信してはなりません。
When a peer receives a SIGNED_INTEGRITY message with a signed munro hash but the timestamp is too old, the peer MUST discard the message. Otherwise, it SHOULD use the signed munro to update its hash tree and pick a tune-in in the live stream. A peer may use the information from multiple peers to pick the tune-in point.
ピアが、署名されたmunroハッシュを含むSIGNED_INTEGRITYメッセージを受信したが、タイムスタンプが古すぎる場合、ピアはメッセージを破棄する必要があります。それ以外の場合は、署名されたmunroを使用してハッシュツリーを更新し、ライブストリームでチューンインを選択する必要があります（SHOULD）。ピアは、複数のピアからの情報を使用して、チューニングポイントを選択できます。
As a live broadcast progresses, a peer may want to discard the chunks that it already played out. Ideally, other peers should be aware of this fact so that they will not try to request these chunks from this peer. This could happen in scenarios where live streams may be paused by viewers, or viewers are allowed to start late in a live broadcast (e.g., start watching a broadcast at 20:35 when it actually began at 20:30).
ライブブロードキャストが進行するにつれて、ピアは、すでに再生したチャンクを破棄したい場合があります。理想的には、他のピアはこの事実を認識して、これらのチャンクをこのピアに要求しないようにする必要があります。これは、視聴者がライブストリームを一時停止したり、視聴者がライブブロードキャストの開始を遅らせたりするシナリオ（たとえば、実際には20:30に始まった放送を20:35に開始するなど）で発生する可能性があります。
PPSPP provides a simple solution for peers to stay up to date with the chunk availability of a discarding peer. A discarding peer in a live stream MUST enable the Live Discard Window protocol option, specifying how many chunks/bytes it caches before the last chunk/byte it advertised as being available (see Section 7.9). Its peers SHOULD apply this number as a sliding window filter over the peer's chunk availability as conveyed via its HAVE messages.
PPSPPは、ピアが破棄ピアのチャンクの可用性を最新に保つためのシンプルなソリューションを提供します。ライブストリームの破棄ピアは、ライブ破棄ウィンドウプロトコルオプションを有効にして、使用可能として通知された最後のチャンク/バイトの前にキャッシュするチャンク/バイトの数を指定する必要があります（セクション7.9を参照）。そのピアは、HAVEメッセージを介して伝達されるピアのチャンクの可用性に対するスライディングウィンドウフィルターとしてこの数を適用する必要があります（SHOULD）。
Three factors are important when deciding for an appropriate value for this option: the desired amount of playback buffer for peers, the bitrate of the stream, and the available resources of the peer. Consider the case of a fresh peer joining the stream. The size of the discard window of the peers it connects to influences how much data it can directly download to establish its prebuffer. If the window is smaller than the desired buffer, the fresh peer has to wait until the peers downloaded more of the stream before it can start playback. As media buffers are generally specified in terms of a number of seconds, the size of the discard window is also related to the (average) bitrate of the stream. Finally, if a peer has few resources to store chunks and metadata, it should choose a small discard window.
このオプションの適切な値を決定する場合、3つの要素が重要です。ピアの再生バッファーの望ましい量、ストリームのビットレート、ピアの使用可能なリソースです。新しいピアがストリームに参加する場合を考えてみましょう。接続先のピアの破棄ウィンドウのサイズは、プリバッファを確立するために直接ダウンロードできるデータの量に影響します。ウィンドウが目的のバッファーよりも小さい場合、新しいピアは、ピアが再生を開始する前に、さらに多くのストリームをダウンロードするまで待機する必要があります。メディアバッファーは通常、秒数で指定されるため、破棄ウィンドウのサイズは、ストリームの（平均）ビットレートにも関連しています。最後に、ピアにチャンクとメタデータを格納するためのリソースが少ない場合は、小さな破棄ウィンドウを選択する必要があります。
The HANDSHAKE message in PPSPP can contain the following protocol options. Unless stated otherwise, a protocol option consists of an 8-bit code followed by an 8-bit value. Larger values are all encoded big-endian. Each protocol option is explained in the following subsections. The list of protocol options MUST be sorted on code value (ascending) in a HANDSHAKE message.
PPSPPのHANDSHAKEメッセージには、次のプロトコルオプションを含めることができます。特に明記しない限り、プロトコルオプションは、8ビットコードとそれに続く8ビット値で構成されます。大きな値はすべてエンコードされたビッグエンディアンです。各プロトコルオプションについては、以下のサブセクションで説明します。プロトコルオプションのリストは、HANDSHAKEメッセージのコード値（昇順）でソートする必要があります。
+--------+-------------------------------------+
| Code | Description |
+--------+-------------------------------------+
| 0 | Version |
| 1 | Minimum Version |
| 2 | Swarm Identifier |
| 3 | Content Integrity Protection Method |
| 4 | Merkle Hash Tree Function |
| 5 | Live Signature Algorithm |
| 6 | Chunk Addressing Method |
| 7 | Live Discard Window |
| 8 | Supported Messages |
| 9 | Chunk Size |
| 10-254 | Unassigned |
| 255 | End Option |
+--------+-------------------------------------+
Table 2: PPSPP Options
表2：PPSSPPオプション
A peer MUST conclude the list of protocol options with the end option. Subsequent octets should be considered protocol messages. The code for the end option is 255, and unlike others, it has no value octet, so the option's length is 1 octet.
ピアは、プロトコルオプションのリストを終了オプションで結論付ける必要があります。後続のオクテットはプロトコルメッセージと見なされます。終了オプションのコードは255であり、他とは異なり、値のオクテットがないため、オプションの長さは1オクテットです。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+
A peer MUST include the maximum version of the PPSPP it supports as the first protocol option in the list. The code for this option is 0. Defined values are listed in Table 3.
ピアは、リストの最初のプロトコルオプションとして、サポートするPPSPPの最大バージョンを含める必要があります。このオプションのコードは0です。定義された値を表3に示します。
+---------+----------------------------------------+
| Version | Description |
+---------+----------------------------------------+
| 0 | Reserved |
| 1 | Protocol as described in this document |
| 2-255 | Unassigned |
+---------+----------------------------------------+
Table 3: PPSPP Version Numbers
表3：PPSSPPバージョン番号
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| Version (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When a peer initiates the handshake, it MUST include the minimum version of the PPSPP it supports in the list of protocol options, following the min/max versioning scheme defined in [RFC6709], Section 4.1, strategy 5. The code for this option is 1. Defined values are listed in Table 3.
ピアがハンドシェイクを開始するとき、サポートするPPSPPの最小バージョンをプロトコルオプションのリストに含める必要があります。[RFC6709]、セクション4.1、戦略5で定義された最小/最大バージョン管理スキームに従います。このオプションのコードは1.定義された値を表3に示します。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1| Min. Ver. (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When a peer initiates the handshake, it MUST include a single swarm identifier option. If the peer is not the initiator, it MAY include a swarm identifier option, as an end-to-end check. This option has the following structure:
ピアがハンドシェイクを開始するとき、単一のスウォーム識別子オプションを含める必要があります。ピアがイニシエータでない場合、エンドツーエンドのチェックとして、スウォーム識別子オプションを含めることができます（MAY）。このオプションの構造は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 0| Swarm ID Length (16) | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Swarm Identifier (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Swarm ID Length field contains the length of the single Swarm Identifier that follows in bytes. The Length field is 16 bits wide to allow for large public keys as identifiers in live streaming.
Swarm ID Lengthフィールドには、後に続く単一のSwarm Identifierの長さがバイトで含まれています。長さフィールドは16ビット幅で、ライブストリーミングで識別子として大きな公開鍵を使用できます。
Each PPSPP peer knows the IDs of the swarms it joins, so this information can be immediately verified upon receipt.
各PPSPPピアは、参加する群れのIDを知っているため、この情報は受信時にすぐに確認できます。
A peer MUST include the content integrity method used by a swarm. The code for this option is 3. Defined values are listed in Table 4.
ピアは、スウォームによって使用されるコンテンツ整合性メソッドを含める必要があります。このオプションのコードは3です。定義された値を表4に示します。
+--------+-------------------------+
| Method | Description |
+--------+-------------------------+
| 0 | No integrity protection |
| 1 | Merkle Hash Tree |
| 2 | Sign All |
| 3 | Unified Merkle Tree |
| 4-255 | Unassigned |
+--------+-------------------------+
Table 4: PPSPP Content Integrity Protection Methods
表4：PPSSPPコンテンツの完全性保護方法
The "Merkle Hash Tree" method is the default for static content, see Section 5.1. "Sign All", and "Unified Merkle Tree" are for live content, see Section 6.1, with "Unified Merkle Tree" being the default.
「マークルハッシュツリー」メソッドは、静的コンテンツのデフォルトです。セクション5.1を参照してください。 「Sign All」と「Unified Merkle Tree」はライブコンテンツ用です。セクション6.1を参照してください。「Unified Merkle Tree」がデフォルトです。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 1| CIPM (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When the content integrity protection method is "Merkle Hash Tree", this option defining which hash function is used for the tree MUST be included. The code for this option is 4. Defined values are listed in Table 5 (see [FIPS180-4] for the function semantics).
コンテンツの整合性保護方法が「マークルハッシュツリー」の場合、ツリーに使用するハッシュ関数を定義するこのオプションを含める必要があります。このオプションのコードは4です。定義された値を表5に示します（関数のセマンティクスについては[FIPS180-4]を参照してください）。
+----------+-------------+
| Function | Description |
+----------+-------------+
| 0 | SHA-1 |
| 1 | SHA-224 |
| 2 | SHA-256 |
| 3 | SHA-384 |
| 4 | SHA-512 |
| 5-255 | Unassigned |
+----------+-------------+
Table 5: PPSPP Merkle Hash Functions
表5：PPSPPマークルハッシュ関数
Implementations MUST support SHA-1 (see Section 12.5) and SHA-256. SHA-256 is the default.
実装はSHA-1（セクション12.5を参照）とSHA-256をサポートする必要があります。 SHA-256がデフォルトです。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0| MHF (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When the content integrity protection method is "Sign All" or "Unified Merkle Tree", this option MUST be defined. The code for this option is 5. The 8-bit value of this option is one of the values listed in the "Domain Name System Security (DNSSEC) Algorithm Numbers" registry [IANADNSSECALGNUM]. The RSASHA1 [RFC4034], RSASHA256 [RFC5702], ECDSAP256SHA256 and ECDSAP384SHA384 [RFC6605] algorithms are mandatory to implement. Default is ECDSAP256SHA256.
コンテンツの整合性保護方法が「すべて署名」または「統合マークルツリー」の場合、このオプションを定義する必要があります。このオプションのコードは5です。このオプションの8ビット値は、「ドメインネームシステムセキュリティ（DNSSEC）アルゴリズム番号」レジストリ[IANADNSSECALGNUM]にリストされている値の1つです。 RSASHA1 [RFC4034]、RSASHA256 [RFC5702]、ECDSAP256SHA256およびECDSAP384SHA384 [RFC6605]アルゴリズムの実装は必須です。デフォルトはECDSAP256SHA256です。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 1| LSA (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A peer MUST include the chunk addressing method it uses. The code for this option is 6. Defined values are listed in Table 6.
ピアは、使用するチャンクアドレス指定方法を含める必要があります。このオプションのコードは6です。定義された値を表6に示します。
+--------+---------------------+
| Method | Description |
+--------+---------------------+
| 0 | 32-bit bins |
| 1 | 64-bit byte ranges |
| 2 | 32-bit chunk ranges |
| 3 | 64-bit bins |
| 4 | 64-bit chunk ranges |
| 5-255 | Unassigned |
+--------+---------------------+
Table 6: PPSPP Chunk Addressing Methods
表6：PPSSPPチャンクアドレス指定方法
Implementations MUST support "32-bit chunk ranges" and "64-bit chunk ranges". Default is "32-bit chunk ranges".
実装は、「32ビットのチャンク範囲」および「64ビットのチャンク範囲」をサポートする必要があります。デフォルトは「32ビットのチャンク範囲」です。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 1 0| CAM (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A peer in a live swarm MUST include the discard window it uses. The code for this option is 7. The unit of the discard window depends on the chunk addressing method used, see Table 6. For bins and chunk ranges, it is a number of chunks; for byte ranges, it is a number of bytes. Its data type is the same as for a bin, or one value in a range specification. In other words, its value is a 32-bit or 64-bit integer in big-endian format. If this option is used, the Chunk Addressing Method MUST appear before it in the list. This option has the following structure:
ライブスウォームのピアには、使用する破棄ウィンドウを含める必要があります。このオプションのコードは7です。破棄ウィンドウの単位は、使用されるチャンクアドレス指定方法によって異なります。表6を参照してください。ビンとチャンクの範囲については、チャンクの数です。バイト範囲の場合、これはバイト数です。そのデータ型は、ビンの場合と同じか、範囲指定の1つの値です。つまり、その値はビッグエンディアン形式の32ビットまたは64ビット整数です。このオプションを使用する場合は、チャンクアドレス指定メソッドをリストの前に置く必要があります。このオプションの構造は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 1 1| Live Discard Window (32 or 64) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A peer that does not, under normal circumstances, discard chunks MUST set this option to the special value 0xFFFFFFFF (32-bit) or 0xFFFFFFFFFFFFFFFF (64-bit). For example, peers that record a complete broadcast to offer it directly as a static file after the broadcast ends use these values (see Section 6.1.2). Section 6.2 explains how to determine a value for this option.
通常の状況でチャンクを破棄しないピアは、このオプションを特別な値0xFFFFFFFFFF（32ビット）または0xFFFFFFFFFFFFFFFF（64ビット）に設定する必要があります。たとえば、完全なブロードキャストを記録して、ブロードキャストの終了後にそれを静的ファイルとして直接提供するピアは、これらの値を使用します（セクション6.1.2を参照）。セクション6.2では、このオプションの値を決定する方法について説明します。
Peers may support just a subset of the PPSPP messages. For example, peers running over TCP may not accept ACK messages or peers used with a centralized tracking infrastructure may not accept PEX messages. For these reasons, peers who support only a proper subset of the PPSPP messages MUST signal which subset they support by means of this protocol option. The code for this option is 8. The value of this option is a length octet (SupMsgLen) indicating the length, in bytes, of the compressed bitmap that follows.
ピアは、PPSPPメッセージのサブセットのみをサポートする場合があります。たとえば、TCPで実行されているピアはACKメッセージを受け入れない場合があり、集中型トラッキングインフラストラクチャで使用されるピアはPEXメッセージを受け入れない場合があります。これらの理由により、PPSPPメッセージの適切なサブセットのみをサポートするピアは、このプロトコルオプションによってサポートするサブセットを通知する必要があります。このオプションのコードは8です。このオプションの値は、後に続く圧縮ビットマップの長さ（バイト単位）を示す長さオクテット（SupMsgLen）です。
The set of messages supported can be derived from the compressed bitmap by padding it with bytes of value 0 until it is 256 bits in length. Then, a 1 bit in the resulting bitmap at position X (numbering left to right) corresponds to support for message type X, see Table 7. In other words, to construct the compressed bitmap, create a bitmap with a 1 for each message type supported and a 0 for a message type that is not, store it as an array of bytes, and truncate it to the last non-zero byte. An example of the first 16 bits of the compressed bitmap for a peer supporting every message except ACKs and PEXs is 11011001 11110000.
サポートされるメッセージのセットは、圧縮されたビットマップから、長さが256ビットになるまで、値0のバイトで埋め込むことによって導出できます。次に、結果のビットマップの位置X（左から右に番号付け）の1ビットは、メッセージタイプXのサポートに対応します。表7を参照してください。つまり、圧縮ビットマップを作成するには、メッセージタイプごとに1のビットマップを作成します。サポートされていないメッセージタイプの場合は0、それをバイトの配列として保存し、最後のゼロ以外のバイトに切り捨てます。 ACKおよびPEXを除くすべてのメッセージをサポートするピアの圧縮ビットマップの最初の16ビットの例は、11011001 11110000です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 0| SupMsgLen (8) | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Supported Messages Bitmap (variable, max 256) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A peer in a swarm MUST include the chunk size the swarm uses. The code for this option is 9. Its value is a 32-bit integer denoting the size of the chunks in bytes in big-endian format. When variable chunk sizes are used, this option MUST be set to the special value 0xFFFFFFFF. Section 8.1 explains how content publishers can determine a value for this option.
スウォームのピアには、スウォームが使用するチャンクサイズを含める必要があります。このオプションのコードは9です。その値は、ビッグエンディアン形式のチャンクのサイズをバイト単位で示す32ビット整数です。可変チャンクサイズを使用する場合、このオプションは特別な値0xFFFFFFFFに設定する必要があります。セクション8.1では、コンテンツ発行者がこのオプションの値を決定する方法について説明します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 1| Chunk Size (32) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+
PPSPP implementations MUST use UDP as transport protocol and MUST use LEDBAT for congestion control [RFC6817]. Using LEDBAT enables PPSPP to serve the content after playback (seeding) without disrupting the user who may have moved to different tasks that use its network connection. Future PPSPP versions can also run over other transport protocols or use different congestion control algorithms.
PPSPP実装は、UDPを転送プロトコルとして使用しなければならず、輻輳制御のためにLEDBATを使用しなければなりません[RFC6817]。 LEDBATを使用すると、PPSPPは、ネットワーク接続を使用する別のタスクに移動した可能性のあるユーザーを混乱させることなく、再生（シード）後にコンテンツを提供できます。 PPSPPの将来のバージョンでは、他のトランスポートプロトコルで実行したり、さまざまな輻輳制御アルゴリズムを使用したりすることもできます。
In general, a UDP datagram containing PPSPP messages SHOULD fit inside a single IP packet, so its maximum size depends on the MTU of the network. If the UDP datagram does not fit, its chance of getting lost in the network increases as the loss of a single fragment of the datagram causes the loss of the complete datagram.
一般に、PPPSPメッセージを含むUDPデータグラムは単一のIPパケット内に収まる必要があるため（SHOULD）、その最大サイズはネットワークのMTUによって異なります。 UDPデータグラムが適合しない場合、データグラムの単一のフラグメントが失われるとデータグラム全体が失われるため、ネットワークで失われる可能性が高くなります。
The largest message in a PPSPP datagram is the DATA message carrying a chunk of content. So the (maximum) size of a chunk to choose for a particular swarm depends primarily on the expected MTU. The chunk size should be chosen such that a chunk and its required INTEGRITY messages can generally be carried inside a single datagram, following the Atomic Datagram Principle (Section 5.3). Other considerations are the hardware capabilities of the peers. Having large chunks and therefore less chunks per megabyte of content reduces processing costs. The chunk addressing schemes can all work with different chunk sizes, see Section 4.
PPSPPデータグラムの最大のメッセージは、コンテンツのチャンクを運ぶDATAメッセージです。したがって、特定のスウォームに対して選択するチャンクの（最大）サイズは、主に予想されるMTUに依存します。チャンクのサイズは、チャンクとそれに必要なINTEGRITYメッセージが、通常、アトミックデータグラムの原則（5.3項）に従って単一のデータグラム内で伝送されるように選択する必要があります。他の考慮事項は、ピアのハードウェア機能です。チャンクが大きいため、コンテンツのメガバイトあたりのチャンクが少ないため、処理コストが削減されます。チャンクアドレス指定スキームは、すべて異なるチャンクサイズで機能します。セクション4を参照してください。
The RECOMMENDED approach is to use fixed-size chunks of 1024 bytes, as this size has a high likelihood of traveling end-to-end across the Internet without any fragmentation. In particular, with this size, a UDP datagram with a DATA message can be transmitted as a single IP packet over an Ethernet network with 1500-byte frames.
推奨されるアプローチは、1024バイトの固定サイズのチャンクを使用することです。このサイズは、断片化せずにインターネットをエンドツーエンドで移動する可能性が高いためです。特に、このサイズでは、DATAメッセージを含むUDPデータグラムは、1500バイトのフレームを持つイーサネットネットワークを介して単一のIPパケットとして送信できます。
A PPSPP implementation MAY use a variant of the Packetization Layer Path MTU Discovery (PLPMTUD), described in [RFC4821], for discovering the optimal MTU between sender and destination. As in PLPMTUD, progressively larger probing packets are used to detect the optimal MTU for a given path. However, in PPSPP, probe packets SHOULD contain actual messages, in particular, multiple DATA messages. By using actual DATA messages as probe packets, the returning ACK messages will confirm the probe delivery, effectively updating the MTU estimate on both ends of the link. To be able to scale up probe packets with sensible increments, a minimum chunk size of 512 bytes SHOULD be used. Smaller chunk sizes lead to an inefficient protocol. An implication is that PPSPP supports datagrams over IPv4 of 576 bytes or more only. This variant is not mandatory to implement.
PPSPP実装は、送信者と宛先の間の最適なMTUを発見するために、[RFC4821]で説明されているパケット化レイヤパスMTU発見（PLPMTUD）のバリアントを使用する場合があります。 PLPMTUDと同様に、徐々に大きくなるプローブパケットを使用して、特定のパスの最適なMTUを検出します。ただし、PPPSPでは、プローブパケットに実際のメッセージ、特に複数のDATAメッセージを含める必要があります（SHOULD）。実際のDATAメッセージをプローブパケットとして使用することにより、返されるACKメッセージはプローブ配信を確認し、リンクの両端のMTU推定を効果的に更新します。適切な増分でプローブパケットをスケールアップできるようにするには、512バイトの最小チャンクサイズを使用する必要があります（SHOULD）。チャンクサイズが小さいと、プロトコルが非効率になります。つまり、PPSPPは576バイト以上のIPv4を介したデータグラムのみをサポートします。このバリアントの実装は必須ではありません。
The chunk size used for a particular swarm, or the fact that it is variable, MUST be part of the swarm's metadata (which then minimally consists of the swarm ID and the chunk nature and size).
特定のスウォームに使用されるチャンクサイズ、またはそれが可変であるという事実は、スウォームのメタデータの一部である必要があります（メタデータは、スウォームIDとチャンクの性質およびサイズで最低限構成されます）。
When using UDP, the abstract datagram described above corresponds directly to a UDP datagram. Most messages within a datagram have a fixed length, which generally depends on the type of the message. The first byte of a message denotes its type. The currently defined types are:
UDPを使用する場合、上記の抽象データグラムはUDPデータグラムに直接対応します。データグラム内のほとんどのメッセージは固定長であり、通常はメッセージのタイプによって異なります。メッセージの最初のバイトはそのタイプを示します。現在定義されているタイプは次のとおりです。
+----------+------------------+
| Msg Type | Description |
+----------+------------------+
| 0 | HANDSHAKE |
| 1 | DATA |
| 2 | ACK |
| 3 | HAVE |
| 4 | INTEGRITY |
| 5 | PEX_RESv4 |
| 6 | PEX_REQ |
| 7 | SIGNED_INTEGRITY |
| 8 | REQUEST |
| 9 | CANCEL |
| 10 | CHOKE |
| 11 | UNCHOKE |
| 12 | PEX_RESv6 |
| 13 | PEX_REScert |
| 14-254 | Unassigned |
| 255 | Reserved |
+----------+------------------+
Table 7: PPSPP Message Types
表7：PPSSPPメッセージタイプ
Furthermore, integers are serialized in network (big-endian) byte order. So, consider the example of a HAVE message (Section 3.2) using bin chunk addressing. It has a message type of 0x03 and a payload of a bin number, a 4-byte integer (say, 1); hence, its on-the-wire representation for UDP can be written in hex as "0300000001".
さらに、整数はネットワーク（ビッグエンディアン）バイトオーダーでシリアル化されます。したがって、ビンチャンクアドレッシングを使用したHAVEメッセージの例（セクション3.2）を検討してください。メッセージタイプは0x03で、ビン番号のペイロードである4バイト整数（たとえば1）です。したがって、UDPのネットワーク上での表現は、16進数で "0300000001"と書くことができます。
All messages are idempotent or recognizable as duplicates. Idempotent means that processing a message more than once does not lead to a different state from if it was processed just once. In particular, a peer MAY resend DATA, ACK, HAVE, INTEGRITY, PEX_*, SIGNED_INTEGRITY, REQUEST, CANCEL, CHOKE, and UNCHOKE messages without problems when loss is suspected. When a peer resends a HANDSHAKE message, it can be recognized as duplicate by the receiver, because it already recorded the first connection attempt, and be dealt with.
すべてのメッセージはべき等であるか、重複として認識されます。べき等とは、メッセージを2回以上処理しても、メッセージが1回だけ処理された場合とは異なる状態にならないことを意味します。特に、損失が疑われる場合、ピアはDATA、ACK、HAVE、INTEGRITY、PEX _ *、SIGNED_INTEGRITY、REQUEST、CANCEL、CHOKE、およびUNCHOKEメッセージを問題なく再送信できます（MAY）。ピアがHANDSHAKEメッセージを再送信すると、すでに最初の接続試行が記録されており、処理されているため、受信者はそれを重複として認識できます。
As described in Section 3.11, PPSPP uses a multiplexing scheme, called channels, to allow multiple swarms to use the same UDP port. In the UDP encapsulation, each datagram from Peer A to Peer B is prefixed with the channel ID allocated by Peer B. The peers learn about each other's channel ID during the handshake as explained in Section 3.1.1. A channel ID consists of 4 bytes and MUST be generated following the requirements in [RFC4960] (Section 5.1.3).
セクション3.11で説明したように、PPSPPはチャネルと呼ばれる多重化スキームを使用して、複数のスウォームが同じUDPポートを使用できるようにします。 UDPカプセル化では、ピアAからピアBへの各データグラムには、ピアBによって割り当てられたチャネルIDがプレフィックスとして付けられます。ピアは、セクション3.1.1で説明されているように、ハンドシェイク中に互いのチャネルIDについて学習します。チャネルIDは4バイトで構成され、[RFC4960]（セクション5.1.3）の要件に従って生成する必要があります。
A channel is established with a handshake. To start a handshake, the initiating peer needs to know the swarm metadata, defined in Section 3.1 and the IP address and UDP port of a peer. A datagram containing a HANDSHAKE message then looks as follows:
チャネルはハンドシェイクで確立されます。ハンドシェイクを開始するには、開始ピアは、セクション3.1で定義されたスウォームメタデータと、ピアのIPアドレスとUDPポートを知っている必要があります。 HANDSHAKEメッセージを含むデータグラムは次のようになります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Channel ID (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| Source Channel ID (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Protocol Options ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
ただし：
Destination Channel ID:
宛先チャネルID：
If the datagram is sent by the initiating peer, then it MUST be an all-zeros channel ID.
データグラムが開始ピアによって送信される場合、それはすべてゼロのチャネルIDでなければなりません。
If the datagram is sent by the responding peer, then it MUST consist of the Source Channel ID from the sender's HANDSHAKE message.
データグラムが応答するピアによって送信される場合、送信者のHANDSHAKEメッセージからのソースチャネルIDで構成される必要があります。
The octet 0x00: The HANDSHAKE message type Source Channel ID: A locally unused channel ID
オクテット0x00：HANDSHAKEメッセージタイプソースチャネルID：ローカルで未使用のチャネルID
Protocol Options: A list of protocol options encoding the swarm's metadata, as defined in Section 7.
プロトコルオプション：セクション7で定義されている、スウォームのメタデータをエンコードするプロトコルオプションのリスト。
A peer SHOULD explicitly close a channel by sending a HANDSHAKE message that MUST contain an all zeros Source Channel ID and a list of protocol options. The list MUST either be empty or contain the maximum version number the sender supports, following the min/max versioning scheme defined in [RFC6709], Section 4.1.
ピアは、すべてゼロのソースチャネルIDとプロトコルオプションのリストを含む必要があるHANDSHAKEメッセージを送信して、チャネルを明示的に閉じる必要があります（SHOULD）。 [RFC6709]のセクション4.1で定義されている最小/最大バージョン管理スキームに従って、リストは空であるか、送信者がサポートする最大バージョン番号を含んでいる必要があります。
A HAVE message (type 0x03) consists of a single chunk specification that states that the sending peer has those chunks and successfully checked their integrity. The single chunk specification represents a consecutive range of verified chunks. A bin consists of a single integer, and a chunk or byte range of two integers, of the width specified by the Chunk Addressing protocol options, encoded big-endian.
HAVEメッセージ（タイプ0x03）は、送信側ピアにそれらのチャンクがあり、それらの整合性を正常にチェックしたことを示す単一のチャンク仕様で構成されています。単一チャンク仕様は、検証済みチャンクの連続した範囲を表します。ビンは、単一の整数と、チャンクまたはバイト範囲の2つの整数で構成され、その幅は、チャンクアドレッシングプロトコルオプションで指定された、ビッグエンディアンでエンコードされています。
A HAVE message using 32-bit chunk ranges as Chunk Addressing method:
チャンクアドレス指定方法として32ビットのチャンク範囲を使用するHAVEメッセージ：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 1| Start chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | End chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
where the first octet is the HAVE message (0x03) followed by the start chunk and the end chunk describing the chunk range. Note this diagram shows a message and not a datagram, so it is not prefixed by the destination Channel ID. This holds for all subsequent message diagrams.
ここで、最初のオクテットはHAVEメッセージ（0x03）で、その後にチャンクの範囲を表す開始チャンクと終了チャンクが続きます。この図はデータグラムではなくメッセージを示しているため、宛先チャネルIDが前に付いていないことに注意してください。これは、後続のすべてのメッセージ図に当てはまります。
A DATA message (type 0x01) consists of a chunk specification, a timestamp, and the actual chunk. In case a datagram contains one DATA message, a sender MUST always put the DATA message in the tail of the datagram. A datagram MAY contain multiple DATA messages when the chunk size is fixed and when none of the DATA messages carry the last chunk, if that is smaller than the chunk size. As LEDBAT congestion control is used, a sender MUST include a timestamp, in particular, a 64-bit integer representing the current system time with microsecond accuracy. The timestamp MUST be included between chunk specification and the actual chunk.
DATAメッセージ（タイプ0x01）は、チャンク指定、タイムスタンプ、および実際のチャンクで構成されます。データグラムに1つのDATAメッセージが含まれている場合、送信者は常にDATAメッセージをデータグラムの末尾に配置する必要があります。チャンクサイズが固定されていて、最後のチャンクがチャンクサイズよりも小さい場合、どのDATAメッセージにも最後のチャンクが含まれていない場合、データグラムには複数のDATAメッセージが含まれる場合があります。 LEDBAT輻輳制御が使用されるため、送信者はタイムスタンプ、特にマイクロ秒の精度で現在のシステム時間を表す64ビット整数を含める必要があります。タイムスタンプは、チャンク指定と実際のチャンクの間に含める必要があります。
A DATA message using 32-bit chunk ranges as Chunk Addressing method:
32ビットのチャンク範囲をチャンクアドレス指定方法として使用するDATAメッセージ：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1| Start chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | End chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp (64) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where the first octet is the DATA message (0x01) followed by the start chunk and the end chunk describing the single chunk, the timestamp, and the actual data.
ここで、最初のオクテットはDATAメッセージ（0x01）で、その後に開始チャンクと終了チャンクが続き、単一のチャンク、タイムスタンプ、および実際のデータを記述します。
An ACK message (type 0x02) acknowledges data that was received from its addressee; to comply with the LEDBAT delay-based congestion control, an ACK message consists of a chunk specification and a timestamp representing a one-way delay sample. The one-way delay sample is a 64-bit integer with microsecond accuracy, and it is computed from the timestamp received from the previous DATA message containing the chunk being acknowledged following the LEDBAT specification.
ACKメッセージ（タイプ0x02）は、宛先から受信したデータを確認します。 LEDBAT遅延ベースの輻輳制御に準拠するために、ACKメッセージはチャンク仕様と一方向遅延サンプルを表すタイムスタンプで構成されます。一方向の遅延サンプルは、マイクロ秒の精度を持つ64ビット整数であり、LEDBAT仕様に従って確認応答されているチャンクを含む以前のDATAメッセージから受信したタイムスタンプから計算されます。
An ACK message using 32-bit chunk ranges as Chunk Addressing method:
32ビットのチャンク範囲をチャンクアドレス指定方法として使用するACKメッセージ：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 0| Start chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | End chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| One-way delay sample (64) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
where the first octet is the ACK message (0x02) followed by the start chunk and the end chunk describing the chunk range and the one-way delay sample.
ここで、最初のオクテットはACKメッセージ（0x02）で、その後にチャンクの範囲と一方向の遅延サンプルを表す開始チャンクと終了チャンクが続きます。
An INTEGRITY message (type 0x04) consists of a chunk specification and the cryptographic hash for the specified chunk or node. The type and format of the hash depends on the protocol options.
INTEGRITYメッセージ（タイプ0x04）は、指定されたチャンクまたはノードのチャンク仕様と暗号化ハッシュで構成されます。ハッシュのタイプと形式は、プロトコルオプションによって異なります。
An INTEGRITY message using 32-bit chunk ranges as Chunk Addressing method and a SHA-256 hash:
32ビットのチャンク範囲をチャンクアドレス指定方法およびSHA-256ハッシュとして使用するINTEGRITYメッセージ：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0| Start chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | End chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Hash (256) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
where the first octet is the INTEGRITY message (0x04) followed by the
start chunk and the end chunk describing the chunk range and the
hash.
A SIGNED_INTEGRITY message (type 0x07) consists of a chunk specification, a 64-bit timestamp in NTP Timestamp format [RFC5905] and a digital signature encoded as a Signature field would be in an RRSIG record in DNSSEC without the Base64 encoding [RFC4034]. The signature algorithm is defined by the Live Signature Algorithm protocol option, see Section 7.7. The plaintext over which the signature is taken depends on the content integrity protection method used, see Section 6.1.
SIGNED_INTEGRITYメッセージ（タイプ0x07）は、チャンク仕様、NTPタイムスタンプ形式の64ビットタイムスタンプ[RFC5905]で構成され、署名フィールドとしてエンコードされたデジタル署名は、Base64エンコードなしのDNSSECのRRSIGレコードに含まれます[RFC4034]。署名アルゴリズムは、ライブ署名アルゴリズムプロトコルオプションで定義されます。セクション7.7を参照してください。署名に使用される平文は、使用されるコンテンツの整合性保護方法によって異なります。セクション6.1を参照してください。
A SIGNED_INTEGRITY message using 32-bit chunk ranges as Chunk Addressing method:
チャンクアドレッシングメソッドとして32ビットのチャンク範囲を使用するSIGNED_INTEGRITYメッセージ：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 1 1| Start chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | End chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp (64) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Signature ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where the first octet is the SIGNED_INTEGRITY message (0x07) followed by the start chunk and the end chunk describing the chunk range, the timestamp, and the Signature.
ここで、最初のオクテットはSIGNED_INTEGRITYメッセージ（0x07）であり、その後にチャンクの範囲、タイムスタンプ、および署名を記述する開始チャンクと終了チャンクが続きます。
The length of the digital signature can be derived from the Live Signature Algorithm protocol option and the swarm ID as follows. The first mandatory algorithms are RSASHA1 and RSASHA256. For those algorithms, the swarm ID consists of a 1-byte Algorithm field followed by an RSA public key stored as a tuple (exponent length, exponent, modulus) [RFC3110]. Given the exponent length and the length of the public key tuple in the swarm ID, the length of the modulus in bytes can be calculated. This yields the length of the signature, as in RSA this is the length of the modulus [HAC01]. The other mandatory algorithms are ECDSAP256SHA256 and ECDSAP384SHA384 [RFC6605]. For these algorithms, the length of the digital signature is 64 and 96 bytes, respectively.
デジタル署名の長さは、次のように、ライブ署名アルゴリズムプロトコルオプションと群IDから取得できます。最初の必須アルゴリズムは、RSASHA1およびRSASHA256です。これらのアルゴリズムの場合、スウォームIDは、1バイトのアルゴリズムフィールドと、それに続くタプル（指数長、指数、係数）として格納されたRSA公開鍵で構成されます[RFC3110]。指数の長さとスウォームIDの公開鍵タプルの長さを指定すると、バイト単位の係数の長さを計算できます。これにより、署名の長さが得られます。RSAの場合、これは係数[HAC01]の長さです。他の必須のアルゴリズムはECDSAP256SHA256とECDSAP384SHA384 [RFC6605]です。これらのアルゴリズムの場合、デジタル署名の長さはそれぞれ64バイトと96バイトです。
A REQUEST message (type 0x08) consists of a chunk specification for the chunks the requester wants to download.
REQUESTメッセージ（タイプ0x08）は、リクエスターがダウンロードしたいチャンクのチャンク仕様で構成されています。
A REQUEST message using 32-bit chunk ranges as Chunk Addressing method:
チャンクアドレッシング方式として32ビットのチャンク範囲を使用するREQUESTメッセージ：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 0| Start chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | End chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
where the first octet is the REQUEST message (0x08) followed by the start chunk and the end chunk describing the chunk range.
ここで、最初のオクテットはREQUESTメッセージ（0x08）で、その後にチャンクの範囲を表す開始チャンクと終了チャンクが続きます。
A CANCEL message (type 0x09) consists of a chunk specification for the chunks the requester no longer is interested in.
CANCELメッセージ（タイプ0x09）は、リクエスターが不要になったチャンクのチャンク指定で構成されています。
A CANCEL message using 32-bit chunk ranges as Chunk Addressing method:
チャンクアドレッシングメソッドとして32ビットのチャンク範囲を使用するCANCELメッセージ：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 1| Start chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | End chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
where the first octet is the CANCEL message (0x09) followed by the start chunk and the end chunk describing the chunk range.
ここで、最初のオクテットはCANCELメッセージ（0x09）で、その後に開始チャンクとチャンク範囲を説明する終了チャンクが続きます。
Both CHOKE and UNCHOKE messages (types 0x0a and 0x0b, respectively) carry no payload.
CHOKEおよびUNCHOKEメッセージ（それぞれタイプ0x0aおよび0x0b）は、ペイロードを伝送しません。
A CHOKE message:
チョークメッセージ：
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 1 0|
+-+-+-+-+-+-+-+-+
where the first octet is the CHOKE message (0x0a).
ここで、最初のオクテットはCHOKEメッセージ（0x0a）です。
An UNCHOKE message:
UNCHOKEメッセージ：
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 1 1|
+-+-+-+-+-+-+-+-+
where the first octet is the UNCHOKE message (0x0b).
ここで、最初のオクテットはUNCHOKEメッセージ（0x0b）です。
A PEX_REQ (0x06) message has no payload. A PEX_RESv4 (0x05) message consists of an IPv4 address in big-endian format followed by a UDP port number in big-endian format. A PEX_RESv6 (0x0c) message contains a 128-bit IPv6 address instead of an IPv4 one. If a PEX_REQ message does not originate from a private, unique-local, link-local, or multicast address [RFC1918] [RFC4193] [RFC4291], then the PEX_RES* messages sent in reply MUST NOT contain such addresses. This is to prevent leaking of internal addresses to external peers.
PEX_REQ（0x06）メッセージにはペイロードがありません。 PEX_RESv4（0x05）メッセージは、ビッグエンディアン形式のIPv4アドレスと、それに続くビッグエンディアン形式のUDPポート番号で構成されます。 PEX_RESv6（0x0c）メッセージには、IPv4アドレスの代わりに128ビットIPv6アドレスが含まれています。 PEX_REQメッセージがプライベート、一意ローカル、リンクローカル、またはマルチキャストアドレス[RFC1918] [RFC4193] [RFC4291]から発信されていない場合、返信で送信されるPEX_RES *メッセージにそのようなアドレスを含めてはなりません（MUST NOT）。これは、内部アドレスが外部ピアに漏洩するのを防ぐためです。
A PEX_REQ message:
PEX_REQメッセージ：
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 1 0|
+-+-+-+-+-+-+-+-+
where the first octet is the PEX_REQ message (0x06).
ここで、最初のオクテットはPEX_REQメッセージ（0x06）です。
A PEX_RESv4 message:
PEX_RESv4メッセージ：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 1| IPv4 Address (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Port (16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where the first octet is the PEX_RESv4 message (0x05) followed by the IPv4 address and the port number.
ここで、最初のオクテットはPEX_RESv4メッセージ（0x05）で、その後にIPv4アドレスとポート番号が続きます。
A PEX_RESv6 message:
PEX_RESv6メッセージ：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 1 0 0| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (128) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Port (16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where the first octet is the PEX_RESv6 message (0x0c), followed by the IPv6 address and the port number.
ここで、最初のオクテットはPEX_RESv6メッセージ（0x0c）であり、その後にIPv6アドレスとポート番号が続きます。
A PEX_REScert (0x0d) message consists of a 16-bit integer in big-endian specifying the size of the membership certificate that follows, see Section 12.2.1. This membership certificate states that Peer P at Time T is a member of Swarm S and is a X.509v3 certificate [RFC5280] that is encoded using the ASN.1 distinguished encoding rules (DER) [CCITT.X690.2002]. The certificate MUST contain a "Subject Alternative Name" extension, marked as critical, of type uniformResourceIdentifier.
PEX_REScert（0x0d）メッセージは、後に続くメンバーシップ証明書のサイズを指定するビッグエンディアンの16ビット整数で構成されます。セクション12.2.1を参照してください。このメンバーシップ証明書は、ピアTの時刻TがSwarm Sのメンバーであり、ASN.1識別符号化規則（DER）[CCITT.X690.2002]を使用して符号化されたX.509v3証明書[RFC5280]であることを示しています。証明書には、重要としてマークされた、uniformResourceIdentifierタイプの「Subject Alternative Name」拡張が含まれている必要があります。
A PEX_REScert message:
PEX_REScertメッセージ：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 1 0 1| Size of Memb. Cert. (16) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Membership Certificate ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where the first octet is the PEX_REScert message (0x0d) followed by the size of the membership certificate and the membership certificate.
ここで、最初のオクテットはPEX_REScertメッセージ（0x0d）で、その後にメンバーシップ証明書のサイズとメンバーシップ証明書が続きます。
The URL contained in the name extension MUST follow the generic syntax for URLs [RFC3986], where its scheme component is "file", the host in the authority component is the DNS name or IP address of Peer P, the port in the authority component is the port of Peer P, and the path contains the swarm identifier for Swarm S, in hexadecimal form. In particular, the preferred form of the swarm identifier is xxyyzz..., where the 'x's, 'y's, and 'z's are 2 hexadecimal digits of the 8-bit pieces of the identifier. The validity time of the certificate is set with notBefore UTCTime set to T and notAfter UTCTime set to T plus some expiry time defined by the issuer. An example URL:
名前拡張子に含まれるURLは、URLの一般的な構文[RFC3986]に従う必要があります。そのスキームコンポーネントは「ファイル」であり、機関コンポーネントのホストはピアPのDNS名またはIPアドレス、機関コンポーネントのポートです。ピアPのポートです。パスには、16進形式のSwarm Sのswarm識別子が含まれています。特に、スウォーム識別子の推奨される形式はxxyyzz ...です。ここで、「x」、「y」、および「z」は、識別子の8ビット部分の2つの16進数です。証明書の有効期間は、notBefore UTCTimeをTに設定し、notAfter UTCTimeをTに設定し、さらに発行者が定義した有効期限を設定して設定します。 URLの例：
file://192.0.2.0:6778/e5a12c7ad2d8fab33c699d1e198d66f79fa610c3
Keep alives do not have a message type on UDP. They are just simple datagrams consisting of the 4-byte channel ID of the destination only.
キープアライブには、UDPのメッセージタイプはありません。これらは、宛先の4バイトのチャネルIDのみで構成される単純なデータグラムです。
A keep-alive datagram:
キープアライブデータグラム：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel ID (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Explicit flow control is not required for PPSPP over UDP. In the case of video on demand, the receiver explicitly requests the content from peers, and is therefore in control of how much data is coming towards it. In the case of live streaming, where a push model may be used, the amount of data incoming is limited to the stream bitrate, which the receiver must be able to process for a continuous playback. Should, for any reason, the receiver get saturated with data, the congestion control at the sender side will detect the situation and adjust the sending rate accordingly.
PPSPP over UDPでは、明示的なフロー制御は必要ありません。ビデオオンデマンドの場合、受信者はピアにコンテンツを明示的に要求するため、コンテンツの量を制御できます。プッシュモデルを使用できるライブストリーミングの場合、受信するデータの量はストリームのビットレートに制限されます。これは、レシーバーが連続再生のために処理できる必要があります。何らかの理由で受信側がデータで飽和すると、送信側の輻輳制御が状況を検出し、それに応じて送信速度を調整します。
PPSPP over UDP can support different congestion control algorithms. At present, it uses the LEDBAT congestion control algorithm [RFC6817]. LEDBAT is a delay-based congestion control algorithm that is used every day by millions of users as part of the uTP transmission protocol of BitTorrent [LBT] [LCOMPL] and is suitable for P2P streaming [PPSPPERF].
PPSPP over UDPは、さまざまな輻輳制御アルゴリズムをサポートできます。現在、LEDBAT輻輳制御アルゴリズム[RFC6817]を使用しています。 LEDBATは、BitTorrent [LBT] [LCOMPL]のuTP送信プロトコルの一部として何百万ものユーザーによって毎日使用されている遅延ベースの輻輳制御アルゴリズムであり、P2Pストリーミング[PPSPPERF]に適しています。
LEDBAT monitors the delay of the packets on the data path. It uses the one-way delay variations to react early and limit the congestion that the stream may induce in the network [RFC6817]. Using LEDBAT enables PPSPP to serve the content to other interested peers after the playback has finished (seeding), without disrupting the user. After the playback, the user might move to different tasks that use its network link, which are prioritized over PPSPP traffic. Hence, the user does not notice the background PPSPP traffic, which in turn increases the chances of seeding the content for a longer period of time.
LEDBATは、データパス上のパケットの遅延を監視します。一方向の遅延変動を使用して早期に反応し、ネットワークでストリームが引き起こす可能性のある輻輳を制限します[RFC6817]。 LEDBATを使用すると、PPSPPは、ユーザーの作業を中断することなく、再生の終了（シード）後に他の関係のあるピアにコンテンツを提供できます。再生後、ユーザーは、PPSPPトラフィックよりも優先される、ネットワークリンクを使用する別のタスクに移動する場合があります。したがって、ユーザーはバックグラウンドのPPSPPトラフィックに気付かず、その結果、コンテンツを長期間シードする可能性が高くなります。
The property of reacting early is not a problem in a peer-to-peer system where multiple sources offer the content. Considering the case of congestion near the sender, LEDBAT's early reaction impacts the transmission of chunks to the receiver. However, for the receiver, it is actually beneficial to learn early that the transmission from a particular source is impacted. The receiver can then choose to download time-critical chunks from other sources during its chunk picking phase.
複数のソースがコンテンツを提供するピアツーピアシステムでは、早期に反応するという特性は問題ではありません。送信者の近くの輻輳の場合を考えると、LEDBATの初期の反応は、チャンクの受信者への送信に影響を与えます。ただし、受信者にとっては、特定のソースからの送信が影響を受けることを早期に知ることが実際に有益です。受信者は、チャンクピッキングフェーズ中に他のソースからタイムクリティカルなチャンクをダウンロードすることを選択できます。
If the bottleneck is near the receiver, the receiver is indeed unlucky that transmissions from any source that runs through this bottleneck will back off quite fast due to LEDBAT. However, for the rest of the network (and the network operator), this is beneficial as the video-streaming system will back off early enough and not contribute too much to the congestion.
ボトルネックがレシーバーの近くにある場合、レシーバーは確かに不運です。このボトルネックを通過する任意のソースからの送信は、LEDBATが原因でかなり速くバックオフします。ただし、残りのネットワーク（およびネットワークオペレーター）にとっては、ビデオストリーミングシステムが十分に早くバックオフし、輻輳の原因となりすぎないため、これは有益です。
The power of LEDBAT is that its behavior can be configured. In the case of live streaming, a PPSPP deployer may want a more aggressive behavior to ensure quality of service. In that case, LEDBAT can be configured to be more aggressive. In particular, LEDBAT's queuing target delay value (TARGET in [RFC6817]) and other parameters can be adjusted such that it acts as aggressive as TCP (or even more). Hence, LEDBAT is an algorithm that works for many scenarios in a peer-to-peer context.
LEDBATの威力は、その動作を設定できることです。ライブストリーミングの場合、PPSPP展開担当者は、サービスの品質を保証するために、より積極的な動作を必要とする場合があります。その場合、LEDBATをより積極的に構成できます。特に、LEDBATのキューイングターゲット遅延値（[RFC6817]のTARGET）およびその他のパラメーターは、TCP（またはそれ以上）と同様に積極的に機能するように調整できます。したがって、LEDBATはピアツーピアコンテキストで多くのシナリオで機能するアルゴリズムです。
We present a small example of communication between a leecher and a seeder. The example presents the transmission of the file "Hello World!", which fits within a 1024-byte chunk. For an easy understanding, we use the message description names, as listed in Table 7, and the protocol option names as listed in Table 2, rather than the actual binary value.
リーチャーとシーダーの間のコミュニケーションの小さな例を紹介します。この例は、1024バイトのチャンクに収まるファイル「Hello World！」の送信を示しています。わかりやすくするために、実際のバイナリ値ではなく、表7にリストされているメッセージ記述名と表2にリストされているプロトコルオプション名を使用します。
To do the handshake, the initiating peer sends a datagram that MUST start with an all-zeros channel ID (0x00000000); followed by a HANDSHAKE message, whose payload is a locally unused; a random channel ID (in this case 0x00000001); and a list of protocol options. Channel IDs MUST be randomly chosen, as described in Section 12.1.
ハンドシェイクを行うために、開始ピアはすべてゼロのチャネルID（0x00000000）で始まる必要があるデータグラムを送信します。その後にHANDSHAKEメッセージが続き、そのペイロードはローカルで未使用です。ランダムなチャネルID（この場合は0x00000001）。およびプロトコルオプションのリスト。セクション12.1で説明されているように、チャネルIDはランダムに選択する必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HANDSHAKE |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1| Version |0 0 0 0 0 0 0 1| Min Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1| Swarm ID |0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 0 1 0 0 1 1 1 1 1 0 0 1 1 0|
~ ..... ~
|1 0 0 0 0 1 1 0 1 0 1 0 1 0 1 0 1 0 1 1 0 0 0 0 0 0 1 1 1 0 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cont. Int. |0 0 0 0 0 0 0 1| Mer.H.Tree F. |0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk Add. |0 0 0 0 0 0 1 0| Chunk Size |0 0 0 0 0 0 0 0~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0| End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The protocol options are:
Version: 1
バージョン：1
Minimum supported Version: 1
サポートされる最小バージョン：1
Swarm Identifier: A 32-byte root hash (47a0...b03b) identifying the content
Swarm Identifier：コンテンツを識別する32バイトのルートハッシュ（47a0 ... b03b）
Content Integrity Protection Method: Merkle Hash Tree
コンテンツの完全性保護方法：マークルハッシュツリー
Merkle Tree Hash Function: SHA-256
マークルツリーハッシュ関数：SHA-256
Chunk Addressing Method: 32-bit chunk ranges
チャンクアドレッシング方式：32ビットのチャンク範囲
Chunk Size: 1024
チャンクサイズ：1024
The receiving peer MAY respond, in which case the returned datagram
MUST consist of the channel ID from the sender's HANDSHAKE message
(0x00000001); a HANDSHAKE message, whose payload is a locally unused;
a random channel ID (0x00000008); and a list of protocol options;
followed by any other messages it wants to send.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HANDSHAKE |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 0| Version |0 0 0 0 0 0 0 1| Cont. Int. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1| Mer.H.Tree F. |0 0 0 0 0 0 1 0| Chunk Add. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 0| Chunk Size |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0| End | HAVE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
With the protocol options, the receiving peer agrees on speaking protocol version 1, on using the Merkle Hash Tree as the Content Integrity Protection Method, SHA-256 hash as the Merkle Tree Hash Function, 32-bit chunk ranges as the Chunk Addressing Method, and Chunk Size 1024. Furthermore, it sends a HAVE message within the same datagram, announcing that it has locally available the first chunk of content.
プロトコルオプションを使用すると、受信ピアは、プロトコルバージョン1を話すことに同意し、コンテンツの完全性保護方式としてマークルハッシュツリーを使用し、マークルツリーハッシュ関数としてSHA-256ハッシュを使用し、チャンクアドレス指定方法として32ビットのチャンク範囲を使用します。さらに、同じデータグラム内でHAVEメッセージを送信し、コンテンツの最初のチャンクをローカルで利用できることを通知します。
At this point, the initiator knows that the peer really responds; for that purpose, channel IDs MUST be random enough to prevent easy guessing. So, the third datagram of a handshake MAY already contain some heavy payload. To minimize the number of initialization round trips, the first two datagrams MAY also contain some minor payload, e.g., the HAVE message.
この時点で、イニシエーターはピアが実際に応答することを認識しています。そのためには、簡単に推測できないようにチャネルIDをランダムにする必要があります。したがって、ハンドシェイクの3番目のデータグラムには、すでに重いペイロードが含まれている場合があります。初期化の往復回数を最小限にするために、最初の2つのデータグラムには、HAVEメッセージなどのマイナーなペイロードも含まれている場合があります。
The initiating peer MAY send a request for the chunks of content it wants to retrieve from the receiving peer, e.g., the first chunk announced during the handshake. It always precedes the message with the channel ID of the peer it is communicating with (0x00000008 in our example), as described in Section 3.11. Furthermore, it MAY add additional messages such as a PEX_REQ.
開始ピアは、受信ピアから取得したいコンテンツのチャンク、たとえば、ハンドシェイク中にアナウンスされた最初のチャンクに対するリクエストを送信する場合があります。セクション3.11で説明されているように、メッセージの前には常に、通信先のピアのチャネルID（この例では0x00000008）が付いています。さらに、PEX_REQなどの追加メッセージを追加する場合があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| REQUEST |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| PEX_REQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When receiving the third datagram, both peers have proof that they really talk to each other; the three-way handshake is complete. The receiving peer responds to the request by sending a DATA message containing the requested content.
3番目のデータグラムを受信すると、両方のピアは、実際に互いに通信していることを証明します。 3ウェイハンドシェイクが完了しました。受信ピアは、要求されたコンテンツを含むDATAメッセージを送信することにより、要求に応答します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DATA |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 1 1 0 1 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 0 0 0 0 1 1 0 0 0 0 0 0 0 1 0 1 1 0 1 1 1 1 1 0 1 1 0 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 0 0 1 0 0|0 1 0 0 1 0 0 0 0 1 1 0 0 1 0 1 0 1 1 0 1 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ..... ~
|0 1 1 0 1 1 0 0 0 1 1 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The DATA message consists of:
DATAメッセージは次のもので構成されます。
The 32-bit chunk range: 0,0 (the first chunk)
32ビットのチャンク範囲：0,0（最初のチャンク）
The timestamp value: 0004e94180b7db44
タイムスタンプ値：0004e94180b7db44
The data: 48656c6c6f20776f726c6421 (the "Hello world!" file)
データ：48656c6c6f20776f726c6421（「Hello world！」ファイル）
Note that the above datagram does not include the INTEGRITY message, as the entire content can fit into a single message; hence, the initiating peer is able to verify it against the root hash. Also, in this example, the peer does not respond to the PEX_REQ as it does not know any third peer participating in the swarm.
上記のデータグラムにはINTEGRITYメッセージが含まれていないことに注意してください。これは、コンテンツ全体が1つのメッセージに収まるためです。したがって、開始ピアはルートハッシュに対してそれを確認できます。また、この例では、ピアはスウォームに参加している3番目のピアを認識していないため、PEX_REQに応答しません。
Upon receiving the requested data, the initiating peer responds with an ACK message for the first chunk, containing a one-way delay sample (100 ms). Furthermore, it also adds a HAVE message for the chunk.
要求されたデータを受信すると、開始ピアは、一方向遅延サンプル（100 ms）を含む最初のチャンクのACKメッセージで応答します。さらに、チャンクのHAVEメッセージも追加します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACK |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 0 0 1 0 0| HAVE |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
At this point, the initiating peer has successfully retrieved the entire file. Then, it explicitly closes the connection by sending a HANDSHAKE message that contains an all-zeros Source Channel ID.
この時点で、開始ピアはファイル全体を正常に取得しました。次に、すべてゼロのソースチャネルIDを含むHANDSHAKEメッセージを送信して、接続を明示的に閉じます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HANDSHAKE |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk (or piece) picking entirely depends on the receiving peer. The sending peer is made aware of preferred chunks by the means of REQUEST messages. In some (live) scenarios, it may be beneficial to allow the sender to ignore those hints and send unrequested data.
チャンク（またはピース）ピッキングは、完全に受信ピアに依存します。送信ピアは、REQUESTメッセージによって優先チャンクを認識します。一部の（ライブ）シナリオでは、送信者がそれらのヒントを無視して、要求されていないデータを送信できるようにすると便利な場合があります。
The chunk picking algorithm is external to the PPSPP and will generally be a pluggable policy that uses the mechanisms provided by PPSPP. The algorithm will handle the choices made by the user consuming the content, such as seeking or switching audio tracks or subtitles. Example policies for P2P streaming can be found in [BITOS], and [EPLIVEPERF].
チャンクピッキングアルゴリズムはPPSPPの外部にあり、通常はPPSPPによって提供されるメカニズムを使用するプラグ可能なポリシーになります。このアルゴリズムは、オーディオトラックや字幕の検索や切り替えなど、コンテンツを利用するユーザーが行った選択を処理します。 P2Pストリーミングのポリシーの例は、[BITOS]と[EPLIVEPERF]にあります。
The role of reciprocity algorithms in peer-to-peer systems is to promote client contribution and prevent freeriding. A peer is said to be freeriding if it only downloads content but never uploads to others. Examples of reciprocity algorithms are tit-for-tat as used in BitTorrent [TIT4TAT] and Give-to-Get [GIVE2GET]. In PPSPP, reciprocity enforcement is the sole responsibility of the sending peer.
ピアツーピアシステムにおける相互関係アルゴリズムの役割は、クライアントの貢献を促進し、フリーライディングを防ぐことです。ピアは、コンテンツをダウンロードするだけで他人にアップロードしない場合、フリーライディングであると言われます。相反性アルゴリズムの例は、BitTorrent [TIT4TAT]とGive-to-Get [GIVE2GET]で使用されるtit-for-tatです。 PPSPPでは、相互関係の強制は送信側ピアの唯一の責任です。
IANA has created a new top-level registry called "Peer-to-Peer Streaming Peer Protocol (PPSPP)", which hosts the six new sub-registries defined below for the extensibility of the protocol. For all registries, assignments consist of a name and its associated value. Also, for all registries, the "Unassigned" ranges designated are governed by the policy "IETF Review" as described in [RFC5226].
IANAは、「ピアツーピアストリーミングピアプロトコル（PPSPP）」と呼ばれる新しいトップレベルのレジストリを作成しました。これは、プロトコルの拡張性のために以下に定義された6つの新しいサブレジストリをホストします。すべてのレジストリで、割り当ては名前とそれに関連付けられた値で構成されます。また、すべてのレジストリについて、[RFC5226]で説明されているように、指定された「割り当てられていない」範囲はポリシー「IETFレビュー」によって管理されます。
The registry name is "PPSPP Message Type Registry". Values are integers in the range 0-255, with initial assignments and reservations given in Table 7.
レジストリ名は「PPSPP Message Type Registry」です。値は0〜255の範囲の整数で、初期割り当てと予約は表7に示されています。
The registry name is "PPSPP Option Registry". Values are integers in the range 0-255, with initial assignments and reservations given in Table 2.
レジストリ名は「PPSPP Option Registry」です。値は0〜255の範囲の整数で、表2に初期割り当てと予約が示されています。
The registry name is "PPSPP Version Number Registry". Values are integers in the range 0-255, with initial assignments and reservations given in Table 3.
レジストリ名は「PPSPPバージョン番号レジストリ」です。値は0〜255の範囲の整数で、表3に初期割り当てと予約が示されています。
The registry name is "PPSPP Content Integrity Protection Method Registry". Values are integers in the range 0-255, with initial assignments and reservations given in Table 4.
レジストリ名は「PPSPP Content Integrity Protection Method Registry」です。値は0〜255の範囲の整数で、初期割り当てと予約は表4に示されています。
The registry name is "PPSPP Merkle Hash Tree Function Registry". Values are integers in the range 0-255, with initial assignments and reservations given in Table 5.
レジストリ名は「PPSPP Merkle Hash Tree Function Registry」です。値は0〜255の範囲の整数で、初期割り当てと予約は表5に示されています。
The registry name is "PPSPP Chunk Addressing Method Registry". Values are integers in the range 0-255, with initial assignments and reservations given in Table 6.
レジストリ名は「PPSPP Chunk Addressing Method Registry」です。値は0〜255の範囲の整数で、表6に初期割り当てと予約が示されています。
This section presents operations and management considerations following the checklist in [RFC5706], Appendix A.
このセクションでは、[RFC5706]の付録Aのチェックリストに従って、運用と管理に関する考慮事項を示します。
In this section, "PPSPP client" is defined as a PPSPP peer acting on behalf of an end user which may not yet have a copy of the content, and "PPSPP server" as a PPSPP peer that provides the initial copies of the content to the swarm on behalf of a content provider.
このセクションでは、「PPSPPクライアント」は、コンテンツのコピーをまだ持っていない可能性のあるエンドユーザーに代わって動作するPPSPPピアとして定義され、「PPSPPサーバー」は、コンテンツの初期コピーを提供するPPSPPピアとして定義されますコンテンツプロバイダーに代わって群れ。
A content provider wishing to use PPSPP to distribute content should set up at least one PPSPP server. PPSPP servers need to have access to either some static content or some live audio/video sources. To provide flexibility for implementors, this configuration process is not standardized. The output of this process will be a list of metadata records, one for each swarm. A metadata record consists of the swarm ID, the chunk size used, the chunk addressing method used, the content integrity protection method used, and the Merkle hash tree function used (if applicable). If automatic content size detection (see Section 5.6) is not used, the content length is also part of the metadata record for static content. Note the swarm ID already contains the Live Signature Algorithm used, in case of a live stream.
PPSPPを使用してコンテンツを配信するコンテンツプロバイダーは、少なくとも1つのPPSPPサーバーをセットアップする必要があります。 PPSPPサーバーは、一部の静的コンテンツまたは一部のライブオーディオ/ビデオソースにアクセスできる必要があります。実装者に柔軟性を提供するために、この構成プロセスは標準化されていません。このプロセスの出力は、各群に1つずつ、メタデータレコードのリストになります。メタデータレコードは、スウォームID、使用されるチャンクサイズ、使用されるチャンクアドレス指定方法、使用されるコンテンツ整合性保護方法、および使用されるマークルハッシュツリー関数（該当する場合）で構成されます。自動コンテンツサイズ検出（セクション5.6を参照）を使用しない場合、コンテンツの長さは静的コンテンツのメタデータレコードの一部でもあります。スウォームIDには、ライブストリームの場合に使用されるライブ署名アルゴリズムがすでに含まれていることに注意してください。
In addition, a content provider should set up a tracking facility for the content by configuring, for example, a peer-to-peer streaming protocol tracker [PPSP-TP] or a Distributed Hash Table. The output of the latter process is a list of transport addresses for the tracking facility.
さらに、コンテンツプロバイダーは、たとえば、ピアツーピアストリーミングプロトコルトラッカー[PPSP-TP]または分散ハッシュテーブルを構成して、コンテンツの追跡機能を設定する必要があります。後者のプロセスの出力は、追跡機能のトランスポートアドレスのリストです。
The list of metadata records of available content, and transport address for the tracking facility, can be distributed to users in various ways. Typically, they will be published on a website as links. When a user clicks such a link, the PPSPP client is launched, either as a standalone application or by invoking the browser's internal PPSPP protocol handler, as exemplified in Section 2. The clients use the tracking facility to obtain the transport address of the PPSPP server(s) and other peers from the swarm, executing the peer protocol to retrieve and redistribute the content. The format of the PPSPP URLs should be defined in an extension document. The default protocol options should be exploited to keep the URLs small.
利用可能なコンテンツのメタデータレコードのリスト、および追跡機能のトランスポートアドレスは、さまざまな方法でユーザーに配布できます。通常、それらはリンクとしてWebサイトに公開されます。ユーザーがそのようなリンクをクリックすると、スタンドアロンアプリケーションとして、またはセクション2に例示されているように、ブラウザの内部PPSPPプロトコルハンドラを呼び出すことによって、PPSPPクライアントが起動されます。クライアントは追跡機能を使用して、PPSPPサーバーのトランスポートアドレスを取得します。 （s）群からの他のピア。ピアプロトコルを実行してコンテンツを取得し、再配布します。 PPSPP URLの形式は、拡張ドキュメントで定義する必要があります。デフォルトのプロトコルオプションを利用して、URLを小さく保つ必要があります。
The minimal information a tracking facility must return when queried for a list of peers for a swarm is as follows. Assuming the communication between tracking facility and requester is protected, the facility must at least return for each peer in the list its IP address, transport protocol identifier (i.e., UDP), and transport protocol port number.
スウォームのピアのリストを照会したときに追跡機能が返す必要のある最小限の情報は、次のとおりです。追跡ファシリティとリクエスタ間の通信が保護されていると仮定すると、ファシリティは、リスト内の各ピアについて、少なくともIPアドレス、トランスポートプロトコル識別子（つまり、UDP）、およびトランスポートプロトコルポート番号を返す必要があります。
This document does not detail a migration path since there is no previous standard protocol providing similar functionality.
同様の機能を提供する以前の標準プロトコルがないため、このドキュメントでは移行パスの詳細は説明しません。
When using the peer-to-peer streaming protocol tracker, PPSPP requires a specific behavior from this protocol for security reasons, as detailed in Section 12.2.
ピアツーピアストリーミングプロトコルトラッカーを使用する場合、PPSPPでは、セクション12.2で詳しく説明するように、セキュリティ上の理由から、このプロトコルからの特定の動作が必要です。
PPSPP is a peer-to-peer protocol that takes advantage of the fact that content is available from multiple sources to improve robustness, scalability, and performance. At the same time, poor choices in determining which exact sources to use can lead to bad experience for the end user and high costs for network operators. Hence, PPSPP can benefit from the ALTO protocol to steer peer selection, as described in Section 3.10.1.
PPSPPは、コンテンツが複数のソースから利用できるという事実を利用して、堅牢性、スケーラビリティー、およびパフォーマンスを向上させるピアツーピアプロトコルです。同時に、使用する正確なソースを決定する際の選択が不十分だと、エンドユーザーのエクスペリエンスが低下し、ネットワークオペレーターのコストが高くなる可能性があります。したがって、3.10.1節で説明するように、PPPSPはALTOプロトコルの利点を活用してピア選択を誘導できます。
PPSPP is operating correctly when all peers obtain the desired content on time. Therefore, the PPSPP client is the ideal location to verify the protocol's correct operation. However, it is not feasible to mandate logging the behavior of PPSPP peers in all implementations and deployments, for example, due to privacy reasons. There are two alternative options:
すべてのピアが必要なコンテンツを時間どおりに取得すると、PPSPPは正しく動作します。したがって、PPPSPクライアントは、プロトコルの正しい動作を確認するための理想的な場所です。ただし、プライバシー上の理由などから、すべての実装と展開でPPSPPピアの動作をログに記録することを義務付けることはできません。 2つの代替オプションがあります。
o Monitoring the PPSPP servers initially providing the content, using standard metrics such as bandwidth usage, peer connections, and activity, can help identify trouble, see next section and [RFC2564].
o 帯域幅の使用状況、ピア接続、アクティビティなどの標準的なメトリックを使用して、最初にコンテンツを提供するPPSPPサーバーを監視すると、問題の特定に役立ちます。次のセクションと[RFC2564]を参照してください。
o The tracker protocol [PPSP-TP] may be used to gather information about all peers in a swarm, to obtain a global view of operation, according to PPSP.OAM.REQ-3 in [RFC6972].
o [RFC6972]のPPSP.OAM.REQ-3に従って、トラッカープロトコル[PPSP-TP]を使用して、群れ内のすべてのピアに関する情報を収集し、操作のグローバルなビューを取得できます。
Basic operation of the protocol can be easily verified when a tracker and swarm metadata are known by starting a PPSPP download. Deep packet inspection for DATA and ACK messages help to establish that actual content transfer is happening and that the chunk availability signaling and integrity checking are working.
PPSPPダウンロードを開始することにより、トラッカーと群れのメタデータがわかっている場合、プロトコルの基本的な動作を簡単に確認できます。 DATAおよびACKメッセージの詳細なパケット検査は、実際のコンテンツ転送が行われていること、およびチャンクの可用性のシグナリングと整合性チェックが機能していることを確認するのに役立ちます。
Table 8 shows the PPSPP parameters, their defaults, and where the parameter is defined. For parameters that have no default, the table row contains the word "var" and refers to the section discussing the considerations to make when choosing a value.
表8は、PPPSPパラメーター、それらのデフォルト、およびパラメーターの定義場所を示しています。デフォルトのないパラメーターの場合、表の行には「var」という単語が含まれており、値を選択する際の考慮事項について説明しているセクションを参照しています。
+-------------------------+-----------------------+-----------------+
| Name | Default | Definition |
+-------------------------+-----------------------+-----------------+
| Chunk Size | var, 1024 bytes | Section 8.1 |
| | recommended | |
| | | |
| Static Content | 1 (Merkle Hash Tree) | Section 7.5 |
| Integrity Protection | | |
| Method | | |
| | | |
| Live Content Integrity | 3 (Unified Merkle | Section 7.5 |
| Protection Method | Tree) | |
| | | |
| Merkle Hash Tree | 2 (SHA-256) | Section 7.6 |
| Function | | |
| | | |
| Live Signature | 13 (ECDSAP256SHA256) | Section 7.7 |
| Algorithm | | |
| | | |
| Chunk Addressing Method | 2 (32-bit chunk | Section 7.8 |
| | ranges) | |
| | | |
| Live Discard Window | var | Section 6.2, |
| | | Section 7.9 |
| | | |
| NCHUNKS_PER_SIG | var | Section 6.1.2.1 |
| | | |
| Dead peer detection | No reply in 3 minutes | Section 3.12 |
| | + 3 datagrams | |
+-------------------------+-----------------------+-----------------+
Table 8: PPSPP Defaults
表8：PPSPPのデフォルト
The management considerations for PPSPP are very similar to other protocols that are used for large-scale content distribution, in particular HTTP. How does one manage large numbers of servers? How does one push new content out to a server farm and allows staged releases? How are faults detected and how are servers and end-user performance measured? As standard solutions to these challenges are still being developed, this section cannot provide a definitive recommendation on how PPSPP should be managed. Hence, it describes the standard solutions available at this time and assumes a future extension document will provide more complete guidelines.
PPSPPの管理に関する考慮事項は、大規模なコンテンツ配信に使用される他のプロトコル、特にHTTPと非常によく似ています。多数のサーバーをどのように管理しますか？新しいコンテンツをサーバーファームにプッシュし、段階的なリリースを許可するにはどうすればよいですか？障害はどのように検出され、サーバーとエンドユーザーのパフォーマンスはどのように測定されますか？これらの課題に対する標準的な解決策がまだ開発中であるため、このセクションでは、PPPSPの管理方法に関する決定的な推奨事項を提供できません。したがって、現時点で利用可能な標準ソリューションについて説明し、将来の拡張ドキュメントがより完全なガイドラインを提供すると想定しています。
As just stated, PPSPP servers providing initial copies of the content are akin to WWW and FTP servers. They can also be deployed in large numbers and thus can benefit from standard management facilities. Therefore, PPSPP servers may implement an SNMP management interface based on the APPLICATION-MIB [RFC2564], where the file object can be used to report on swarms.
先ほど述べたように、コンテンツの初期コピーを提供するPPSPPサーバーは、WWWおよびFTPサーバーに似ています。また、それらを多数展開することもできるため、標準的な管理機能を利用できます。したがって、PPPSPサーバーは、APPLICATION-MIB [RFC2564]に基づくSNMP管理インターフェースを実装する場合があります。ここでは、ファイルオブジェクトを使用して、群れに関するレポートを作成できます。
What is missing is the ability to remove or rate limit specific PPSPP swarms on a server. This corresponds to removing or limiting specific virtual servers on a web server. In other words, as multiple pieces of content (swarms, virtual WWW servers) are multiplexed onto a single server process, more fine-grained management of that process is required. This functionality is currently missing.
不足しているのは、サーバー上の特定のPPSPPスウォームを削除またはレート制限する機能です。これは、Webサーバー上の特定の仮想サーバーを削除または制限することに対応します。つまり、複数のコンテンツ（スウォーム、仮想WWWサーバー）が単一のサーバープロセスに多重化されるため、そのプロセスをよりきめ細かく管理する必要があります。この機能は現在欠落しています。
Logging is an important functionality for PPSPP servers and, depending on the deployment, PPSPP clients. Logging should be done via syslog [RFC5424].
ログは、PPSSPPサーバーおよび展開によってはPPSSPPクライアントにとって重要な機能です。ロギングは、syslog [RFC5424]を介して行う必要があります。
The facilities for verifying correct operation and server management (just discussed) appear sufficient for PPSPP fault monitoring. This can be supplemented with host resource [RFC2790] and UDP/IP network monitoring [RFC4113], as PPSPP server failures can generally be attributed directly to conditions on the host or network.
正しい操作とサーバー管理を検証する機能（先ほど説明したもの）は、PPPSP障害監視には十分であるように見えます。これは、ホストリソース[RFC2790]とUDP / IPネットワークモニタリング[RFC4113]で補足できます。PPSPPサーバーの障害は、通常、ホストまたはネットワークの状態に直接起因します。
Since PPSPP has been designed to work in a hostile environment, many benign faults will be handled by the mechanisms used for managing attacks. For example, when a malfunctioning peer starts sending the wrong chunks, this is detected by the content integrity protection mechanism and another source is sought.
PPSPPは悪意のある環境で機能するように設計されているため、多くの無害な障害は、攻撃の管理に使用されるメカニズムによって処理されます。たとえば、誤動作しているピアが間違ったチャンクの送信を開始すると、これはコンテンツの整合性保護メカニズムによって検出され、別のソースが求められます。
Large-scale deployments may benefit from a standard way of replicating a new piece of content on a set of initial PPSPP servers. This functionality may need to include controlled releasing, such that content becomes available only at a specific point in time (e.g., the release of a movie trailer). This functionality could be provided via NETCONF [RFC6241], to enable atomic configuration updates over a set of servers. Uploading the new content could be one configuration change, making the content available for download by the public another.
大規模な展開では、一連の初期PPSPPサーバー上で新しいコンテンツを複製する標準的な方法が有効です。この機能には、コンテンツが特定の時点でのみ利用可能になるように、制御されたリリースを含める必要がある場合があります（映画の予告編のリリースなど）。この機能は、NETCONF [RFC6241]を介して提供され、一連のサーバーでアトミックな構成の更新を可能にします。新しいコンテンツのアップロードは、1つの構成変更であり、他の人がコンテンツをダウンロードできるようにすることができます。
Content providers may offer PPSPP hosting for different customers and will want to bill these customers, for example, based on bandwidth usage. This situation is a common accounting scenario, similar to billing per virtual server for web servers. PPSPP can therefore benefit from general standardization efforts in this area [RFC2975] when they come to fruition.
コンテンツプロバイダーは、さまざまな顧客にPPSPPホスティングを提供する場合があり、たとえば、帯域幅の使用量に基づいてこれらの顧客に請求することを希望します。この状況は、Webサーバーの仮想サーバーごとの請求と同様の一般的な会計シナリオです。したがって、PPSPPは、この分野での一般的な標準化の取り組み[RFC2975]が実を結ぶときに恩恵を受けることができます。
Depending on the deployment scenarios, the application performance measurement facilities of [RFC3729] and associated [RFC4150] can be used with PPSPP.
展開シナリオによっては、[RFC3729]および関連する[RFC4150]のアプリケーションパフォーマンス測定機能をPPSPPで使用できます。
In addition, when the PPSPP tracker protocol is used, it provides a built-in, application-level, performance measurement infrastructure for different metrics. See PPSP.OAM.REQ-3 in [RFC6972].
さらに、PPSPPトラッカープロトコルを使用すると、さまざまなメトリックに対して組み込みのアプリケーションレベルのパフォーマンス測定インフラストラクチャが提供されます。 [RFC6972]のPPSP.OAM.REQ-3を参照してください。
Malicious peers should ideally be locked out long term. This is primarily for performance reasons, as the protocol is robust against attacks (see next section). Section 12.7 describes a procedure for long-term exclusion.
悪意のあるピアは、理想的には長期間ロックアウトする必要があります。プロトコルは攻撃に対して堅牢であるため、これは主にパフォーマンス上の理由によるものです（次のセクションを参照）。 12.7項では、長期的な除外の手順について説明します。
As any other network protocol, PPSPP faces a common set of security challenges. An implementation must consider the possibility of buffer overruns, DoS attacks and manipulation (i.e., reflection attacks). Any guarantee of privacy seems unlikely, as the user is exposing its IP address to the peers. A probable exception is the case of the user being hidden behind a public NAT or proxy. This section discusses the protocol's security considerations in detail.
他のネットワークプロトコルと同様に、PPSPPは一般的なセキュリティの課題に直面しています。実装では、バッファオーバーラン、DoS攻撃、および操作（つまり、リフレクション攻撃）の可能性を考慮する必要があります。ユーザーがピアにIPアドレスを公開しているため、プライバシーの保証はほとんどありません。考えられる例外は、ユーザーがパブリックNATまたはプロキシの背後に隠れている場合です。このセクションでは、プロトコルのセキュリティに関する考慮事項について詳しく説明します。
Borrowing from the analysis in [RFC5971], the PPSPP may be attacked with three types of denial-of-service attacks:
[RFC5971]の分析から借用すると、PPSPPは3種類のサービス拒否攻撃で攻撃される可能性があります。
1. DoS amplification attack: attackers try to use a PPSPP peer to generate more traffic to a victim.
1. DoS増幅攻撃：攻撃者はPPSPPピアを使用して、被害者へのトラフィックを増やします。
2. DoS flood attack: attackers try to deny service to other peers by allocating lots of state at a PPSPP peer.
2. DoSフラッド攻撃：攻撃者は、PPSPPピアに多くの状態を割り当てることにより、他のピアへのサービスを拒否しようとします。
3. Disrupt service to an individual peer: attackers send bogus, e.g., REQUEST and HAVE messages appearing to come from victim Peer A to the Peers B1..Bn serving that peer. This causes Peer A to receive chunks it did not request or to not receive the chunks it requested.
3. 個々のピアへのサービスを中断する：攻撃者は偽のメッセージを送信します。たとえば、REQUESTメッセージやHAVEメッセージは、被害者のピアAからピアB1..Bnに送信されているように見えますこれにより、ピアAは要求しなかったチャンクを受信するか、要求したチャンクを受信しなくなります。
The basic scheme to protect against these attacks is the use of a secure handshake procedure. In the UDP encapsulation, the handshake procedure is secured by the use of randomly chosen channel IDs as follows. The channel IDs must be generated following the requirements in [RFC4960] (Section 5.1.3).
これらの攻撃から保護するための基本的なスキームは、安全なハンドシェイク手順の使用です。 UDPカプセル化では、ランダムに選択されたチャネルIDを使用して、次のようにハンドシェイク手順が保護されます。チャネルIDは、[RFC4960]（セクション5.1.3）の要件に従って生成する必要があります。
When UDP is used, all datagrams carrying PPSPP messages are prefixed with a 4-byte channel ID. These channel IDs are random numbers, established during the handshake phase as follows. Peer A initiates an exchange with Peer B by sending a datagram containing a HANDSHAKE message prefixed with the channel ID consisting of all zeros. Peer A's HANDSHAKE contains a randomly chosen channel ID, chanA:
UDPを使用する場合、PPSPPメッセージを伝送するすべてのデータグラムには、4バイトのチャネルIDがプレフィックスとして付加されます。これらのチャネルIDは乱数であり、ハンドシェイクフェーズ中に次のように確立されます。ピアAは、すべてゼロからなるチャネルIDが前に付いたHANDSHAKEメッセージを含むデータグラムを送信することにより、ピアBとの交換を開始します。ピアAのハンドシェイクには、ランダムに選択されたチャネルID chanAが含まれています。
A->B: chan0 + HANDSHAKE(chanA) + ...
A-> B：chan0 + HANDSHAKE（chanA）+ ...
When Peer B receives this datagram, it creates some state for Peer A, that at least contains the channel ID chanA. Next, Peer B sends a response to Peer A, consisting of a datagram containing a HANDSHAKE message prefixed with the chanA channel ID. Peer B's HANDSHAKE contains a randomly chosen channel ID, chanB.
ピアBがこのデータグラムを受信すると、少なくともチャネルID chanAを含むピアAの状態が作成されます。次に、ピアBは、chanAチャネルIDが前に付いたHANDSHAKEメッセージを含むデータグラムで構成される、ピアAに応答を送信します。ピアBのハンドシェイクには、ランダムに選択されたチャネルID chanBが含まれています。
B->A: chanA + HANDSHAKE(chanB) + ...
B-> A：chanA +ハンドシェイク（chanB）+ ...
Peer A now knows that Peer B really responds, as it echoed chanA. So the next datagram that Peer A sends may already contain heavy payload, i.e., a chunk. This next datagram to Peer B will be prefixed with the chanB channel ID. When Peer B receives this datagram, both peers have the proof they are really talking to each other, the three-way handshake is complete. In other words, the randomly chosen channel IDs act as tags (cf. [RFC4960] (Section 5.1)).
ピアAは、chanAと同じように、ピアBが実際に応答することを認識しています。したがって、ピアAが送信する次のデータグラムには、重いペイロード、つまりチャンクがすでに含まれている可能性があります。ピアBへのこの次のデータグラムの先頭には、chanBチャネルIDが付けられます。ピアBがこのデータグラムを受信すると、両方のピアが実際に互いに通信しているという証拠が得られ、3ウェイハンドシェイクが完了します。つまり、ランダムに選択されたチャネルIDはタグとして機能します（[RFC4960]（セクション5.1）を参照）。
A->B: chanB + HAVE + DATA + ...
A-> B：chanB + HAVE + DATA + ...
In short, PPSPP does a so-called return routability check before heavy payload is sent. This means that attack 1 is fended off: PPSPP does not send back much more data than it received, unless it knows it is talking to a live peer. Attackers sending a spoofed HANDSHAKE to Peer B pretending to be Peer A now need to intercept the message from Peer B to Peer A to get Peer B to send heavy payload, and ensure that that heavy payload goes to the victim, something assumed too hard to be a practical attack.
つまり、PPSPPは、重いペイロードが送信される前に、いわゆるリターンルーティング可能性チェックを実行します。これは、攻撃1が回避されることを意味します。PPSPPは、ライブピアと通信していることを認識していない限り、受信したデータよりもはるかに多くのデータを送信しません。ピアAのふりをしてスプーフィングされたハンドシェイクをピアBに送信する攻撃者は、ピアBからピアAにメッセージをインターセプトして、ピアBに重いペイロードを送信させ、その重いペイロードが被害者に届くようにする必要があります。実用的な攻撃になります。
Note the rule is that no heavy payload may be sent until the third datagram. This has implications for PPSPP implementations that use chunk addressing schemes that are verbose. If a PPSPP implementation uses large bitmaps to convey chunk availability, these may not be sent by Peer B in the second datagram.
ルールは、3番目のデータグラムまで重いペイロードを送信できないことに注意してください。これは、詳細なチャンクアドレス指定スキームを使用するPPSPP実装に影響を与えます。 PPSPP実装がチャンクの可用性を伝えるために大きなビットマップを使用する場合、これらはピアBによって2番目のデータグラムで送信されない場合があります。
On receiving the first datagram Peer B will record some state about Peer A. At present, this state consists of the chanA channel ID, and the results of processing the other messages in the first datagram. In particular, if Peer A included some HAVE messages, Peer B may add a chunk availability map to Peer A's state. In addition, Peer B may request some chunks from Peer A in the second datagram, and Peer B will maintain state about these outgoing requests.
最初のデータグラムを受信すると、ピアBはピアAに関するいくつかの状態を記録します。現在、この状態は、chanAチャネルIDと、最初のデータグラム内の他のメッセージの処理結果で構成されています。特に、ピアAがいくつかのHAVEメッセージを含んでいた場合、ピアBは、チャンク可用性マップをピアAの状態に追加できます。さらに、ピアBは2番目のデータグラムでピアAにいくつかのチャンクを要求することがあり、ピアBはこれらの発信要求に関する状態を維持します。
So presently, PPSPP is somewhat vulnerable to attack 2. An attacker could send many datagrams with HANDSHAKEs and HAVEs and thus allocate state at the PPSPP peer. Therefore, Peer A MUST respond immediately to the second datagram, if it is still interested in Peer B.
そのため現在、PPSPPは攻撃2に対していくぶん脆弱です。攻撃者はHANDSHAKEおよびHAVEを使用して多くのデータグラムを送信し、PPPSPピアで状態を割り当てる可能性があります。したがって、ピアBに引き続き関心がある場合、ピアAは2番目のデータグラムにすぐに応答する必要があります。
The reason for using this slightly vulnerable three-way handshake instead of the safer handshake procedure of Stream Control Transmission Protocol (SCTP) [RFC4960] (Section 5.1) is quicker response time for the user. In the SCTP procedure, Peers A and B cannot request chunks until datagrams 3 and 4 respectively, as opposed to 2 and 1 in the proposed procedure. This means that the user has to wait less time in PPSPP between starting the video stream and seeing the first images.
ストリーム制御伝送プロトコル（SCTP）[RFC4960]（セクション5.1）のより安全なハンドシェイク手順の代わりに、このわずかに脆弱な3ウェイハンドシェイクを使用する理由は、ユーザーの応答時間が速いためです。 SCTP手順では、ピアAとBは、提案された手順の2と1ではなく、それぞれデータグラム3と4までチャンクを要求できません。つまり、ユーザーは、ビデオストリームを開始してから最初の画像が表示されるまでの間、PPSPPで待機する時間が少なくて済みます。
In general, channel IDs serve to authenticate a peer. Hence, to attack, a malicious Peer T would need to be able to eavesdrop on conversations between victim A and a benign Peer B to obtain the channel ID Peer B assigned to Peer A, chanB. Furthermore, attacker Peer T would need to be able to spoof, e.g., REQUEST and HAVE messages from Peer A to cause Peer B to send heavy DATA messages to Peer A, or prevent Peer B from sending them, respectively.
一般に、チャネルIDはピアの認証に役立ちます。したがって、攻撃するには、悪意のあるピアTが被害者Aと良性のピアBの間の会話を傍受して、ピアAに割り当てられたチャネルIDピアBのチャネルBを取得できる必要があります。さらに、攻撃者のピアTは、ピアAからのREQUESTメッセージやHAVEメッセージなどを偽装して、ピアBからピアAに大量のDATAメッセージを送信させたり、ピアBがメッセージを送信したりできないようにする必要があります。
The capability to eavesdrop is not common, so the protection afforded by channel IDs will be sufficient in most cases. If not, point-to-point encryption of traffic should be used, see below.
盗聴機能は一般的ではないため、ほとんどの場合、チャネルIDによって提供される保護で十分です。そうでない場合は、トラフィックのポイントツーポイント暗号化を使用する必要があります。以下を参照してください。
As described in Section 3.10, Peer A can send Peer-Exchange messages PEX_RES to Peer B, which contain the IP address and port of other peers that are supposedly also in the current swarm. The strength of this mechanism is that it allows decentralized tracking: after an initial bootstrap, no central tracker is needed. The vulnerability of this mechanism (and DHTs) is that malicious peers can use it for an Amplification attack.
セクション3.10で説明したように、ピアAはピア交換メッセージPEX_RESをピアBに送信できます。ピアBには、現在のスウォームにあると思われる他のピアのIPアドレスとポートが含まれています。このメカニズムの強みは、分散型の追跡が可能になることです。最初のブートストラップの後は、中央のトラッカーは必要ありません。このメカニズム（およびDHT）の脆弱性は、悪意のあるピアが増幅攻撃に使用できることです。
In particular, a malicious Peer T could send PEX_RES messages to well-behaved Peer A with addresses of Peers B1..Bn; on receipt, Peer A could send a HANDSHAKE to all these peers. So, in the worst case, a single datagram results in N datagrams. The actual damage depends on Peer A's behavior. For example, when Peer A already has sufficient connections, it may not connect to the offered ones at all; but if it is a fresh peer, it may connect to all directly.
特に、悪意のあるピアTは、ピアB1..Bnのアドレスを使用して、正常に動作しているピアAにPEX_RESメッセージを送信できます。受信すると、ピアAはHANDSHAKEをこれらすべてのピアに送信できます。したがって、最悪の場合、単一のデータグラムはN個のデータグラムになります。実際の損傷は、ピアAの動作によって異なります。たとえば、ピアAにすでに十分な接続がある場合、提供された接続にまったく接続しない可能性があります。しかし、それが新しいピアである場合、すべてに直接接続できます。
In addition, PEX can be used in Eclipse attacks [ECLIPSE] where malicious peers try to isolate a particular peer such that it only interacts with malicious peers. Let us distinguish two specific attacks:
さらに、PEXはEclipse攻撃[ECLIPSE]で使用でき、悪意のあるピアが悪意のあるピアとのみ相互作用するように特定のピアを分離しようとします。 2つの特定の攻撃を区別してみましょう。
E1. Malicious peers try to eclipse the single injector in live streaming.
E1。悪意のあるピアは、ライブストリーミングで単一のインジェクターを遮ろうとします。
E2. Malicious peers try to eclipse a specific consumer peer.
E2。悪意のあるピアは、特定の消費者のピアを日食にしようとします。
Attack E1 has the most impact on the system as it would disrupt all peers.
攻撃E1は、すべてのピアを混乱させるため、システムに最も影響を与えます。
If peer addresses are relatively stable, strong protection against the attack can be provided by using public key cryptography and certification. In particular, a PEX_REScert message will carry swarm-membership certificates rather than IP address and port. A membership certificate for Peer B states that Peer B at address (ipB,portB) is part of Swarm S at Time T and is cryptographically signed. The receiver Peer A can check the certificate for a valid signature, the right swarm and liveliness, and only then consider contacting Peer B. These swarm-membership certificates correspond to signed node descriptors in secure decentralized peer sampling services [SPS].
ピアアドレスが比較的安定している場合、公開キーの暗号化と証明書を使用することにより、攻撃に対する強力な保護を提供できます。特に、PEX_REScertメッセージは、IPアドレスとポートではなく、swarm-membership証明書を伝達します。ピアBのメンバーシップ証明書には、アドレス（ipB、portB）のピアBが時間TのスウォームSの一部であり、暗号で署名されていることが記載されています。受信者のピアAは、証明書の有効な署名、正しい群れと活性を確認してから、ピアBへの連絡を検討できます。これらの群れメンバーシップ証明書は、安全な分散型ピアサンプリングサービス[SPS]の署名済みノード記述子に対応します。
Several designs are possible for the security environment for these membership certificates. That is, there are different designs possible for who signs the membership certificates and how public keys are distributed. As an example, we describe a design where the peer-to-peer streaming protocol tracker acts as certification authority.
これらのメンバーシップ証明書のセキュリティ環境では、いくつかの設計が可能です。つまり、誰がメンバーシップ証明書に署名するか、および公開鍵がどのように配布されるかについて、さまざまな設計が可能です。例として、ピアツーピアストリーミングプロトコルトラッカーが認証局として機能する設計について説明します。
Peer A wanting to join Swarm S sends a certificate request message to a Tracker X for that swarm. Upon receipt, the tracker creates a membership certificate from the request with Swarm ID S, a Timestamp T, and the external IP and port it received the message from, signed with the tracker's private key. This certificate is returned to Peer A.
Swarm Sに参加したいピアAは、そのスウォームの証明書要求メッセージをトラッカーXに送信します。トラッカーは、受信すると、Swarm ID S、タイムスタンプT、およびトラッカーの秘密鍵で署名されたメッセージを受信した外部IPおよびポートを使用して、リクエストからメンバーシップ証明書を作成します。この証明書はピアAに返されます。
Peer A then includes this certificate when it sends a PEX_REScert to Peer B. Receiver Peer B verifies it against the tracker public key. This tracker public key should be part of the swarm's metadata, which Peer B received from a trusted source. Subsequently, Peer B can send the member certificate of Peer A to other peers in PEX_REScert messages.
次に、ピアAは、PEX_REScertをピアBに送信するときにこの証明書を含めます。受信側のピアBは、トラッカーの公開鍵と照合して証明書を検証します。このトラッカー公開鍵は、ピアBが信頼できるソースから受け取った群れのメタデータの一部である必要があります。その後、ピアBは、ピアAのメンバー証明書をPEX_REScertメッセージで他のピアに送信できます。
Peer A can send the certification request when it first contacts the tracker or at a later time. Furthermore, the responses the tracker sends could contain membership certificates instead of plain addresses, such that they can be gossiped securely as well.
ピアAは、最初にトラッカーに連絡するとき、または後で連絡するときに、認証要求を送信できます。さらに、トラッカーが送信する応答には、プレーンアドレスの代わりにメンバーシップ証明書を含めることができるため、安全にうわさすることができます。
We assume the tracker is protected against attacks and does a return routability check. The latter ensures that malicious peers cannot obtain a certificate for a random host, just for hosts where they can eavesdrop on incoming traffic.
トラッカーは攻撃から保護されていると想定し、返送可能性チェックを行います。後者は、悪意のあるピアがランダムなホストの証明書を取得できないことを保証します。受信トラフィックを盗聴できるホストの場合のみです。
The load generated on the tracker depends on churn and the lifetime of a certificate. Certificates can be fairly long lived, given that the main goal of the membership certificates is to prevent that malicious Peer T can cause good Peer A to contact *random* hosts. The freshness of the timestamp just adds extra protection in addition to achieving that goal. It protects against malicious hosts causing a good Peer A to contact hosts that previously participated in the swarm.
トラッカーで生成される負荷は、チャーンと証明書の有効期間によって異なります。メンバーシップ証明書の主な目的は、悪意のあるピアTが適切なピアAが*ランダム*ホストに接続するのを防ぐことであることを考えると、証明書はかなり長持ちする可能性があります。タイムスタンプの鮮度は、その目標を達成するだけでなく、追加の保護を追加するだけです。これは、悪意のあるホストが、以前に群れに参加していたホストに適切なピアAに連絡させることから保護します。
The membership certificate mechanism itself can be used for a kind of amplification attack against good peers. Malicious Peer T can cause Peer A to spend some CPU to verify the signatures on the membership certificates that Peer T sends. To counter this, Peer A SHOULD check a few of the certificates sent and discard the rest if they are defective.
メンバーシップ証明書メカニズム自体は、優れたピアに対する一種の増幅攻撃に使用できます。悪意のあるピアTは、ピアAにCPUを費やして、ピアTが送信するメンバーシップ証明書の署名を検証させる可能性があります。これに対抗するため、ピアAは送信された証明書のいくつかを確認し、欠陥がある場合は残りを破棄する必要があります（SHOULD）。
The same membership certificates described above can be registered in a Distributed Hash Table that has been secured against the well-known DHT specific attacks [SECDHTS].
上記と同じメンバーシップ証明書を、よく知られているDHT固有の攻撃[SECDHTS]から保護されている分散ハッシュテーブルに登録できます。
Note that this scheme does not work for peers behind a symmetric Network Address Translator, but neither does normal tracker registration.
このスキームは、対称型ネットワークアドレス変換の背後にあるピアでは機能しませんが、通常のトラッカー登録では機能しないことに注意してください。
Before we can discuss Eclipse attacks, we first need to establish the security properties of the central tracker. A tracker is vulnerable to Amplification attacks, too. A malicious Peer T could register a victim Peer B with the tracker, and many peers joining the swarm will contact Peer B. Trackers can also be used in Eclipse attacks. If many malicious peers register themselves at the tracker, the percentage of bad peers in the returned address list may become high. Leaving the protection of the tracker to the peer-to-peer streaming protocol tracker specification [PPSP-TP], we assume for the following discussion that it returns a true random sample of the actual swarm membership (achieved via Sybil attack protection). This means that if 50% of the peers are bad, you'll still get 50% good addresses from the tracker.
Eclipse攻撃について説明する前に、まず中央トラッカーのセキュリティプロパティを確立する必要があります。トラッカーも増幅攻撃に対して脆弱です。悪意のあるピアTが被害者のピアBをトラッカーに登録する可能性があり、スウォームに参加する多くのピアがピアBに連絡します。トラッカーはEclipse攻撃にも使用できます。多くの悪意のあるピアがトラッカーに自分自身を登録する場合、返されるアドレスリスト内の不良なピアの割合が高くなる可能性があります。トラッカーの保護をピアツーピアストリーミングプロトコルトラッカー仕様[PPSP-TP]に任せて、以下の説明では、実際のスウォームメンバーシップの真のランダムサンプルが返されると想定します（Sybil攻撃保護によって実現）。つまり、ピアの50％が不良であっても、トラッカーから50％の良好なアドレスを取得できます。
Attack E1 on PEX can be fended off by letting live injectors disable PEX -- or at least, letting live injectors ensure that part of their connections are to peers whose addresses came from the trusted tracker.
PEXへの攻撃E1は、ライブインジェクターにPEXを無効にさせるか、少なくとも、信頼できるトラッカーからアドレスが取得されたピアへの接続の一部を確実にすることで回避できます。
The same measures defend against attack E2 on PEX. They can also be employed dynamically. When the current set of Peers B that Peer A is connected to doesn't provide good quality of service, Peer A can contact the tracker to find new candidates.
同じ対策がPEXに対する攻撃E2を防御します。動的に使用することもできます。ピアAが接続されているピアBの現在のセットがサービスの品質を向上させない場合、ピアAはトラッカーに連絡して新しい候補を見つけることができます。
Regarding PPSP.SEC.REQ-1 in [RFC6972], the Closed Swarms [CLOSED] and Enhanced Closed Swarms [ECS] mechanisms provide swarm-level access control. The basic idea is that a peer cannot download from another peer unless it shows a Proof-of-Access. Enhanced Closed Swarms improve on the original Closed Swarms by adding on-the-wire encryption against man-in-the-middle attacks and more flexible access control rules.
[RFC6972]のPPSP.SEC.REQ-1に関して、クローズドスウォーム[CLOSED]および拡張クローズドスウォーム[ECS]メカニズムは、スウォームレベルのアクセス制御を提供します。基本的な考え方は、アクセス証明が表示されない限り、ピアは別のピアからダウンロードできないということです。強化されたクローズドスウォームは、man-in-the-middle攻撃に対するネットワーク上の暗号化とより柔軟なアクセス制御ルールを追加することにより、元のクローズドスウォームを改善します。
The exact mapping of ECS to PPSPP is defined in [ECS-protocol].
ECSからPPSPPへの正確なマッピングは、[ECSプロトコル]で定義されています。
Regarding PPSP.SEC.REQ-1 in [RFC6972], no extra mechanism is needed to support confidentiality in PPSPP. A content publisher wishing confidentiality should just distribute content in ciphertext and/or in a format to which Digital Rights Management (DRM) techniques have been applied. In that case, it is assumed a higher layer handles key management out-of-band. Alternatively, pure point-to-point encryption of content and traffic can be provided by the proposed Closed Swarms access control mechanism, by DTLS [RFC6347], or by IPsec [RFC4301].
[RFC6972]のPPSP.SEC.REQ-1に関して、PPSPPの機密性をサポートするために追加のメカニズムは必要ありません。機密性を希望するコンテンツ発行者は、暗号文および/またはデジタル著作権管理（DRM）技術が適用された形式でコンテンツを配布するだけです。その場合、上位層が帯域外の鍵管理を処理すると想定されます。あるいは、コンテンツとトラフィックの純粋なポイントツーポイント暗号化は、提案されたClosed Swarmsアクセス制御メカニズム、DTLS [RFC6347]、またはIPsec [RFC4301]によって提供できます。
When transmitting over DTLS, PPSPP can obtain the PMTU estimate maintained by the IP layer to determine how much payload can be put in a single datagram without fragmentation ([RFC6347], Section 4.1.1.1). If PMTU changes and the chunk size becomes too large to fit into a single datagram, PPSPP can choose to allow fragmentation by clearing the Don't Fragment (DF) bit. Alternatively, the content publisher can decide to use smaller chunks and transmit multiple in the same datagram when the MTU allows.
DTLSを介して送信する場合、PPSPPはIPレイヤーによって維持されるPMTUの見積もりを取得して、断片化せずに単一のデータグラムに入れることができるペイロードの量を決定できます（[RFC6347]、セクション4.1.1.1）。 PMTUが変更され、チャンクサイズが大きくなりすぎて単一のデータグラムに収まらない場合、PPSPPは、Do n't Fragment（DF）ビットをクリアすることにより、フラグメンテーションを許可することを選択できます。または、コンテンツパブリッシャーは、MTUが許可する場合、より小さいチャンクを使用して同じデータグラムで複数を送信することを決定できます。
Implementations MUST support SHA-1 as the hash function for content integrity protection via Merkle hash trees. SHA-1 may be preferred over stronger hash functions by content providers because it reduces on-the-wire overhead. As such, it presents a trade-off between performance and security. The security considerations for SHA-1 are discussed in [RFC6194].
実装は、マークルハッシュツリーによるコンテンツの整合性保護のためのハッシュ関数としてSHA-1をサポートする必要があります。 SHA-1は、ネットワーク上のオーバーヘッドを削減するため、コンテンツプロバイダーによるより強力なハッシュ関数よりも優先される場合があります。そのため、パフォーマンスとセキュリティの間でトレードオフが発生します。 SHA-1のセキュリティに関する考慮事項は、[RFC6194]で説明されています。
In general, note that the hash function is used in a hash tree, which makes it more complex to create collisions. In particular, if attackers manage to find a collision for a hash, it can replace just one chunk, so the impact is limited. If fixed-size chunks are used, the collision even has to be of the same size as the original chunk. For hashes higher up in the hash tree, a collision must be a concatenation of two hashes. In sum, finding collisions that fit with the hash tree are generally harder to find than regular collisions.
一般に、ハッシュ関数はハッシュツリーで使用されるため、衝突が発生しやすくなります。特に、攻撃者がハッシュの衝突を見つけた場合、1つのチャンクだけを置き換えることができるため、影響は限定的です。固定サイズのチャンクを使用する場合、衝突は元のチャンクと同じサイズでなければなりません。ハッシュツリーの上位にあるハッシュの場合、衝突は2つのハッシュの連結でなければなりません。要約すると、ハッシュツリーに適合する衝突を見つけることは、通常の衝突よりも見つけるのが一般に困難です。
12.6. Limit Potential Damage and Resource Exhaustion by Bad or Broken Peers
12.6. 不良または破損したピアによる潜在的な損傷とリソースの枯渇を制限する
Regarding PPSP.SEC.REQ-2 in [RFC6972], this section provides an analysis of the potential damage a malicious peer can do with each message in the protocol, and how it is prevented by the protocol (implementation).
[RFC6972]のPPSP.SEC.REQ-2に関して、このセクションでは、悪意のあるピアがプロトコル内の各メッセージを使用して発生する可能性のある損傷の分析と、プロトコル（実装）によってそれがどのように防止されるかについて説明します。
o Secured against DoS Amplification attacks as described in Section 12.1.
o セクション12.1で説明されているように、DdoS増幅攻撃から保護します。
o Threat HS.1: An Eclipse attack where Peers T1..Tn fill all connection slots of Peer A by initiating the connection to Peer A.
o 脅威HS.1：ピアAへの接続を開始することにより、ピアT1..TnがピアAのすべての接続スロットを埋めるEclipse攻撃。
Solution: Peer A must not let other peers fill all its available connection slots, i.e., Peer A must initiate connections itself too, to prevent isolation.
解決策：ピアAは、他のピアが利用可能なすべての接続スロットを埋めないようにする必要があります。つまり、分離を防ぐために、ピアAも接続を開始する必要があります。
o Threat HAVE.1: Malicious Peer T can claim to have content that it does not. Subsequently, Peer T won't respond to requests.
o 脅威HAVE.1：悪意のあるピアTは、そうでないコンテンツがあると主張できます。その後、ピアTは要求に応答しません。
Solution: Peer A will consider Peer T to be a slow peer and not ask it again.
解決策：ピアAは、ピアTを低速ピアであると見なし、再度要求しないようにします。
o Threat HAVE.2: Malicious Peer T can claim not to have content. Hence, it won't contribute.
o 脅威HAVE.2：悪意のあるピアTはコンテンツがないと主張できます。したがって、貢献しません。
Solution: Peer and chunk selection algorithms external to the protocol will implement fairness and provide sharing incentives.
解決策：プロトコルの外部にあるピアおよびチャンク選択アルゴリズムは、公平性を実装し、共有インセンティブを提供します。
o Threat DATA.1: Peer T sending bogus chunks.
o 脅威DATA.1：ピアTが偽のチャンクを送信しています。
Solution: The content integrity protection schemes defend against this.
ソリューション：コンテンツの整合性保護スキームは、これを防ぎます。
o Threat DATA.2: Peer T sends Peer A unrequested chunks.
o 脅威DATA.2：ピアTがピアAに要求されていないチャンクを送信します。
To protect against this threat we need network-level DoS prevention.
この脅威から保護するには、ネットワークレベルのDoS防止が必要です。
o Threat ACK.1: Peer T acknowledges wrong chunks.
o 脅威ACK.1：ピアTが間違ったチャンクを確認します。
Solution: Peer A will detect inconsistencies with the data it sent to Peer T.
解決策：ピアAは、ピアTに送信したデータとの不整合を検出します。
o Threat ACK.2: Peer T modifies timestamp in ACK to Peer A used for time-based congestion control.
o 脅威ACK.2：ピアTは、時間ベースの輻輳制御に使用されるピアAへのACKのタイムスタンプを変更します。
Solution: In theory, by decreasing the timestamp, Peer T could fake that there is no congestion when in fact there is, causing Peer A to send more data than it should. [RFC6817] does not list this as a security consideration. Possibly, this attack can be detected by the large resulting asymmetry between round-trip time and measured one-way delay.
解決策：理論的には、タイムスタンプを減らすことで、ピアTは実際には輻輳がないと偽って、ピアAが必要以上のデータを送信するようにすることができます。 [RFC6817]は、これをセキュリティ上の考慮事項として挙げていません。おそらく、この攻撃は、往復時間と測定された一方向の遅延との間の大きな非対称性によって検出される可能性があります。
o Threat INTEGRITY.1: An amplification attack where Peer T sends bogus INTEGRITY or SIGNED_INTEGRITY messages, causing Peer A to checks hashes or signatures, thus spending CPU unnecessarily.
o 脅威INTEGRITY.1：ピアTが偽のINTEGRITYまたはSIGNED_INTEGRITYメッセージを送信する増幅攻撃。ピアAがハッシュまたは署名をチェックするため、CPUが不必要に消費されます。
Solution: If the hashes/signatures don't check out, Peer A will stop asking Peer T because of the atomic datagram principle and the content integrity protection. Subsequent unsolicited traffic from Peer T will be ignored.
解決策：ハッシュ/署名がチェックアウトしない場合、アトミックデータグラムの原則とコンテンツの整合性保護のため、ピアAはピアTへの要求を停止します。ピアTからのその後の一方的なトラフィックは無視されます。
o Threat INTEGRITY.2: An attack where Peer T sends old SIGNED_INTEGRITY messages in the Unified Merkle Tree scheme, trying to make Peer A tune in at a past point in the live stream.
o 脅威INTEGRITY.2：Peer Tが古いSIGNED_INTEGRITYメッセージをUnified Merkle Treeスキームで送信し、ライブストリームの過去の時点でPeer Aをチューニングしようとする攻撃。
Solution: The timestamp in the SIGNED_INTEGRITY message protects against such replays. Subsequent traffic from Peer T will be ignored.
解決策：SIGNED_INTEGRITYメッセージのタイムスタンプは、そのようなリプレイから保護します。ピアTからの後続のトラフィックは無視されます。
o Threat REQUEST.1: Peer T could request lots from Peer A, leaving Peer A without resources for others.
o 脅威REQUEST.1：ピアTがピアAにロットをリクエストし、ピアAを他のリソースなしに残すことができます。
Solution: A limit is imposed on the upload capacity a single peer can consume, for example, by using an upload bandwidth scheduler that takes into account the need of multiple peers. A natural upper limit of this upload quotum is the bitrate of the content, taking into account that this may be variable.
解決策：たとえば、複数のピアの必要性を考慮したアップロード帯域幅スケジューラを使用することにより、単一のピアが消費できるアップロード容量に制限が課されます。このアップロードクォータの自然な上限は、コンテンツのビットレートです。これは変動する可能性があることを考慮しています。
o Threat CANCEL.1: Peer T sends CANCEL messages for content it never requested to Peer A.
o 脅威CANCEL.1：ピアTは、要求していないコンテンツのCANCELメッセージをピアAに送信します。
Solution: Peer A will detect the inconsistency of the messages and ignore them. Note that CANCEL messages may be received unexpectedly when a transport is used where REQUEST messages may be lost or reordered with respect to the subsequent CANCELs.
解決策：ピアAはメッセージの不整合を検出し、それらを無視します。 REQUESTメッセージが失われたり、後続のCANCELに関して並べ替えられたりするトランスポートが使用されている場合、CANCELメッセージが予期せず受信される可能性があることに注意してください。
o Threat CHOKE.1: Peer T sends REQUEST messages after Peer A sent Peer B a CHOKE message.
o 脅威CHOKE.1：ピアAがピアBにCHOKEメッセージを送信した後、ピアTはREQUESTメッセージを送信します。
Solution: Peer A will just discard the unwanted REQUESTs and resend the CHOKE, assuming it got lost.
解決策：ピアAは、チョークが失われたと想定して、不要なリクエストを破棄し、チョークを再送信します。
o Threat UNCHOKE.1: Peer T sends an UNCHOKE message to Peer A without having sent a CHOKE message before.
o 脅威UNCHOKE.1：ピアTは、以前にCHOKEメッセージを送信したことなくUNCHOKEメッセージをピアAに送信します。
Solution: Peer A can easily detect this violation of protocol state, and ignore it. Note this can also happen due to loss of a CHOKE message sent by a benign peer.
解決策：ピアAは、このプロトコル状態の違反を簡単に検出して無視できます。これは、良性のピアから送信されたCHOKEメッセージが失われたことによっても発生する可能性があることに注意してください。
o Threat UNCHOKE.2: Peer T sends an UNCHOKE message to Peer A, but subsequently does not respond to its REQUESTs.
o 脅威UNCHOKE.2：ピアTがUNCHOKEメッセージをピアAに送信しますが、その後、その要求に応答しません。
Solution: Peer A will consider Peer T to be a slow peer and not ask it again.
解決策：ピアAは、ピアTを低速ピアであると見なし、再度要求しないようにします。
o Secured against amplification and Eclipse attacks as described in Section 12.2.
o セクション12.2で説明されているように、増幅攻撃とEclipse攻撃から保護されています。
o Threat: Peer T could send a spoofed PEX_REQ or REQUEST from Peer B to Peer A, causing Peer A to send a PEX_RES/DATA to Peer B.
o 脅威：ピアTは、偽装されたPEX_REQまたはREQUESTをピアBからピアAに送信し、ピアAがピアBにPEX_RES / DATAを送信する可能性があります。
Solution: the message from Peer T won't be accepted unless Peer T does a handshake first, in which case the reply goes to Peer T, not victim Peer B.
解決策：ピアTがハンドシェイクを最初に行わない限り、ピアTからのメッセージは受け入れられません。その場合、応答は被害者のピアBではなくピアTに送信されます。
This section is regarding PPSP.SEC.REQ-2 in [RFC6972]. A receiving peer can detect malicious or faulty senders as just described, which it can then subsequently ignore. However, excluding such a bad peer from the system completely is complex. Random monitoring by trusted peers that would blacklist bad peers as described in [DETMAL] is one option. This mechanism does require extra capacity to run such trusted peers, which must be indistinguishable from regular peers, and requires a solution for the timely distribution of this blacklist to peers in a scalable manner.
このセクションは、[RFC6972]のPPSP.SEC.REQ-2に関するものです。受信ピアは、前述のように悪意のある、または欠陥のある送信者を検出でき、その後無視することができます。ただし、そのような悪いピアをシステムから完全に除外することは複雑です。 [DETMAL]で説明されているように、不良ピアをブラックリストに載せる信頼できるピアによるランダムな監視は、1つのオプションです。このメカニズムでは、このような信頼されたピアを実行するために追加の容量が必要であり、通常のピアと区別できない必要があり、このブラックリストをスケーラブルな方法でピアにタイムリーに配布するためのソリューションが必要です。
[CCITT.X690.2002] International Telephone and Telegraph Consultative Committee, "ASN.1 encoding rules: Specification of basic encoding Rules (BER), Canonical encoding rules (CER) and Distinguished encoding rules (DER)", CCITT Recommendation X.690, July 2002.
[CCITT.X690.2002] International Telephone and Telegraph Consultative Committee、 "ASN.1 encoding rules：Specification of basic encoding Rules（BER）、Canonical encoding rules（CER）and Distinguished encoding rules（DER）"、CCITT Recommendation X.690 、2002年7月。
[FIPS180-4] National Institute of Standards and Technology, Information Technology Laboratory, "Federal Information Processing Standards: Secure Hash Standard (SHS)", FIPS PUB 180-4, March 2012.
[FIPS180-4]国立標準技術研究所、情報技術研究所、「連邦情報処理標準：セキュアハッシュ標準（SHS）」、FIPS PUB 180-4、2012年3月。
[IANADNSSECALGNUM] IANA, "Domain Name System Security (DNSSEC) Algorithm Numbers", March 2014, <http://www.iana.org/assignments/dns-sec-alg-numbers>.
[IANADNSSECALGNUM] IANA、「ドメインネームシステムセキュリティ（DNSSEC）アルゴリズム番号」、2014年3月、<http://www.iana.org/assignments/dns-sec-alg-numbers>。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., J. de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、J。de Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、DOI 10.17487 / RFC1918、 1996年2月、<http://www.rfc-editor.org/info/rfc1918>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", RFC 3110, DOI 10.17487/RFC3110, May 2001, <http://www.rfc-editor.org/info/rfc3110>.
[RFC3110] Eastlake 3rd、D。、「ドメインネームシステム（DNS）のRSA / SHA-1 SIGおよびRSAキー」、RFC 3110、DOI 10.17487 / RFC3110、2001年5月、<http：//www.rfc-editor .org / info / rfc3110>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<http：/ /www.rfc-editor.org/info/rfc3986>。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <http://www.rfc-editor.org/info/rfc4034>.
[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNS Security Extensionsのリソースレコード」、RFC 4034、DOI 10.17487 / RFC4034、2005年3月、< http://www.rfc-editor.org/info/rfc4034>。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<http://www.rfc-editor.org/info/rfc4291>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<http://www.rfc-editor.org/info/rfc5280>。
[RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC", RFC 5702, DOI 10.17487/RFC5702, October 2009, <http://www.rfc-editor.org/info/rfc5702>.
[RFC5702] Jansen、J。、「DNSKEYでのRSAを使用したSHA-2アルゴリズムとDNSSECのRRSIGリソースレコードの使用」、RFC 5702、DOI 10.17487 / RFC5702、2009年10月、<http://www.rfc-editor.org / info / rfc5702>。
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <http://www.rfc-editor.org/info/rfc5905>.
[RFC5905] Mills、D.、Martin、J.、Ed。、Burbank、J。、およびW. Kasch、「Network Time Protocol Version 4：Protocol and Algorithms Specification」、RFC 5905、DOI 10.17487 / RFC5905、2010年6月、 <http://www.rfc-editor.org/info/rfc5905>。
[RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC", RFC 6605, DOI 10.17487/RFC6605, April 2012, <http://www.rfc-editor.org/info/rfc6605>.
[RFC6605] Hoffman、P。およびW. Wijngaards、「DNSSECの楕円曲線デジタル署名アルゴリズム（DSA）」、RFC 6605、DOI 10.17487 / RFC6605、2012年4月、<http://www.rfc-editor.org/info / rfc6605>。
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, DOI 10.17487/RFC6817, December 2012, <http://www.rfc-editor.org/info/rfc6817>.
[RFC6817] Shalunov、S.、Hazel、G.、Iyengar、J。、およびM. Kuehlewind、「Low Extra Delay Background Transport（LEDBAT）」、RFC 6817、DOI 10.17487 / RFC6817、2012年12月、<http：// www.rfc-editor.org/info/rfc6817>。
[ABMRKL] Bakker, A., "Merkle hash torrent extension", BitTorrent Enhancement Proposal 30, March 2009, <http://bittorrent.org/beps/bep_0030.html>.
[ABMRKL] Bakker、A。、「Merkle hash torrent extension」、BitTorrent Enhancement Proposal 30、2009年3月、<http://bittorrent.org/beps/bep_0030.html>。
[BINMAP] Grishchenko, V. and J. Pouwelse, "Binmaps: Hybridizing Bitmaps and Binary Trees", Delft University of Technology Parallel and Distributed Systems Report Series, Report number PDS-2011-005, ISSN 1387-2109, April 2009.
[BINMAP] Grishchenko、V。およびJ. Pouwelse、「Binmaps：Hybridizing Bitmaps and Binary Trees」、デルフト工科大学並列分散システムレポートシリーズ、レポート番号PDS-2011-005、ISSN 1387-2109、2009年4月。
[BITOS] Vlavianos, A., Iliofotou, M., Mathieu, F., and M. Faloutsos, "BiToS: Enhancing BitTorrent for Supporting Streaming Applications", IEEE INFOCOM Global Internet Symposium, Barcelona, Spain, April 2006.
[BITOS] Vlavianos、A.、Iliofotou、M.、Mathieu、F。、およびM. Faloutsos、「BiToS：Enhancing BitTorrent for Supporting Streaming Applications」、IEEE INFOCOMグローバルインターネットシンポジウム、バルセロナ、スペイン、2006年4月。
[BITTORRENT] Cohen, B., "The BitTorrent Protocol Specification", BitTorrent Enhancement Proposal 3, February 2008, <http://bittorrent.org/beps/bep_0003.html>.
[BITTORRENT]コーエンB。、「BitTorrentプロトコル仕様」、BitTorrent拡張提案3、2008年2月、<http://bittorrent.org/beps/bep_0003.html>。
[CLOSED] Borch, N., Mitchell, K., Arntzen, I., and D. Gabrijelcic, "Access Control to BitTorrent Swarms Using Closed Swarms", ACM workshop on Advanced Video Streaming Techniques for Peer-to-Peer Networks and Social Networking (AVSTP2P '10), Florence, Italy, October 2010, <http://doi.acm.org/10.1145/1877891.1877898>.
[クローズド] Borch、N.、Mitchell、K.、Arntzen、I。、およびD. Gabrijelcic、「クローズドスウォームを使用したBitTorrentスウォームへのアクセス制御」、ピアツーピアネットワークおよびソーシャル向けの高度なビデオストリーミングテクニックに関するACMワークショップネットワーキング（AVSTP2P '10）、イタリア、フィレンツェ、2010年10月、<http://doi.acm.org/10.1145/1877891.1877898>。
[DETMAL] Shetty, S., Galdames, P., Tavanapong, W., and Ying. Cai, "Detecting Malicious Peers in Overlay Multicast Streaming", IEEE Conference on Local Computer Networks, (LCN'06), Tampa, FL, USA, November 2006.
[DETMAL] Shetty、S.、Galdames、P.、Tavanapong、W。、およびYing。 Cai、「Detecting Malicious Peers in Overlay Multicast Streaming」、IEEE Conference on Local Computer Networks（LCN'06）、タンパ、FL、USA、2006年11月。
[ECLIPSE] Sit, E. and R. Morris, "Security Considerations for Peer-to-Peer Distributed Hash Tables", IPTPS '01: Revised Papers from the First International Workshop on Peer-to-Peer Systems, pp. 261-269, Springer-Verlag, 2002.
[ECLIPSE]シット、EおよびR.モリス、「ピアツーピア分散ハッシュテーブルのセキュリティに関する考慮事項」、IPTPS '01：ピアツーピアシステムに関する最初の国際ワークショップからの改訂された論文、pp。261-269 、Springer-Verlag、2002年。
[ECS] Jovanovikj, V., Gabrijelcic, D., and T. Klobucar, "Access Control in BitTorrent P2P Networks Using the Enhanced Closed Swarms Protocol", International Conference on Emerging Security Information, Systems and Technologies (SECURWARE 2011), pp. 97-102, Nice, France, August 2011.
[ECS] Jovanovikj、V.、Gabrijelcic、D。、およびT. Klobucar、「Enhanced Closed Swarms Protocolを使用したBitTorrent P2Pネットワークでのアクセス制御」、新しいセキュリティ情報、システム、テクノロジーに関する国際会議（SECURWARE 2011）、pp。 97-102、ニース、フランス、2011年8月。
[ECS-protocol] Gabrijelcic, D., "Enhanced Closed Swarm protocol", Work in Progress, draft-ppsp-gabrijelcic-ecs-01, June 2013.
[ECSプロトコル] Gabrijelcic、D。、「Enhanced Closed Swarm protocol」、Work in Progress、draft-ppsp-gabrijelcic-ecs-01、2013年6月。
[EPLIVEPERF] Bonald, T., Massoulie, L., Mathieu, F., Perino, D., and A. Twigg, "Epidemic live streaming: optimal performance trade-offs", Proceedings of the 2008 ACM SIGMETRICS International Conference on Measurement and Modeling of Computer Systems, Annapolis, MD, USA, June 2008.
[EPLIVEPERF] Bonald、T.、Massoulie、L.、Mathieu、F.、Perino、D。、およびA. Twigg、「流行のライブストリーミング：最適なパフォーマンスのトレードオフ」、2008 ACM SIGMETRICS International Conference on Measurementの議事録およびコンピュータシステムのモデリング、アナポリス、メリーランド州、米国、2008年6月。
[GIVE2GET] Mol, J., Pouwelse, J., Meulpolder, M., Epema, D., and H. Sips, "Give-to-Get: Free-riding-resilient Video-on-Demand in P2P Systems", Proceedings Multimedia Computing and Networking conference (Proceedings of SPIE, Vol. 6818), San Jose, CA, USA, January 2008.
[GIVE2GET] Mol、J.、Pouwelse、J.、Meulpolder、M.、Epema、D。、およびH. Sips、「Give-to-Get：Free-riding-resilient Video-on-Demand in P2P Systems」、 Proceedings Multimedia Computing and Networking Conference（Proceedings of SPIE、Vol。6818）、サンノゼ、カリフォルニア州、2008年1月。
[HAC01] Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook of Applied Cryptography", CRC Press, (Fifth Printing, August 2001), October 1996.
[HAC01] Menezes、A.、van Oorschot、P。、およびS. Vanstone、「応用暗号法ハンドブック」、CRC Press、（Fifth Printing、2001年8月）、1996年10月。
[JIM11] Jimenez, R., Osmani, F., and B. Knutsson, "Sub-Second Lookups on a Large-Scale Kademlia-Based Overlay", IEEE International Conference on Peer-to-Peer Computing (P2P'11), Kyoto, Japan, August 2011.
[JIM11] Jimenez、R.、Osmani、F。、およびB. Knutsson、「大規模なKademliaベースのオーバーレイの2次ルックアップ」、ピアツーピアコンピューティングに関するIEEE国際会議（P2P'11）、京都、日本、2011年8月。
[LBT] Rossi, D., Testa, C., Valenti, S., and L. Muscariello, "LEDBAT: the new BitTorrent congestion control protocol", Computer Communications and Networks (ICCCN), Zurich, Switzerland, August 2010.
[LBT] Rossi、D.、Testa、C.、Valenti、S。、およびL. Muscariello、「LEDBAT：新しいBitTorrent輻輳制御プロトコル」、コンピュータ通信およびネットワーク（ICCCN）、スイス、チューリッヒ、2010年8月。
[LCOMPL] Testa, C. and D. Rossi, "On the impact of uTP on BitTorrent completion time", IEEE International Conference on Peer-to-Peer Computing (P2P'11), Kyoto, Japan, August 2011.
[LCOMPL]テスタC.およびD.ロッシ、「BitTorrent完了時間に対するuTPの影響について」、ピアツーピアコンピューティングに関するIEEE国際会議（P2P'11）、京都、日本、2011年8月。
[MERKLE] Merkle, R., "Secrecy, Authentication, and Public Key Systems", Ph.D. thesis, Dept. of Electrical Engineering, Stanford University, CA, USA, pp 40-45, 1979.
[MERKLE]マークル、R。、「秘密、認証、公開鍵システム」、Ph.D。論文、米国カリフォルニア州スタンフォード大学電気工学科、pp 40-45、1979。
[P2PWIKI] Bakker, A., Petrocco, R., Dale, M., Gerber, J., Grishchenko, V., Rabaioli, D., and J. Pouwelse, "Online video using BitTorrent and HTML5 applied to Wikipedia", IEEE International Conference on Peer-to-Peer Computing (P2P'10), Delft, The Netherlands, August 2010.
[P2PWIKI] Bakker、A.、Petrocco、R.、Dale、M.、Gerber、J.、Grishchenko、V.、Rabaioli、D。、およびJ. Pouwelse、「BitTorrentおよびHTML5を使用したオンラインビデオをWikipediaに適用」、ピアツーピアコンピューティングに関するIEEE国際会議（P2P'10）、オランダ、デルフト、2010年8月。
[POLLIVE] Dhungel, P., Hei, Xiaojun., Ross, K., and N. Saxena, "Pollution in P2P Live Video Streaming", International Journal of Computer Networks & Communications (IJCNC) Vol. 1, No. 2, Jul 2009.
[POLLIVE] Dhungel、P.、Hei、Xiaojun。、Ross、K。、およびN. Saxena、「P2Pライブビデオストリーミングの汚染」、International Journal of Computer Networks＆Communications（IJCNC）Vol。 1、No。2、2009年7月。
[PPSP-TP] Cruz, R., Nunes, M., Yingjie, G., Xia, J., Huang, R., Taveira, J., and D. Lingli, "PPSP Tracker Protocol-Base Protocol (PPSP-TP/1.0)", Work in Progress, draft-ietf-ppsp-base-tracker-protocol-09, March 2015.
[PPSP-TP] Cruz、R.、Nunes、M.、Yingjie、G.、Xia、J.、Huang、R.、Taveira、J。、およびD. Lingli、「PPSP Tracker Protocol-Base Protocol（PPSP- TP / 1.0） "、進行中の作業、draft-ietf-ppsp-base-tracker-protocol-09、2015年3月。
[PPSPPERF] Petrocco, R., Pouwelse, J., and D. Epema, "Performance Analysis of the Libswift P2P Streaming Protocol", IEEE International Conference on Peer-to-Peer Computing (P2P'12), Tarragona, Spain, September 2012.
[PPSPPERF] Petrocco、R.、Pouwelse、J。、およびD. Epema、「Libswift P2Pストリーミングプロトコルのパフォーマンス分析」、ピアツーピアコンピューティングに関するIEEE国際会議（P2P'12）、スペイン、タラゴナ、9月2012。
[RFC2564] Kalbfleisch, C., Krupczak, C., Presuhn, R., and J. Saperia, "Application Management MIB", RFC 2564, DOI 10.17487/RFC2564, May 1999, <http://www.rfc-editor.org/info/rfc2564>.
[RFC2564] Kalbfleisch、C.、Krupczak、C.、Presuhn、R。、およびJ. Saperia、「アプリケーション管理MIB」、RFC 2564、DOI 10.17487 / RFC2564、1999年5月、<http：//www.rfc-editor .org / info / rfc2564>。
[RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", RFC 2790, DOI 10.17487/RFC2790, March 2000, <http://www.rfc-editor.org/info/rfc2790>.
[RFC2790] Waldbusser、S。およびP. Grillo、「Host Resources MIB」、RFC 2790、DOI 10.17487 / RFC2790、2000年3月、<http://www.rfc-editor.org/info/rfc2790>。
[RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to Accounting Management", RFC 2975, DOI 10.17487/RFC2975, October 2000, <http://www.rfc-editor.org/info/rfc2975>.
[RFC2975] Aboba、B.、Arkko、J。、およびD. Harrington、「Introduction to Accounting Management」、RFC 2975、DOI 10.17487 / RFC2975、2000年10月、<http://www.rfc-editor.org/info / rfc2975>。
[RFC3365] Schiller, J., "Strong Security Requirements for Internet Engineering Task Force Standard Protocols", BCP 61, RFC 3365, DOI 10.17487/RFC3365, August 2002, <http://www.rfc-editor.org/info/rfc3365>.
[RFC3365] Schiller、J。、「インターネット技術特別調査委員会標準プロトコルの強力なセキュリティ要件」、BCP 61、RFC 3365、DOI 10.17487 / RFC3365、2002年8月、<http://www.rfc-editor.org/info/ rfc3365>。
[RFC3729] Waldbusser, S., "Application Performance Measurement MIB", RFC 3729, DOI 10.17487/RFC3729, March 2004, <http://www.rfc-editor.org/info/rfc3729>.
[RFC3729] Waldbusser、S。、「アプリケーションパフォーマンス測定MIB」、RFC 3729、DOI 10.17487 / RFC3729、2004年3月、<http://www.rfc-editor.org/info/rfc3729>。
[RFC4113] Fenner, B. and J. Flick, "Management Information Base for the User Datagram Protocol (UDP)", RFC 4113, DOI 10.17487/RFC4113, June 2005, <http://www.rfc-editor.org/info/rfc4113>.
[RFC4113] Fenner、B。およびJ. Flick、「ユーザーデータグラムプロトコル（UDP）の管理情報ベース」、RFC 4113、DOI 10.17487 / RFC4113、2005年6月、<http://www.rfc-editor.org/ info / rfc4113>。
[RFC4150] Dietz, R. and R. Cole, "Transport Performance Metrics MIB", RFC 4150, DOI 10.17487/RFC4150, August 2005, <http://www.rfc-editor.org/info/rfc4150>.
[RFC4150] Dietz、R。およびR. Cole、「Transport Performance Metrics MIB」、RFC 4150、DOI 10.17487 / RFC4150、2005年8月、<http://www.rfc-editor.org/info/rfc4150>。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, <http://www.rfc-editor.org/info/rfc4193>.
[RFC4193] Hinden、R。およびB. Haberman、「Unique Local IPv6 Unicast Addresses」、RFC 4193、DOI 10.17487 / RFC4193、2005年10月、<http://www.rfc-editor.org/info/rfc4193>。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、DOI 10.17487 / RFC4301、2005年12月、<http://www.rfc-editor.org/info/rfc4301>。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <http://www.rfc-editor.org/info/rfc4821>.
[RFC4821] Mathis、M。およびJ. Heffner、「Packetization Layer Path MTU Discovery」、RFC 4821、DOI 10.17487 / RFC4821、2007年3月、<http://www.rfc-editor.org/info/rfc4821>。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <http://www.rfc-editor.org/info/rfc4960>.
[RFC4960] Stewart、R.、Ed。、「Stream Control Transmission Protocol」、RFC 4960、DOI 10.17487 / RFC4960、2007年9月、<http://www.rfc-editor.org/info/rfc4960>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <http://www.rfc-editor.org/info/rfc5389>.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「NAT用セッショントラバーサルユーティリティ（STUN）」、RFC 5389、DOI 10.17487 / RFC5389、2008年10月、<http：// www.rfc-editor.org/info/rfc5389>。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, DOI 10.17487/RFC5424, March 2009, <http://www.rfc-editor.org/info/rfc5424>.
[RFC5424] Gerhards、R。、「The Syslog Protocol」、RFC 5424、DOI 10.17487 / RFC5424、2009年3月、<http://www.rfc-editor.org/info/rfc5424>。
[RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, DOI 10.17487/RFC5706, November 2009, <http://www.rfc-editor.org/info/rfc5706>.
[RFC5706]ハリントン、D。、「新しいプロトコルとプロトコル拡張の操作と管理を考慮するためのガイドライン」、RFC 5706、DOI 10.17487 / RFC5706、2009年11月、<http://www.rfc-editor.org/info/rfc5706 >。
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, DOI 10.17487/RFC5971, October 2010, <http://www.rfc-editor.org/info/rfc5971>.
[RFC5971] Schulzrinne、H。およびR. Hancock、「GIST：General Internet Signaling Transport」、RFC 5971、DOI 10.17487 / RFC5971、2010年10月、<http://www.rfc-editor.org/info/rfc5971>。
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, <http://www.rfc-editor.org/info/rfc6194>.
[RFC6194] Polk、T.、Chen、L.、Turner、S。、およびP. Hoffman、「SHA-0およびSHA-1メッセージダイジェストアルゴリズムのセキュリティに関する考慮事項」、RFC 6194、DOI 10.17487 / RFC6194、3月2011、<http://www.rfc-editor.org/info/rfc6194>。
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <http://www.rfc-editor.org/info/rfc6241>.
[RFC6241] Enns、R。、編、Bjorklund、M。、編、Schoenwaelder、J。、編、およびA. Bierman、編、「Network Configuration Protocol（NETCONF）」、RFC 6241、DOI 10.17487 / RFC6241、2011年6月、<http://www.rfc-editor.org/info/rfc6241>。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<http://www.rfc-editor.org/info/rfc6347>。
[RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design Considerations for Protocol Extensions", RFC 6709, DOI 10.17487/RFC6709, September 2012, <http://www.rfc-editor.org/info/rfc6709>.
[RFC6709] Carpenter、B.、Aboba、B.、Ed。、およびS. Cheshire、「プロトコル拡張の設計上の考慮事項」、RFC 6709、DOI 10.17487 / RFC6709、2012年9月、<http：//www.rfc-editor .org / info / rfc6709>。
[RFC6972] Zhang, Y. and N. Zong, "Problem Statement and Requirements of the Peer-to-Peer Streaming Protocol (PPSP)", RFC 6972, DOI 10.17487/RFC6972, July 2013, <http://www.rfc-editor.org/info/rfc6972>.
[RFC6972] Zhang、Y。およびN. Zong、「Problem Statement and Requirements of the Peer-to-Peer Streaming Protocol（PPSP）」、RFC 6972、DOI 10.17487 / RFC6972、2013年7月、<http：//www.rfc -editor.org/info/rfc6972>。
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., Previdi, S., Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", RFC 7285, DOI 10.17487/RFC7285, September 2014, <http://www.rfc-editor.org/info/rfc7285>.
[RFC7285]アリミ、R。、エド、ペンノ、R。、エド、ヤン、Y。、エド、キーゼル、S。、プレビディ、S。、ルーム、W。、シャルノフ、S.、R。 Woundy、「Application-Layer Traffic Optimization（ALTO）Protocol」、RFC 7285、DOI 10.17487 / RFC7285、2014年9月、<http://www.rfc-editor.org/info/rfc7285>。
[SECDHTS] Urdaneta, G., Pierre, G., and M. van Steen, "A Survey of DHT Security Techniques", ACM Computing Surveys, vol. 43(2), January 2011.
[SECDHTS]アーダネータ、G。、ピエール、G。、およびM.ヴァンスティーン、「DHTセキュリティ技術の調査」、ACMコンピューティング調査、vol。 43（2）、2011年1月。
[SIGMCAST] Wong, C. and S. Lam, "Digital Signatures for Flows and Multicasts", IEEE/ACM Transactions on Networking 7(4), pp. 502-513, August 1999.
[SIGMCAST] Wong、C。およびS. Lam、「フローとマルチキャストのデジタル署名」、IEEE / ACM Transactions on Networking 7（4）、pp。502-513、1999年8月。
[SPS] Jesi, G., Montresor, A., and M. van Steen, "Secure Peer Sampling", Computer Networks vol. 54(12), pp. 2086-2098, Elsevier, August 2010.
[SPS] Jesi、G.、Montresor、A。、およびM. van Steen、「Secure Peer Sampling」、Computer Networks vol。 54（12）、2086〜2098ページ、エルゼビア、2010年8月。
[SWIFTIMPL] Grishchenko, V., Paananen, J., Pronchenkov, A., Bakker, A., and R. Petrocco, "Swift reference implementation", 2015, <https://github.com/libswift/libswift>.
[SWIFTIMPL] Grishchenko、V.、Paananen、J.、Pronchenkov、A.、Bakker、A。、およびR. Petrocco、「Swift reference implementation」、2015、<https://github.com/libswift/libswift>。
[TIT4TAT] Cohen, B., "Incentives Build Robustness in BitTorrent", 1st Workshop on Economics of Peer-to-Peer Systems, Berkeley, CA, USA, May 2003.
[TIT4TAT]コーエン、B。、「インセンティブはBitTorrentで堅牢性を構築する」、ピアツーピアシステムの経済学に関する第1回ワークショップ、米国カリフォルニア州バークレー、2003年5月。
Acknowledgements
謝辞
Arno Bakker, Riccardo Petrocco, and Victor Grishchenko are partially supported by the P2P-Next project <http://www.p2p-next.org/>, a research project supported by the European Community under its 7th Framework Programme (grant agreement no. 216217). The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the P2P-Next project or the European Commission.
Arno Bakker、Riccardo Petrocco、Victor Grishchenkoは、P7P-Nextプロジェクト<http://www.p2p-next.org/>によって部分的にサポートされています。 。216217）。ここに含まれる見解と結論は著者の見解と結論であり、P2P-Nextプロジェクトまたは欧州委員会の公式のポリシーまたは承認を、明示的にも暗示的にも、必ずしも表すものとして解釈すべきではありません。
PPSPP was designed by Victor Grishchenko at Technische Universiteit Delft under supervision of Johan Pouwelse. The authors would like to thank the following people for their contributions to this document: the chairs (Martin Stiemerling, Yunfei Zhang, Stefano Previdi, and Ning Zong) and members of the IETF PPSP working group, and Mihai Capota, Raul Jimenez, Flutra Osmani, and Raynor Vliegendhart.
PPSPPは、Johan Pouwelseの監督の下、Technische Universiteit DelftのVictor Grishchenkoによって設計されました。著者は、この文書への貢献に対して次の人々に感謝します：議長（Martin Stiemerling、Yunfei Zhang、Stefano Previdi、およびNing Zong）とIETF PPSPワーキンググループのメンバー、Mihai Capota、Raul Jimenez、Flutra Osmani 、およびRaynor Vliegendhart。
Authors' Addresses
著者のアドレス
Arno Bakker Vrije Universiteit Amsterdam De Boelelaan 1081 Amsterdam 1081HV The Netherlands
アルノバッカーVU大学アムステルダムデボエレラン1081アムステルダム1081HVオランダ
Email: arno@cs.vu.nl
Riccardo Petrocco Technische Universiteit Delft Mekelweg 4 Delft 2628CD The Netherlands
リカルドペトロッコデルフト工科大学Mekelweg 4デルフト2628CDオランダ
Email: r.petrocco@gmail.com
Victor Grishchenko Technische Universiteit Delft Mekelweg 4 Delft 2628CD The Netherlands
ビクターグリシェンコデルフト工科大学Mekelweg 4デルフト2628CDオランダ
Email: victor.grishchenko@gmail.com