Internet Engineering Task Force (IETF) R. Cruz
Request for Comments: 7846 M. Nunes
Category: Standards Track IST/INESC-ID/INOV
ISSN: 2070-1721 J. Xia
R. Huang, Ed.
Huawei
J. Taveira
IST/INOV
D. Lingli
China Mobile
May 2016
Internet Engineering Task Force (IETF) R. Cruz
Request for Comments: 7846 M. Nunes
Category: Standards Track IST/INESC-ID/INOV
ISSN: 2070-1721 J. Xia
R. Huang, Ed.
Huawei
J. Taveira
IST/INOV
D. Lingli
China Mobile
May 2016
Peer-to-Peer Streaming Tracker Protocol (PPSTP)
点对点流跟踪协议（PPSTP）
Abstract
摘要
This document specifies the base Peer-to-Peer Streaming Tracker Protocol (PPSTP) version 1, an application-layer control (signaling) protocol for the exchange of meta information between trackers and peers. The specification outlines the architecture of the protocol and its functionality; it also describes message flows, message processing instructions, message formats, formal syntax, and semantics. The PPSTP enables cooperating peers to form content-streaming overlay networks to support near real-time delivery of structured media content (audio, video, and associated timed text and metadata), such as adaptive multi-rate, layered (scalable), and multi-view (3D) videos in live, time-shifted, and on-demand modes.
本文件规定了基本对等流跟踪器协议（PPSTP）版本1，这是一种应用层控制（信令）协议，用于跟踪器和对等方之间交换元信息。该规范概述了协议的体系结构及其功能；它还描述了消息流、消息处理指令、消息格式、形式语法和语义。PPSTP使合作的对等方能够形成内容流覆盖网络，以支持结构化媒体内容（音频、视频以及相关的定时文本和元数据）的近实时交付，例如实时、时移和点播模式下的自适应多速率、分层（可伸缩）和多视图（3D）视频。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc7846.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7846.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Terminology ................................................4
1.2. Design Overview ............................................6
1.2.1. Typical PPSP Session ................................7
1.2.2. Example of a PPSP Session ...........................7
2. Protocol Architecture and Functional View ......................10
2.1. Messaging Model ...........................................10
2.2. Request/Response Model ....................................10
2.3. State Machines and Flows of the Protocol ..................12
2.3.1. Normal Operation ...................................14
2.3.2. Error Conditions ...................................15
3. Protocol Specification .........................................16
3.1. Presentation Language .....................................16
3.2. Resource Element Types ....................................16
3.2.1. Version ............................................16
3.2.2. Peer Number Element ................................17
3.2.3. Swarm Action Element ...............................18
3.2.4. Peer Information Elements ..........................18
3.2.5. Statistics and Status Information Element ..........20
3.3. Requests and Responses ....................................21
3.3.1. Request Types ......................................21
3.3.2. Response Types .....................................21
3.3.3. Request Element ....................................22
3.3.4. Response Element ...................................23
3.4. PPSTP Message Element .....................................24
4. Protocol Specification: Encoding and Operation .................24
4.1. Requests and Responses ....................................25
4.1.1. CONNECT Request ....................................25
4.1.1.1. Example ...................................28
4.1.2. FIND Request .......................................32
4.1.2.1. Example ...................................33
1. Introduction ....................................................4
1.1. Terminology ................................................4
1.2. Design Overview ............................................6
1.2.1. Typical PPSP Session ................................7
1.2.2. Example of a PPSP Session ...........................7
2. Protocol Architecture and Functional View ......................10
2.1. Messaging Model ...........................................10
2.2. Request/Response Model ....................................10
2.3. State Machines and Flows of the Protocol ..................12
2.3.1. Normal Operation ...................................14
2.3.2. Error Conditions ...................................15
3. Protocol Specification .........................................16
3.1. Presentation Language .....................................16
3.2. Resource Element Types ....................................16
3.2.1. Version ............................................16
3.2.2. Peer Number Element ................................17
3.2.3. Swarm Action Element ...............................18
3.2.4. Peer Information Elements ..........................18
3.2.5. Statistics and Status Information Element ..........20
3.3. Requests and Responses ....................................21
3.3.1. Request Types ......................................21
3.3.2. Response Types .....................................21
3.3.3. Request Element ....................................22
3.3.4. Response Element ...................................23
3.4. PPSTP Message Element .....................................24
4. Protocol Specification: Encoding and Operation .................24
4.1. Requests and Responses ....................................25
4.1.1. CONNECT Request ....................................25
4.1.1.1. Example ...................................28
4.1.2. FIND Request .......................................32
4.1.2.1. Example ...................................33
4.1.3. STAT_REPORT Request ................................34
4.1.3.1. Example ...................................35
4.2. Response Element in Response Messages .....................36
4.3. Error and Recovery Conditions .............................37
4.4. Parsing of Unknown Fields in message-body .................38
5. Operations and Manageability ...................................38
5.1. Operational Considerations ................................38
5.1.1. Installation and Initial Setup .....................38
5.1.2. Migration Path .....................................39
5.1.3. Requirements on Other Protocols and
Functional Components ..............................39
5.1.4. Impact on Network Operation ........................39
5.1.5. Verifying Correct Operation ........................40
5.2. Management Considerations .................................40
5.2.1. Interoperability ...................................40
5.2.2. Management Information .............................40
5.2.3. Fault Management ...................................41
5.2.4. Configuration Management ...........................41
5.2.5. Accounting Management ..............................41
5.2.6. Performance Management .............................41
5.2.7. Security Management ................................41
6. Security Considerations ........................................42
6.1. Authentication between Tracker and Peers ..................42
6.2. Content Integrity Protection against Polluting
Peers/Trackers ............................................43
6.3. Residual Attacks and Mitigation ...........................43
6.4. Pro-incentive Parameter Trustfulness ......................44
6.5. Privacy for Peers .........................................44
7. Guidelines for Extending PPSTP .................................45
7.1. Forms of PPSTP Extension ..................................45
7.2. Issues to Be Addressed in PPSTP Extensions ................47
8. IANA Considerations ............................................48
8.1. MIME Type Registry ........................................48
8.2. PPSTP Version Number Registry .............................49
8.3. PPSTP Request Type Registry ...............................49
8.4. PPSTP Error Code Registry .................................50
9. References .....................................................51
9.1. Normative References ......................................51
9.2. Informative References ....................................53
Acknowledgments ...................................................54
Authors' Addresses ................................................55
4.1.3. STAT_REPORT Request ................................34
4.1.3.1. Example ...................................35
4.2. Response Element in Response Messages .....................36
4.3. Error and Recovery Conditions .............................37
4.4. Parsing of Unknown Fields in message-body .................38
5. Operations and Manageability ...................................38
5.1. Operational Considerations ................................38
5.1.1. Installation and Initial Setup .....................38
5.1.2. Migration Path .....................................39
5.1.3. Requirements on Other Protocols and
Functional Components ..............................39
5.1.4. Impact on Network Operation ........................39
5.1.5. Verifying Correct Operation ........................40
5.2. Management Considerations .................................40
5.2.1. Interoperability ...................................40
5.2.2. Management Information .............................40
5.2.3. Fault Management ...................................41
5.2.4. Configuration Management ...........................41
5.2.5. Accounting Management ..............................41
5.2.6. Performance Management .............................41
5.2.7. Security Management ................................41
6. Security Considerations ........................................42
6.1. Authentication between Tracker and Peers ..................42
6.2. Content Integrity Protection against Polluting
Peers/Trackers ............................................43
6.3. Residual Attacks and Mitigation ...........................43
6.4. Pro-incentive Parameter Trustfulness ......................44
6.5. Privacy for Peers .........................................44
7. Guidelines for Extending PPSTP .................................45
7.1. Forms of PPSTP Extension ..................................45
7.2. Issues to Be Addressed in PPSTP Extensions ................47
8. IANA Considerations ............................................48
8.1. MIME Type Registry ........................................48
8.2. PPSTP Version Number Registry .............................49
8.3. PPSTP Request Type Registry ...............................49
8.4. PPSTP Error Code Registry .................................50
9. References .....................................................51
9.1. Normative References ......................................51
9.2. Informative References ....................................53
Acknowledgments ...................................................54
Authors' Addresses ................................................55
The Peer-to-Peer Streaming Protocol (PPSP) is composed of two protocols: the Tracker Protocol (defined in this document) and the Peer Protocol (defined in [RFC7574]). [RFC6972] specifies that the Tracker Protocol should standardize the messages between PPSP peers and PPSP trackers and also defines the requirements.
对等流协议（PPSP）由两个协议组成：跟踪协议（定义见本文档）和对等协议（定义见[RFC7574]）。[RFC6972]规定跟踪器协议应标准化PPSP对等点和PPSP跟踪器之间的消息，并定义要求。
The Peer-to-Peer Streaming Tracker Protocol (PPSTP) provides communication between trackers and peers by which peers send meta information to trackers, report streaming status, and obtain peer lists from trackers.
对等流跟踪器协议（PPSTP）提供跟踪器和对等体之间的通信，对等体通过该协议向跟踪器发送元信息，报告流状态，并从跟踪器获取对等体列表。
The PPSP architecture requires PPSP peers to be able to communicate with a tracker in order to participate in a particular streaming content swarm. This centralized tracker service is used by PPSP peers for acquisition of peer lists.
PPSP体系结构要求PPSP对等方能够与跟踪器通信，以便参与特定的流式内容群。PPSP对等方使用此集中式跟踪服务获取对等方列表。
The signaling and the media data transfer between PPSP peers is not in the scope of this specification.
PPSP对等点之间的信令和媒体数据传输不在本规范的范围内。
This document introduces a base Peer-to-Peer Streaming Tracker Protocol (PPSTP) that satisfies the requirements in [RFC6972].
本文档介绍了满足[RFC6972]要求的基本对等流跟踪协议（PPSTP）。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
absolute time: Expressed as ISO 8601 timestamps, using zero UTC offset. Fractions of a second may be indicated, for example, December 25, 2010 at 14h56 and 20.25 seconds in basic format is 20101225T145620.25Z and in extended format is 2010-12-25T14:56:20.25Z.
绝对时间：表示为ISO 8601时间戳，使用零UTC偏移量。例如，在2010年12月25日的14h56和20.25秒处，可以表示一秒的分数，基本格式为20101225T145620.25Z，扩展格式为2010-12-25T14:56:20.25Z。
chunk: An uniformly atomic subset of the resource that constitutes the basic unit of data organized in P2P streaming for storage, scheduling, advertisement, and exchange among peers.
区块：资源的统一原子子集，构成P2P流中组织的数据的基本单元，用于存储、调度、广告和对等方之间的交换。
chunk ID: A unique resource identifier for a chunk. The identifier type depends on the addressing scheme used, i.e., an integer, an HTTP-URL, and possibly a byte-range. The identifier type is described in the Media Presentation Description (MPD).
区块ID：区块的唯一资源标识符。标识符类型取决于所使用的寻址方案，即整数、HTTP-URL和可能的字节范围。标识符类型在媒体呈现说明（MPD）中进行了描述。
LEECH: The peers in a swarm that download content from other peers as well as contribute downloaded content with others. A LEECH should join the swarm with uncompleted media content.
水蛭：群中的同龄人，他们从其他同龄人那里下载内容，并与其他人一起贡献下载的内容。水蛭应该以未完成的媒体内容加入蜂群。
MPD (Media Presentation Description): Formalized description for a media presentation, i.e., describes the structure of the media, namely, the representations, the codecs used, the chunks, and the corresponding addressing scheme.
MPD（媒体呈现描述）：媒体呈现的形式化描述，即描述媒体的结构，即表示、使用的编解码器、块和相应的寻址方案。
peer: A participant in a P2P streaming system that not only receives streaming content, but also caches and streams streaming content to other participants.
对等方：P2P流媒体系统中的参与者，不仅接收流媒体内容，还缓存流媒体内容并将其流给其他参与者。
peer ID: The identifier of a peer such that other peers, or the Tracker, can refer to the peer using its ID. The peer ID is mandatory, can take the form of a universally unique identifier (UUID), defined in [RFC4122], and can be bound to a network address of the peer, i.e., an IP address or a uniform resource identifier/locator (URI/URL) that uniquely identifies the corresponding peer in the network. The peer ID and any required security certificates are obtained from an offline enrollment server.
对等机ID：对等机的标识符，以便其他对等机或跟踪器可以使用其ID引用对等机。对等机ID是必需的，可以采用[RFC4122]中定义的通用唯一标识符（UUID）的形式，并且可以绑定到对等机的网络地址，即IP地址或统一资源标识符/定位器（URI/URL）唯一标识网络中对应对等方的。对等ID和任何必需的安全证书都是从脱机注册服务器获得的。
peer list: A list of peers that are in the same swarm maintained by the tracker. A peer can fetch the peer list of a swarm from the tracker.
对等点列表：由跟踪器维护的同一群中的对等点列表。对等方可以从跟踪器中获取群的对等方列表。
PPSP: The abbreviation of Peer-to-Peer Streaming Protocol.
PPSP：对等流媒体协议的缩写。
PPSTP: The abbreviation of Peer-to-Peer Streaming Tracker Protocol.
PPSTP：对等流跟踪协议的缩写。
SEEDER: The peers in a swarm that only contribute the content they have to others. A SEEDER should join the swarm with complete media content.
播种者：群体中的同龄人，他们只向其他人贡献他们所拥有的内容。播种者应该加入群体，并拥有完整的媒体内容。
service portal: A logical entity typically used for client enrollment and for publishing, searching, and retrieving content information. It is usually located in a server of a content provider.
服务门户：通常用于客户端注册以及发布、搜索和检索内容信息的逻辑实体。它通常位于内容提供商的服务器中。
swarm: A group of peers that exchange data to distribute chunks of the same content (e.g., video/audio program, digital file, etc.) at a given time.
swarm：在给定时间交换数据以分发相同内容块（例如视频/音频节目、数字文件等）的一组对等方。
swarm ID: The identifier of a swarm containing a group of peers sharing common streaming content. The swarm ID may use a universally unique identifier (UUID), e.g., a 64- or 128-bit datum to refer to the content resource being shared among peers.
swarm ID：包含共享公共流媒体内容的一组对等方的swarm的标识符。swarm ID可以使用通用唯一标识符（UUID），例如，64位或128位数据来表示在对等方之间共享的内容资源。
tracker: A directory service that maintains a list of peers participating in a specific audio/video channel or in the distribution of a streaming file. It is a logical component that can be deployed in a centralized or distributed way.
跟踪器：一种目录服务，用于维护参与特定音频/视频频道或流文件分发的对等方列表。它是一个逻辑组件，可以以集中式或分布式方式部署。
transaction ID: The identifier of a request from the peer to the tracker. It is used to disambiguate responses that may arrive in a different order than the corresponding requests.
事务ID：从对等方到跟踪器的请求的标识符。它用于消除可能以不同于相应请求的顺序到达的响应的歧义。
The functional entities related to peer-to-peer streaming protocols are the Client Media Player, the service portal, the tracker, and the peers. The complete description of Client Media Player and service portal is not discussed here, as they are not in the scope of the specification. The functional entities directly involved in PPSTP are trackers and peers (which may support different capabilities).
与点对点流协议相关的功能实体是客户端媒体播放器、服务门户、跟踪器和对等方。此处不讨论客户端媒体播放器和服务门户的完整描述，因为它们不在本规范的范围内。PPSTP中直接涉及的功能实体是跟踪器和对等体（可能支持不同的功能）。
The Client Media Player is a logical entity providing direct interface to the end user at the client device and includes the functions to select, request, decode, and render content. The Client Media Player may interface with the local peer application using the standard format for HTTP request and response messages [RFC7230].
客户端媒体播放器是在客户端设备处向最终用户提供直接接口的逻辑实体，包括选择、请求、解码和呈现内容的功能。客户端媒体播放器可以使用HTTP请求和响应消息的标准格式[RFC7230]与本地对等应用程序接口。
The service portal is a logical entity typically used for client enrollment and for publishing, searching, and retrieving content information.
服务门户是一个逻辑实体，通常用于客户端注册以及发布、搜索和检索内容信息。
A peer corresponds to a logical entity (typically in a user device) that actually participates in sharing media content. Peers are organized in various swarms; each swarm corresponds to the group of peers streaming certain content at any given time.
对等方对应于实际参与共享媒体内容的逻辑实体（通常在用户设备中）。同龄人被组织成不同的群体；每个群对应于在任何给定时间流式传输特定内容的对等组。
A tracker is a logical entity that maintains the lists of peers storing chunks for a specific live media channel or on-demand media streaming content, answers queries from peers, and collects information on the activity of peers. While a tracker may have an underlying implementation consisting of more than one physical node, logically, the tracker can most simply be thought of as a single element; in this document, it will be treated as a single logical entity. Communication between these physical nodes to present them as a single tracker to peers is not considered in PPSTP, which is a protocol between a tracker and a peer.
跟踪器是一个逻辑实体，它维护存储特定直播媒体频道或点播媒体流内容块的对等方列表，回答对等方的查询，并收集对等方活动的信息。虽然跟踪器可能具有由多个物理节点组成的底层实现，但从逻辑上讲，跟踪器可以最简单地被视为单个元素；在本文档中，它将被视为单个逻辑实体。PPSTP不考虑这些物理节点之间的通信，将它们作为单个跟踪器呈现给对等方，PPSTP是跟踪器和对等方之间的协议。
PPSTP is not used to exchange actual content data (either on demand or live streaming) with peers, but information about which peers can provide the content. PPSTP is not designed for applications for which in-sync reception is needed.
PPSTP不用于与对等方交换实际内容数据（点播或直播），而是关于哪些对等方可以提供内容的信息。PPSTP不是为需要同步接收的应用而设计的。
When a peer wants to receive streaming of selected content (LEECH mode):
当对等方希望接收选定内容的流式传输时（LEECH模式）：
1. Peer connects to a tracker and joins a swarm.
1. 对等方连接到跟踪器并加入群。
2. Peer acquires a list of other peers in the swarm from the tracker.
2. Peer从跟踪器获取群中其他Peer的列表。
3. Peer exchanges its content availability with the peers on the obtained peer list.
3. 对等方与获得的对等方列表上的对等方交换其内容可用性。
4. Peer identifies the peers with desired content.
4. Peer标识具有所需内容的对等方。
5. Peer requests content from the identified peers.
5. 对等方从已识别的对等方请求内容。
When a peer wants to share streaming content (SEEDER mode) with other peers:
当对等方希望与其他对等方共享流媒体内容（种子模式）时：
1. Peer connects to a tracker.
1. 对等连接到跟踪器。
2. Peer sends information to the tracker about the swarms it belongs to (joined swarms).
2. 对等向跟踪器发送有关其所属群集（已加入群集）的信息。
3. Peer waits for other peers in LEECH mode to connect with it (see steps 3-5 in the previous list).
3. 对等机等待处于LEECH模式的其他对等机与其连接（请参阅上一列表中的步骤3-5）。
After having been disconnected due to some termination conditions or user controls, a peer can resume previous activity by connecting and re-joining the corresponding swarm(s).
由于某些终止条件或用户控制而断开连接后，对等方可以通过连接并重新加入相应的群来恢复先前的活动。
In order to be able to bootstrap in the P2P network, a peer must first obtain a peer ID and any required security certificates or authorization tokens from an enrollment service (end-user registration). The peer ID MUST be unique (see the definition of "peer ID" in Section 1.1); however, the representation of the peer ID is not considered in this document.
为了能够在P2P网络中引导，对等方必须首先从注册服务（最终用户注册）获取对等方ID和任何必需的安全证书或授权令牌。对等ID必须是唯一的（见第1.1节“对等ID”的定义）；但是，本文件不考虑对等ID的表示。
+--------+ +--------+ +--------+ +---------+ +--------+
| Player | | Peer_1 | | Portal | | Tracker | | Peer_2 |
+--------+ +--------+ +--------+ +---------+ +--------+
| | | | |
(a) |--Page request----------------->| | |
|<--------------Page with links--| | |
|--Select stream (MPD request)-->| | |
|<--------------------OK+MPD(x)--| | |
(b) |--Start/Resume->|--CONNECT(join x)------------>| |
|<-----------OK--|<----------------OK+Peerlist--| |
| | | |
|--Get(chunk)--->|<---------- (Peer protocol) ------------->|
|<--------chunk--|<---------------------------------chunks--|
: : : : :
| |--STAT_REPORT---------------->| |
| |<-------------------------OK--| |
: : : : :
| |--FIND----------------------->| |
| |<----------------OK+Peerlist--| |
: : : : :
|--Get(chunk)--->|<---------- (Peer protocol) ------------->|
|<--------chunk--|<---------------------------------chunks--|
: : : : :
+--------+ +--------+ +--------+ +---------+ +--------+
| Player | | Peer_1 | | Portal | | Tracker | | Peer_2 |
+--------+ +--------+ +--------+ +---------+ +--------+
| | | | |
(a) |--Page request----------------->| | |
|<--------------Page with links--| | |
|--Select stream (MPD request)-->| | |
|<--------------------OK+MPD(x)--| | |
(b) |--Start/Resume->|--CONNECT(join x)------------>| |
|<-----------OK--|<----------------OK+Peerlist--| |
| | | |
|--Get(chunk)--->|<---------- (Peer protocol) ------------->|
|<--------chunk--|<---------------------------------chunks--|
: : : : :
| |--STAT_REPORT---------------->| |
| |<-------------------------OK--| |
: : : : :
| |--FIND----------------------->| |
| |<----------------OK+Peerlist--| |
: : : : :
|--Get(chunk)--->|<---------- (Peer protocol) ------------->|
|<--------chunk--|<---------------------------------chunks--|
: : : : :
Figure 1: A Typical PPSP Session for Streaming Content
图1：流媒体内容的典型PPSP会话
To join an existing P2P streaming service and to participate in content sharing, a peer must first locate a tracker.
要加入现有的P2P流媒体服务并参与内容共享，对等方必须首先找到跟踪器。
As illustrated in Figure 1, a P2P streaming session may be initiated starting at point (a), with the Client Media Player browsing for the desired content in order to request it (to the local Peer_1 in the figure), or resume a previously initiated stream, but starting at point (b). For this example, the Peer_1 is in mode LEECH.
如图1所示，P2P流会话可以从点（a）开始启动，客户端媒体播放器浏览所需内容以请求它（图中的本地对等方_1），或者恢复先前启动的流，但从点（b）开始。对于本例，对等_1处于LEECH模式。
At point (a) in Figure 1, the Client Media Player accesses the portal and selects the content of interest. The portal returns the Media Presentation Description (MPD) file that includes information about the address of one or more trackers (which can be grouped by tiers of priority) that control the swarm x for that media content (e.g., content x).
在图1的（a）点，客户端媒体播放器访问门户并选择感兴趣的内容。门户返回媒体呈现描述（MPD）文件，该文件包括一个或多个跟踪器（可按优先级分层）的地址信息，这些跟踪器控制该媒体内容（例如，内容x）的swarm x。
With the information from the MPD, the Client Media Player is able to trigger the start of the streaming session, requesting to the local Peer_1 the chunks of interest.
利用来自MPD的信息，客户端媒体播放器能够触发流会话的开始，向本地对等方请求感兴趣的块。
The PPSP streaming session is then started (or resumed) at Peer_1 by sending a PPSTP CONNECT message to the tracker in order to join swarm x. The tracker will then return the OK response message containing a peer list, if the CONNECT message is successfully accepted. From that point, every chunk request is addressed by Peer_1 to its neighbors (Peer_2 in Figure 1) using a peer protocol, e.g., [RFC7574], returning the received chunks to the Client Media Player.
然后，通过向跟踪器发送PPSP CONNECT消息以加入swarm x，在对等点_1处启动（或恢复）PPSP流式会话。如果连接消息被成功接受，则跟踪器将返回包含对等列表的OK响应消息。从那时起，每个区块请求由对等方_1使用对等协议（例如，[RFC7574]）向其邻居（图1中的对等方_2）发送，并将接收到的区块返回给客户端媒体播放器。
Once connected, Peer_1 needs to periodically report its status and statistics data to the tracker using a STAT_REPORT message.
一旦连接，Peer_1需要使用STAT_报告消息定期向跟踪器报告其状态和统计数据。
If Peer_1 needs to refresh its neighborhood (for example, due to churn), it will send a PPSTP FIND message (with the desired scope) to the tracker.
如果Peer_1需要刷新其邻居（例如，由于客户流失），它将向跟踪器发送PPSTP FIND消息（具有所需范围）。
Peers that are only SEEDERs (i.e., serving content to other peers), as are the typical cases of service provider P2P edge caches and/or media servers, trigger their P2P streaming sessions for content x, y, z... (Figure 2), not from Media Player signals, but from some "Start" activation signal received from the service provider provisioning mechanism. In this particular case, the peer starts or resumes all its streaming sessions just by sending a PPSTP CONNECT message to the tracker (Figure 2), in order to "join" all the requested swarms.
与服务提供商P2P边缘缓存和/或媒体服务器的典型情况一样，仅作为种子的对等方（即，向其他对等方提供内容），会触发其针对内容x、y、z的P2P流式会话。。。（图2），不是来自媒体播放器信号，而是来自从服务提供商供应机制接收的一些“启动”激活信号。在这种特殊情况下，对等方只需向跟踪器发送PPSTP CONNECT消息（图2）即可启动或恢复其所有流式会话，以便“加入”所有请求的群集。
Periodically, the peer also reports its status and statistics data to the tracker using a PPSTP STAT_REPORT message.
对等方还定期使用PPSTP STAT_报告消息向跟踪器报告其状态和统计数据。
+---------+ +---------+
| SEEDER | | Tracker |
+---------+ +---------+
| |
Start->|--CONNECT (join x,y,z)-------->|
|<--------------------------OK--|
: :
| |
|--STAT_REPORT----------------->|
|<--------------------------Ok--|
: :
| |
|--STAT_REPORT----------------->|
|<--------------------------Ok--|
: :
+---------+ +---------+
| SEEDER | | Tracker |
+---------+ +---------+
| |
Start->|--CONNECT (join x,y,z)-------->|
|<--------------------------OK--|
: :
| |
|--STAT_REPORT----------------->|
|<--------------------------Ok--|
: :
| |
|--STAT_REPORT----------------->|
|<--------------------------Ok--|
: :
Figure 2: A Typical PPSP Session for a Streaming SEEDER
图2：流式播种机的典型PPSP会话
The specification of the mechanisms used by the Client Media Player (or provisioning process) and the peer to signal start/resume of streams, request media chunks, and obtain a peer ID, security certificates, or tokens is not in the scope of this document.
客户机媒体播放器（或供应过程）和点对点信号流启动/恢复、请求媒体块以及获取对等ID、安全证书或令牌所使用的机制的规范不在本文档的范围内。
PPSTP is designed with a layered approach i.e., a PPSTP Request/Response layer, a Message layer, and a Transport layer (see Figure 3).
PPSTP采用分层方法设计，即PPSTP请求/响应层、消息层和传输层（见图3）。
+------------------------+
| Application |
+------------------------+
|(PPSTP) Request/Response|
|------------------------|
| (HTTP) Message |
+------------------------+
| Transport |
+------------------------+
+------------------------+
| Application |
+------------------------+
|(PPSTP) Request/Response|
|------------------------|
| (HTTP) Message |
+------------------------+
| Transport |
+------------------------+
Figure 3: Abstract Layering of PPSTP
图3：PPSTP的抽象分层
The PPSTP Request/Response layer deals with the interactions between tracker and peers using request and response messages.
PPSTP请求/响应层使用请求和响应消息处理跟踪器和对等方之间的交互。
The Message layer deals with the framing format for encoding and transmitting data through the underlying transport protocol, as well as the asynchronous nature of the interactions between tracker and peers.
消息层处理通过底层传输协议编码和传输数据的帧格式，以及跟踪器和对等点之间交互的异步性质。
The Transport layer is responsible for the actual transmission of requests and responses over network transports, including the determination of the connection to use for a request or response message when using TCP or Transport Layer Security (TLS) [RFC5246] over it.
传输层负责通过网络传输的请求和响应的实际传输，包括确定在使用TCP或传输层安全性（TLS）[RFC5246]时用于请求或响应消息的连接。
The messaging model of PPSTP aligns with HTTP, which is currently in version 1.1 [RFC7230], and the semantics of its messages. PPSTP is intended to also support future versions of HTTP.
PPSTP的消息传递模型与HTTP（当前版本为1.1[RFC7230]）及其消息的语义保持一致。PPSTP还打算支持HTTP的未来版本。
PPSTP uses a design like REST (Representational State Transfer) with the goal of leveraging current HTTP implementations and infrastructure, as well as familiarity with existing REST-like
PPSTP使用类似REST（表示性状态传输）的设计，目的是利用当前的HTTP实现和基础设施，并熟悉现有的类似REST的设计
services in popular use. PPSTP messages use the UTF-8 character set [RFC3629] and are either requests from peers to a tracker service or responses from a tracker service to peers. The request and response semantics are carried as entities (header and body) in messages that correspond to either HTTP request methods or HTTP response codes, respectively.
普遍使用的服务。PPSTP消息使用UTF-8字符集[RFC3629]，是对等方对跟踪器服务的请求或跟踪器服务对对等方的响应。请求和响应语义在消息中作为实体（头和体）携带，分别对应于HTTP请求方法或HTTP响应代码。
PPSTP uses the HTTP POST method to send parameters in requests. PPSTP messages use JavaScript Object Notation (JSON) [RFC7159] to encode message bodies.
PPSTP使用HTTP POST方法在请求中发送参数。PPSTP消息使用JavaScript对象表示法（JSON）[RFC7159]对消息体进行编码。
Peers send requests to trackers. Trackers send a single response for each request though both requests and responses can be subject to fragmentation of messages in transport.
对等方向跟踪器发送请求。跟踪器为每个请求发送一个响应，尽管请求和响应在传输过程中可能会受到消息碎片的影响。
The request messages of the base protocol are listed in Table 1:
基本协议的请求消息如表1所示：
+------------------------------+
| PPSTP Request Messages |
+------------------------------+
| CONNECT |
| FIND |
| STAT_REPORT |
+------------------------------+
+------------------------------+
| PPSTP Request Messages |
+------------------------------+
| CONNECT |
| FIND |
| STAT_REPORT |
+------------------------------+
Table 1: Request Messages
表1：请求消息
CONNECT: This request message is used when a peer registers in the tracker to notify it about participation in the named swarm(s). If the peer is already registered in the tracker, this request message simply notifies the tracker about participation in the named swarm(s). The tracker records the peer ID, connect-time (referenced to the absolute time), peer IP addresses (and associated location information), link status, and peer mode for the named swarm(s). The tracker also changes the content availability of the valid named swarm(s), i.e., changes the peer's lists of the corresponding swarm(s) for the requesting peer ID. On receiving a CONNECT message, the tracker first checks the peer mode type (SEEDER/LEECH) for the specified swarm(s) and then decides the next steps (see Section 4.1 for more details).
连接：当对等方在跟踪器中注册以通知其参与指定群时，使用此请求消息。如果对等方已在跟踪器中注册，则此请求消息仅通知跟踪器参与指定群。跟踪器记录命名群的对等ID、连接时间（参考绝对时间）、对等IP地址（和相关位置信息）、链路状态和对等模式。跟踪器还更改有效命名群的内容可用性，即更改请求对等ID对应群的对等列表。收到连接消息后，跟踪器首先检查指定群的对等模式类型（播种器/水蛭），然后决定下一步（详见第4.1节）。
FIND: This request message is used by peers to request a list of peers active in the named swarm from the tracker whenever needed. On receiving a FIND message, the tracker finds the peers listed in the content status of the specified swarm that can satisfy the requesting peer's requirements and returns the list to the
查找：对等方使用此请求消息在需要时从跟踪器请求命名群中活动的对等方列表。在接收到查找消息时，跟踪器将查找指定swarm内容状态中列出的能够满足请求对等方要求的对等方，并将列表返回给
requesting peer. To create the peer list, the tracker may take peer status, capabilities, and peer priority into consideration. Peer priority may be determined by network topology preference, operator policy preference, etc.
请求对等。为了创建对等列表，跟踪器可以考虑对等状态、能力和对等优先级。对等优先级可由网络拓扑偏好、操作员策略偏好等决定。
STAT_REPORT: This request message is used to allow an active peer to send status (and optionally statistic data) to the tracker to signal continuing activity. This request message MUST be sent periodically to the tracker while the peer is active in the system.
STAT_REPORT：此请求消息用于允许活动对等方将状态（以及可选的统计数据）发送到跟踪器，以表示活动仍在继续。当对等方在系统中处于活动状态时，必须定期将此请求消息发送到跟踪器。
The state machine for the tracker is very simple, as shown in Figure 4. Peer ID registrations represent a dynamic piece of state maintained by the network.
跟踪器的状态机非常简单，如图4所示。对等ID注册表示由网络维护的动态状态。
--------------------------------------------
/ \
| +------------+ +=========+ +======+ |
\-| TERMINATED |<---| STARTED |<---| INIT |<-/
+------------+ +=========+ +======+
(Transient) \- (start tracker)
--------------------------------------------
/ \
| +------------+ +=========+ +======+ |
\-| TERMINATED |<---| STARTED |<---| INIT |<-/
+------------+ +=========+ +======+
(Transient) \- (start tracker)
Figure 4: Tracker State Machine
图4：跟踪状态机
When there are no peers connected in the tracker, the state machine is in INIT state.
当跟踪器中没有连接对等点时，状态机处于初始状态。
When the first peer connects to register with its peer ID, the state machine moves from INIT to STARTED. As long as there is at least one active registration of a peer ID, the state machine remains in STARTED state. When the last peer ID is removed, the state machine transitions to TERMINATED. From there, it immediately transitions back to INIT state. Because of this, TERMINATED state is transient.
当第一个对等机连接到使用其对等机ID注册时，状态机从INIT移动到STARTED。只要对等ID至少有一个活动注册，状态机就保持在STARTED状态。删除最后一个对等ID后，状态机将转换为TERMINATED。从那里，它立即转换回INIT状态。因此，终止状态是瞬态的。
Once in STARTED state, each peer is instantiated (per peer ID) in the tracker state machine with a dedicated transaction state machine (Figure 5), which is deleted when the peer ID is removed.
一旦进入STARTED状态，每个对等点都会在tracker状态机中实例化（每个对等点ID），并带有一个专用的事务状态机（图5），当对等点ID被删除时，该事务状态机将被删除。
--------------------------------------------
/ \
| +------------+ +=========+ +======+ |
\-| TERMINATED |<---| STARTED |<---| INIT |<-/
+------------+ +=========+ +======+
(Transient) | (1) \- (start tracker)
V
+-----------+ +-------+ rcv CONNECT
(Transient) | TERMINATE | | START | --------------- (1)
+-----------+ +-------+ strt init timer
rcv FIND (B) ^ |
rcv STAT_REPORT (B) | |
on registration error (B)| v
on action error (A) | +------------+
---------------- +<--| PEER | (Transient)
stop init timer | | REGISTERED |
snd error | +------------+
| |
on timeout (D) | | process swarm actions
---------------- | | --------------------- (2)
stop track timer | | snd OK (PeerList)
clean peer info | / stop init timer
del registration | / strt track timer
| /
| |
| | rcv FIND
STAT_REPORT ERR(C) \ | ---- --------------- (3)
FIND ERR(C) ---- \ | / \ snd OK (PeerList)
CONNECT ERR(C) / \ | | | | rst track timer
rcv CONNECT | (4) | | | | |
----------- | v | v v | rcv STAT_REPORT
snd OK \ +==============+ / --------------- (3)
rst track timer ----| TRACKING |---- snd OK response
snd error (C) +==============+ rst track timer
--------------------------------------------
/ \
| +------------+ +=========+ +======+ |
\-| TERMINATED |<---| STARTED |<---| INIT |<-/
+------------+ +=========+ +======+
(Transient) | (1) \- (start tracker)
V
+-----------+ +-------+ rcv CONNECT
(Transient) | TERMINATE | | START | --------------- (1)
+-----------+ +-------+ strt init timer
rcv FIND (B) ^ |
rcv STAT_REPORT (B) | |
on registration error (B)| v
on action error (A) | +------------+
---------------- +<--| PEER | (Transient)
stop init timer | | REGISTERED |
snd error | +------------+
| |
on timeout (D) | | process swarm actions
---------------- | | --------------------- (2)
stop track timer | | snd OK (PeerList)
clean peer info | / stop init timer
del registration | / strt track timer
| /
| |
| | rcv FIND
STAT_REPORT ERR(C) \ | ---- --------------- (3)
FIND ERR(C) ---- \ | / \ snd OK (PeerList)
CONNECT ERR(C) / \ | | | | rst track timer
rcv CONNECT | (4) | | | | |
----------- | v | v v | rcv STAT_REPORT
snd OK \ +==============+ / --------------- (3)
rst track timer ----| TRACKING |---- snd OK response
snd error (C) +==============+ rst track timer
Figure 5: "Per-Peer-ID" State Machine and Flow Diagram
图5：“每个对等ID”状态机和流程图
Unlike the tracker state machine, which exists even when no peer IDs are registered, the "per-Peer-ID" State Machine is instantiated only when the peer ID starts registration in the tracker and is deleted when the peer ID is de-registered/removed. This allows for an implementation optimization whereby the tracker can destroy the objects associated with the "per-Peer-ID" State Machine once it enters the TERMINATE state (Figure 5).
与跟踪器状态机不同，跟踪器状态机即使在没有注册对等ID时也存在，“每对等ID”状态机仅在对等ID开始在跟踪器中注册时实例化，并在对等ID取消注册/删除时删除。这允许实现优化，跟踪器可以在进入终止状态时销毁与“每个对等ID”状态机关联的对象（图5）。
When a new peer ID is added, the corresponding "per-Peer-ID" State Machine is instantiated, and it moves into the PEER REGISTERED state. Because of that, the START state here is transient.
当添加新的对等ID时，相应的“每个对等ID”状态机被实例化，并进入对等注册状态。因此，这里的启动状态是瞬态的。
When the peer ID is no longer bound to a registration, the "per-Peer-ID" State Machine moves to the TERMINATE state, and the state machine is destroyed.
当对等ID不再绑定到注册时，“每个对等ID”状态机移动到终止状态，并且状态机被销毁。
During the lifetime of streaming activity of a peer, the instantiated "per-Peer-ID" State Machine progresses from one state to another in response to various events. The events that may potentially advance the state include:
在对等方流活动的生命周期内，实例化的“每个对等方ID”状态机响应各种事件从一个状态进展到另一个状态。可能使状态提前的事件包括：
o Reception of CONNECT, FIND, and STAT_REPORT messages
o 接收连接、查找和统计报告消息
o Timeout events
o 超时事件
The state diagram in Figure 5 illustrates state changes, together with the causing events and resulting actions. Specific error conditions are not shown in the state diagram.
图5中的状态图说明了状态更改，以及导致事件和结果操作的原因。状态图中未显示特定的错误条件。
For normal operation, the process consists of the following steps:
对于正常操作，该过程包括以下步骤：
1) When a peer wants to access the system, it needs to register with a tracker by sending a CONNECT message asking for the swarm(s) it wants to join. This request from a new peer ID triggers the instantiation in the tracker of a "per-Peer-ID" State Machine. In the START state of the new "per-Peer-ID" State Machine, the tracker registers the peer ID and associated information (IP addresses), starts the "init timer", and moves to PEER REGISTERED state.
1) 当对等方想要访问系统时，它需要通过发送连接消息向跟踪器注册，请求加入它想要加入的群。来自新对等ID的请求触发“每个对等ID”状态机跟踪程序中的实例化。在新的“每个对等ID”状态机的启动状态下，跟踪器注册对等ID和相关信息（IP地址），启动“初始化计时器”，并移动到对等注册状态。
2) In PEER REGISTERED state, if the peer ID is valid, the tracker either:
2) 在对等注册状态下，如果对等ID有效，则跟踪器：
a) processes the requested action(s) for the valid swarm information contained in the CONNECT requests, and if successful, the tracker stops the "init timer", starts the "track timer", and sends the response to the peer (the response may contain the appropriate list of peers for the joining swarm(s), as detailed in Section 4.1), or
a) 为连接请求中包含的有效群信息处理请求的操作，如果成功，跟踪器停止“初始计时器”，启动“跟踪计时器”，并向对等方发送响应（响应可能包含加入群的对等方的适当列表，如第4.1节所述），或
b) moves the valid FIND request to TRACKING state.
b) 将有效的查找请求移动到跟踪状态。
3) In TRACKING state, STAT_REPORT or FIND messages received from that peer ID will reset the "track timer", and the tracker responds to the requests with the following, respectively:
3) 在跟踪状态下，从该对等ID接收的STAT_REPORT或FIND消息将重置“跟踪计时器”，并且跟踪器分别用以下命令响应请求：
a) a successful condition, or
a) 成功的状态，或
b) a successful condition containing the appropriate list of peers for the named swarm (Section 4.2).
b) 一个成功的条件，包含指定群的适当对等列表（第4.2节）。
4) While in TRACKING state, a CONNECT message received from that peer ID with valid swarm action information (Section 4.1.1) resets the "track timer", and the tracker responds to the request with a successful condition.
4) 在跟踪状态下，从该对等ID接收到的带有有效群集操作信息的CONNECT消息（第4.1.1节）重置“跟踪计时器”，并且跟踪器以成功条件响应请求。
Peers are required not to generate protocol elements that are invalid. However, several situations may lead to abnormal conditions in the interaction with the tracker. These situations may be related to peer malfunction or communication errors. The tracker reacts to these abnormal situations depending on its current state related to a peer ID, as follows:
对等方不需要生成无效的协议元素。然而，有几种情况可能导致与跟踪器的交互出现异常情况。这些情况可能与对等故障或通信错误有关。跟踪器根据其与对等ID相关的当前状态对这些异常情况作出反应，如下所示：
A) In PEER REGISTERED state, when a CONNECT request only contains invalid swarm actions (Section 4.1.1), the tracker responds with a PPSTP error code as specified in Section 4.3, deletes the registration, and transitions to TERMINATE state for that peer ID. The state machine is destroyed.
A） 在对等注册状态下，当连接请求仅包含无效的swarm操作（第4.1.1节）时，跟踪器用第4.3节中规定的PPSTP错误代码响应，删除注册，并转换到该对等ID的终止状态。状态机被销毁。
B) In PEER REGISTERED state, if the peer ID is considered invalid (in the case of a CONNECT request or in the case of FIND or STAT_REPORT requests received from an unregistered peer ID), the tracker responds with either a 06 (Authentication Required) error_code or a 03 (Forbidden Action) error_code as described in Section 4.3 and transitions to TERMINATE state for that peer ID. The state machine is destroyed.
B） 在对等注册状态下，如果对等ID被视为无效（在连接请求或从未注册对等ID接收的查找或统计报告请求的情况下），跟踪器将以06（需要身份验证）错误代码或03（禁止操作）响应错误代码，如第4.3节所述，并转换为该对等ID的终止状态。状态机被销毁。
C) In TRACKING state (while the "track timer" has not expired), receiving a CONNECT message from a peer ID with invalid swarm actions (Section 4.1.1) or receiving a FIND/STAT_REPORT message from a peer ID with an invalid swarm ID is considered an error condition. The tracker responds with the corresponding error code (described in Section 4.3).
C） 在跟踪状态下（当“跟踪计时器”未过期时），从具有无效群集操作的对等ID接收连接消息（第4.1.1节）或从具有无效群集ID的对等ID接收查找/统计报告消息被视为错误情况。跟踪器响应相应的错误代码（如第4.3节所述）。
D) In TRACKING state, without receiving messages from the peer on timeout (the "track timer" has expired), the tracker cleans all the information associated with the peer ID in all swarms it was joined, deletes the registration, and transitions to TERMINATE state for that peer ID. The state machine is destroyed.
D） 在跟踪状态下，在超时时未收到来自对等方的消息（“跟踪计时器”已过期），跟踪器将清除其加入的所有群中与对等方ID相关的所有信息，删除注册，并转换到该对等方ID的终止状态。状态机将被销毁。
NOTE: These situations may correspond to malfunctions at the peer or to malicious conditions. As a preventive measure, the tracker proceeds to TERMINATE state for that peer ID.
注意：这些情况可能对应于对等机的故障或恶意情况。作为预防措施，跟踪器继续进入该对等ID的终止状态。
PPSTP uses a REST-like design, encoding the requests and responses using JSON [RFC7159]. For a generalization of the definition of protocol elements and fields, as well as their types and structures, this document uses a C-style notation, similar to the presentation language used to define TLS [RFC5246].
PPSTP使用类似REST的设计，使用JSON[RFC7159]对请求和响应进行编码。为了概括协议元素和字段的定义，以及它们的类型和结构，本文档使用C风格的表示法，类似于用于定义TLS的表示语言[RFC5246]。
A JSON object consists of name/value pairs with the grammar specified in [RFC7159]. In this document, comments begin with "//", and the "ppsp_tp_string_t" and "ppsp_tp_integer_t" types are used to indicate the JSON string and number, respectively. Optional fields are enclosed in "[ ]" brackets. An array is indicated by two numbers in angle brackets, <min..max>, where "min" indicates the minimal number of values and "max" the maximum. An "*" is used to denote a no upper-bound value for "max".
JSON对象由具有[RFC7159]中指定语法的名称/值对组成。在本文档中，注释以“/”开头，“ppsp_tp_string_t”和“ppsp_tp_integer_t”类型分别用于指示JSON字符串和数字。可选字段用“[]”括号括起。一个数组由尖括号中的两个数字表示，<min..max>，其中“min”表示最小值数，“max”表示最大值。“*”用于表示“max”的无上限值。
This section details the format of PPSTP resource element types.
本节详细介绍PPSTP资源元素类型的格式。
For both requests and responses, the version of PPSTP being used MUST be indicated by the attribute version, defined as follows:
对于请求和响应，所使用的PPSTP版本必须由属性版本表示，定义如下：
ppsp_tp_integer_t ppsp_tp_version_t = 1
ppsp\u tp\u整数\u t ppsp\u tp\u版本\u t=1
The defined value for ppsp_tp_version_t is listed in Table 2.
表2中列出了ppsp_tp_版本的定义值。
+----------------------------------------------------------+
| ppsp_tp_version_t | Description |
+----------------------------------------------------------+
| 0 | Reserved |
| 1 | PPSTP version 1 |
| 2-255 | Unassigned |
+----------------------------------------------------------+
+----------------------------------------------------------+
| ppsp_tp_version_t | Description |
+----------------------------------------------------------+
| 0 | Reserved |
| 1 | PPSTP version 1 |
| 2-255 | Unassigned |
+----------------------------------------------------------+
Table 2: PPSTP Version Numbers
表2:PPSTP版本号
The peer number element is a scope selector optionally present in CONNECT and FIND requests.
peer number元素是一个作用域选择器，可选地出现在CONNECT和FIND请求中。
This element contains the attribute peer_count to indicate the maximum number of peers in the returned peer list. peer_count should be less than 30 in this specification. The other 4 attributes, i.e., ability_nat, concurrent_links, online_time, and upload_bandwidth may also be contained in this element to inform the tracker the status of the peer so that the tracker could return some eligible peers based on the implementing rules set by the service providers:
此元素包含属性peer_count，以指示返回的对等列表中的最大对等数量。本规范中的对等计数应小于30。其他4个属性，即能力、并发链接、在线时间和上传带宽也可以包含在该元素中，以通知跟踪器对等方的状态，以便跟踪器可以根据服务提供商设置的实施规则返回一些合格的对等方：
o ability_nat is used to indicate the preferred NAT traversal situation of the requesting peer.
o 能力_nat用于指示请求对等方的首选nat遍历情况。
o concurrent_links means the number of P2P links the peer currently has.
o concurrent_links表示对等方当前拥有的P2P链接数。
o online_time represents online duration time of the peer. The unit is second.
o online_time表示对等方的联机持续时间。这个单位是第二。
o upload_bandwidth is the maximum upload bandwidth capability of the peer. The unit is Kbps.
o upload_带宽是对等方的最大上载带宽能力。单位为Kbps。
The scope selector element and its attributes are defined as follows:
范围选择器元素及其属性定义如下：
Object {
ppsp_tp_integer_t peer_count;
[ppsp_tp_string_t ability_nat = "NO_NAT"
| "STUN"
| "TURN";]
[ppsp_tp_integer_t concurrent_links;]
[ppsp_tp_integer_t online_time;]
[ppsp_tp_integer_t upload_bandwidth;]
} ppsp_tp_peer_num_t;
Object {
ppsp_tp_integer_t peer_count;
[ppsp_tp_string_t ability_nat = "NO_NAT"
| "STUN"
| "TURN";]
[ppsp_tp_integer_t concurrent_links;]
[ppsp_tp_integer_t online_time;]
[ppsp_tp_integer_t upload_bandwidth;]
} ppsp_tp_peer_num_t;
The swarm action element identifies the action(s) to be taken in the named swarm(s) as well as the corresponding peer mode (if the peer is LEECH or SEEDER in that swarm).
swarm action元素确定在指定群中要采取的行动以及相应的对等模式（如果对等方是该群中的水蛭或播种机）。
Object {
ppsp_tp_string_t swarm_id; //swarm ID
ppsp_tp_string_t action = "JOIN"
|"LEAVE"; // Action type of
// the CONNECT
// message
Object {
ppsp_tp_string_t swarm_id; //swarm ID
ppsp_tp_string_t action = "JOIN"
|"LEAVE"; // Action type of
// the CONNECT
// message
ppsp_tp_string_t peer_mode = "SEEDER"
| "LEECH"; // Mode of the peer
// participating
// in this swarm
} ppsp_tp_swarm_action_t;
ppsp_tp_string_t peer_mode = "SEEDER"
| "LEECH"; // Mode of the peer
// participating
// in this swarm
} ppsp_tp_swarm_action_t;
The peer information elements provide network identification information of peers. A peer information element consists of a peer identifier and the IP-related addressing information.
对等信息元素提供对等的网络标识信息。对等信息元素由对等标识符和与IP相关的寻址信息组成。
Object {
ppsp_tp_string_t peer_id;
ppsp_tp_peer_addr_t peer_addr;
} ppsp_tp_peer_info_t;
Object {
ppsp_tp_string_t peer_id;
ppsp_tp_peer_addr_t peer_addr;
} ppsp_tp_peer_info_t;
The ppsp_tp_peer_addr_t element includes the IP address and port, with a few optional attributes related to connection type and network location (in terms of ASN) as well as, optionally, the identifier of the peer protocol being used.
ppsp_tp_peer_addr_t元素包括IP地址和端口，以及一些与连接类型和网络位置（根据ASN）相关的可选属性，还可以选择使用对等协议的标识符。
Object {
ppsp_tp_ip_address ip_address;
ppsp_tp_integer_t port;
ppsp_tp_integer_t priority;
ppsp_tp_string_t type = "HOST"
| "REFLEXIVE"
| "PROXY";
[ppsp_tp_string_t connection = "wireless"
| "wired";]
[ppsp_tp_string_t asn;]
[ppsp_tp_string_t peer_protocol;]
} ppsp_tp_peer_addr_t;
Object {
ppsp_tp_ip_address ip_address;
ppsp_tp_integer_t port;
ppsp_tp_integer_t priority;
ppsp_tp_string_t type = "HOST"
| "REFLEXIVE"
| "PROXY";
[ppsp_tp_string_t connection = "wireless"
| "wired";]
[ppsp_tp_string_t asn;]
[ppsp_tp_string_t peer_protocol;]
} ppsp_tp_peer_addr_t;
The semantics of ppsp_tp_peer_addr_t attributes are listed in Table 3:
ppsp_tp_peer_addr_t属性的语义如表3所示：
+----------------------+----------------------------------+
| Element or Attribute | Description |
+----------------------+----------------------------------+
| ip_address | IP address information |
| port | IP service port value |
| priority | The priority of this interface. |
| | It may be determined by network |
| | topology preference, operator |
| | policy preference, etc. How to |
| | create a priority is outside of |
| | the scope. The larger the value,|
| | the higher the priority. |
| type | Describes the address for NAT |
| | traversal, which can be HOST |
| | REFLEXIVE or PROXY |
| connection | Access type (wireless or wired) |
| asn | Autonomous System Number |
| peer_protocol | Peer-to-Peer Streaming Peer |
| | Protocol (PPSPP) supported |
+----------------------+----------------------------------+
+----------------------+----------------------------------+
| Element or Attribute | Description |
+----------------------+----------------------------------+
| ip_address | IP address information |
| port | IP service port value |
| priority | The priority of this interface. |
| | It may be determined by network |
| | topology preference, operator |
| | policy preference, etc. How to |
| | create a priority is outside of |
| | the scope. The larger the value,|
| | the higher the priority. |
| type | Describes the address for NAT |
| | traversal, which can be HOST |
| | REFLEXIVE or PROXY |
| connection | Access type (wireless or wired) |
| asn | Autonomous System Number |
| peer_protocol | Peer-to-Peer Streaming Peer |
| | Protocol (PPSPP) supported |
+----------------------+----------------------------------+
Table 3: Semantics of ppsp_tp_peer_addr_t
表3:ppsp\u tp\u peer\u addr\t的语义
In this document, IP address is specified as ppsp_tp_addr_value. The exact characters and format depend on address_type:
在本文档中，IP地址指定为ppsp_tp_addr_值。确切的字符和格式取决于地址类型：
o The IPv4 address is encoded as specified by the "IPv4address" rule in Section 3.2.2 of [RFC3986].
o IPv4地址按照[RFC3986]第3.2.2节中的“IPv4address”规则进行编码。
o The IPv6 address is encoded as specified in Section 4 of [RFC5952].
o IPv6地址按照[RFC5952]第4节的规定进行编码。
Object {
ppsp_tp_string_t address_type;
ppsp_tp_addr_value address;
} ppsp_tp_ip_address;
Object {
ppsp_tp_string_t address_type;
ppsp_tp_addr_value address;
} ppsp_tp_ip_address;
The peer information in responses is grouped in a ppsp_tp_peer_group_t element:
响应中的对等信息分组在ppsp_tp_peer_group_t元素中：
Object {
ppsp_tp_peer_info_t peer_info<1..*>;
} ppsp_tp_peer_group_t;
Object {
ppsp_tp_peer_info_t peer_info<1..*>;
} ppsp_tp_peer_group_t;
The statistics element (stat) is used to describe several properties relevant to the P2P network. These properties can be related to stream statistics and peer status information. Each stat element will correspond to a property type, and several stat blocks can be reported in a single STAT_REPORT message, corresponding to some or all the swarms the peer is actively involved. This specification only defines the property type "STREAM_STATS".
统计元素（stat）用于描述与P2P网络相关的几个属性。这些属性可以与流统计信息和对等状态信息相关。每个stat元素将对应一个属性类型，并且可以在单个stat_报告消息中报告多个stat块，对应于对等方积极参与的部分或所有群集。本规范仅定义属性类型“STREAM_STATS”。
The definition of the statistic element and attributes is as follows:
统计元素和属性的定义如下：
Object {
ppsp_tp_string_t swarm_id;
ppsp_tp_integer_t uploaded_bytes;
ppsp_tp_integer_t downloaded_bytes;
ppsp_tp_integer_t available_bandwidth;
ppsp_tp_integer_t concurrent_links;
} stream_stats;
Object {
ppsp_tp_string_t swarm_id;
ppsp_tp_integer_t uploaded_bytes;
ppsp_tp_integer_t downloaded_bytes;
ppsp_tp_integer_t available_bandwidth;
ppsp_tp_integer_t concurrent_links;
} stream_stats;
The semantics of stream_stats attributes are listed in Table 4:
表4列出了stream_stats属性的语义：
+----------------------+----------------------------------+
| Element or Attribute | Description |
+----------------------+----------------------------------+
| swarm_id | Swarm ID |
| uploaded_bytes | Bytes sent to swarm |
| downloaded_bytes | Bytes received from swarm |
| available_bandwidth | Available instantaneous upload |
| | bandwidth |
| concurrent_links | Number of concurrent links |
+----------------------+----------------------------------+
+----------------------+----------------------------------+
| Element or Attribute | Description |
+----------------------+----------------------------------+
| swarm_id | Swarm ID |
| uploaded_bytes | Bytes sent to swarm |
| downloaded_bytes | Bytes received from swarm |
| available_bandwidth | Available instantaneous upload |
| | bandwidth |
| concurrent_links | Number of concurrent links |
+----------------------+----------------------------------+
Table 4: Semantics of stream_stats
表4:stream_stats的语义
The stat information is grouped in the ppsp_tp_stat_group_t element:
统计信息分组在ppsp_tp_统计组元素中：
Object {
ppsp_tp_string_t type = "STREAM_STATS"; // property type
stream_stats stat<1..*>;
} ppsp_tp_stat_group_t
Object {
ppsp_tp_string_t type = "STREAM_STATS"; // property type
stream_stats stat<1..*>;
} ppsp_tp_stat_group_t
Other properties may be defined, related, for example, to incentives and reputation mechanisms like "peer online time" or connectivity conditions like physical "link status", etc.
可以定义其他属性，例如，与激励和声誉机制（如“对等在线时间”）或连接条件（如物理“链接状态”）相关。
For that purpose, the stat element may be extended to provide additional specific information for new properties, elements, or attributes (see the guidelines in Section 7).
为此，可以扩展stat元素，为新属性、元素或属性提供额外的特定信息（参见第7节中的指南）。
This section defines the structure of PPSTP requests and responses.
本节定义了PPSTP请求和响应的结构。
The request type includes CONNECT, FIND, and STAT_REPORT, defined as follows:
请求类型包括CONNECT、FIND和STAT_REPORT，定义如下：
ppsp_tp_string_t ppsp_tp_request_type_t = "CONNECT" | "FIND" | "STAT_REPORT";
ppsp_tp_字符串_t ppsp_tp_请求_type_t=“CONNECT”|“FIND”|“STAT_REPORT”；
Response type corresponds to the response method type of the message, defined as follows:
响应类型对应于消息的响应方法类型，定义如下：
JSONValue ppsp_tp_response_type_t = 0x00 // SUCCESSFUL
| 0x01; // FAILED
JSONValue ppsp_tp_response_type_t = 0x00 // SUCCESSFUL
| 0x01; // FAILED
The request element MUST be present in requests and corresponds to the request method type for the message.
请求元素必须存在于请求中，并与消息的请求方法类型相对应。
The generic definition of a request element is as follows:
请求元素的一般定义如下：
Object {
[ppsp_tp_peer_num_t peer_num;]
[ppsp_tp_peer_addr_t peer_addr<1..*>;]
ppsp_tp_swarm_action_t swarm_action<1..*>;
} ppsp_tp_request_connect;
Object {
[ppsp_tp_peer_num_t peer_num;]
[ppsp_tp_peer_addr_t peer_addr<1..*>;]
ppsp_tp_swarm_action_t swarm_action<1..*>;
} ppsp_tp_request_connect;
Object {
ppsp_tp_string_t swarm_id;
[ppsp_tp_peer_num_t peer_num;]
} ppsp_tp_request_find;
Object {
ppsp_tp_string_t swarm_id;
[ppsp_tp_peer_num_t peer_num;]
} ppsp_tp_request_find;
Object {
ppsp_tp_version_t version;
ppsp_tp_request_type_t request_type;
ppsp_tp_string_t transaction_id;
ppsp_tp_string_t peer_id;
JSONValue request_data = ppsp_tp_req_connect connect
| ppsp_tp_req_find find
| ppsp_tp_stat_group_t stat_report;
} ppsp_tp_request;
Object {
ppsp_tp_version_t version;
ppsp_tp_request_type_t request_type;
ppsp_tp_string_t transaction_id;
ppsp_tp_string_t peer_id;
JSONValue request_data = ppsp_tp_req_connect connect
| ppsp_tp_req_find find
| ppsp_tp_stat_group_t stat_report;
} ppsp_tp_request;
A request element consists of the version of PPSTP, the request type, a transaction ID, the requesting peer ID, and requesting body (i.e., request_data). The request_data MUST be correctly set to the corresponding element based on the request type (see Table 5).
请求元素由PPSTP版本、请求类型、事务ID、请求对等ID和请求主体（即请求数据）组成。必须根据请求类型将请求_数据正确设置为相应的元素（参见表5）。
+----------------------+----------------------+
| request_type | request_data |
+----------------------+----------------------+
| "CONNECT" | "connect" |
| "FIND" | "find" |
| "STAT_REPORT" | "stat_report" |
+----------------------+----------------------+
+----------------------+----------------------+
| request_type | request_data |
+----------------------+----------------------+
| "CONNECT" | "connect" |
| "FIND" | "find" |
| "STAT_REPORT" | "stat_report" |
+----------------------+----------------------+
Table 5: The Relationship between request_type and request_data
表5：请求类型和请求数据之间的关系
The generic definition of a response element is as follows:
响应元素的一般定义如下：
Object {
ppsp_tp_version_t version;
ppsp_tp_response_type_t response_type;
ppsp_tp_integer_t error_code;
ppsp_tp_string_t transaction_id;
[ppsp_tp_peer_addr_t peer_addr;]
[ppsp_tp_swarm_action_result_t swarm_result<1..*>;]
} ppsp_tp_response;
Object {
ppsp_tp_version_t version;
ppsp_tp_response_type_t response_type;
ppsp_tp_integer_t error_code;
ppsp_tp_string_t transaction_id;
[ppsp_tp_peer_addr_t peer_addr;]
[ppsp_tp_swarm_action_result_t swarm_result<1..*>;]
} ppsp_tp_response;
A response element consists of the version of PPSTP, the response type, the error code, a transaction ID, and optionally the public address of the requesting peer and one or multiple swarm action result elements. Normally, swarm action result elements SHOULD be present and error_code MUST be set to 00 (No Error) when response_type is 0x00. Swarm action result elements SHOULD NOT be set when error_code is 01 (Bad Request). Detailed selection of error_code is introduced in Section 4.3.
响应元素由PPSTP的版本、响应类型、错误代码、事务ID、请求对等方的公共地址（可选）和一个或多个swarm action result元素组成。通常情况下，当响应类型为0x00时，应存在群集动作结果元素，且错误代码必须设置为00（无错误）。错误代码为01（错误请求）时，不应设置群集操作结果元素。第4.3节介绍了错误代码的详细选择。
Object {
ppsp_tp_string_t swarm_id;
ppsp_tp_response_type_t result;
[ppsp_tp_peer_group_t peer_group;]
} ppsp_tp_swarm_action_result_t;
Object {
ppsp_tp_string_t swarm_id;
ppsp_tp_response_type_t result;
[ppsp_tp_peer_group_t peer_group;]
} ppsp_tp_swarm_action_result_t;
A swarm action result element represents the result of an action requested by the peer. It contains a swarm identifier that globally indicates the swarm, the result for the peer of this action (which could be CONNECT ("JOIN" or "LEAVE"), FIND, or STAT_REPORT), and optionally one peer group element. The attribute result indicates the operation result of the corresponding request. When the response element corresponds to the STAT_REPORT request or the result attribute is set to 0x01, the peer group element SHOULD NOT be set.
swarm action result元素表示对等方请求的操作的结果。它包含一个swarm标识符，全局指示swarm、该操作的对等方的结果（可以是连接（“加入”或“离开”）、查找或统计报告），以及可选的一个对等组元素。属性result表示对应请求的操作结果。当response元素对应于STAT_REPORT请求或result属性设置为0x01时，不应设置对等组元素。
PPSTP messages (requests or responses) are designed to have a similar structure with a root field named "PPSPTrackerProtocol" containing meta information and data pertaining to a request or a response.
PPSTP消息（请求或响应）的结构与名为“PPSPTrackerProtocol”的根字段类似，其中包含与请求或响应相关的元信息和数据。
The base type of a PPSTP message is defined as follows:
PPSTP消息的基本类型定义如下：
Object {
JSONValue PPSPTrackerProtocol = ppsp_tp_request Request
| ppsp_tp_response Response;
} ppsp_tp_message_root;
Object {
JSONValue PPSPTrackerProtocol = ppsp_tp_request Request
| ppsp_tp_response Response;
} ppsp_tp_message_root;
PPSTP is a message-oriented request/response protocol. PPSTP messages use a text type encoding in JSON [RFC7159], which MUST be indicated in the Content-Type field in HTTP/1.1 [RFC7231], specifying the "application/ppsp-tracker+json" media type for all PPSTP request parameters and responses.
PPSTP是一种面向消息的请求/响应协议。PPSTP消息使用JSON[RFC7159]中的文本类型编码，必须在HTTP/1.1[RFC7231]中的内容类型字段中指明，并为所有PPSTP请求参数和响应指定“应用程序/ppsp跟踪器+JSON”媒体类型。
Implementations MUST support the "https" URI scheme [RFC2818] and Transport Layer Security (TLS) [RFC5246].
实现必须支持“https”URI方案[RFC2818]和传输层安全性（TLS）[RFC5246]。
For deployment scenarios where peer (client) authentication is desired at the tracker, HTTP Digest Access Authentication [RFC7616] MUST be supported, with TLS Client Authentication as the preferred mechanism, if available.
对于需要在跟踪器上进行对等（客户端）身份验证的部署场景，必须支持HTTP摘要访问身份验证[RFC7616]，TLS客户端身份验证是首选机制（如果可用）。
PPSTP uses the HTTP POST method to send parameters in requests to provide information resources that are the function of one or more of those input parameters. Input parameters are encoded in JSON in the HTTP entity body of the request.
PPSTP使用HTTP POST方法在请求中发送参数，以提供信息资源，这些信息资源是一个或多个输入参数的函数。输入参数在请求的HTTP实体体中用JSON编码。
The section describes the operation of the three types of requests of PPSTP and provides some examples of usage.
本节描述了PPSTP三种类型请求的操作，并提供了一些使用示例。
This method is used when a peer registers to the system and/or requests some swarm actions (join/leave). The peer MUST properly set the request type to CONNECT, generate and set the transaction_ids, set the peer_id, and include swarms the peer is interested in, followed by the corresponding action type and peer mode.
当对等方向系统注册和/或请求一些群集操作（加入/离开）时，使用此方法。对等方必须正确设置请求类型以连接、生成和设置事务id，设置对等方id，并包括对等方感兴趣的群集，然后是相应的操作类型和对等方模式。
o When a peer already possesses content and agrees to share it with others, it should set the action type to the value JOIN, as well as set the peer mode to SEEDER during its start (or re-start) period.
o 当对等方已经拥有内容并同意与其他方共享时，它应该将动作类型设置为值联接，并在其启动（或重新启动）期间将对等方模式设置为种子机。
o When a peer makes a request to join a swarm to consume content, it should set the action type to the value JOIN, as well as set the peer mode to LEECH during its start (or re-start) period.
o 当对等方请求加入swarm以消费内容时，应将动作类型设置为值join，并在其启动（或重新启动）期间将对等方模式设置为LEECH。
In the above cases, the peer can provide optional information on the addresses of its network interface(s), for example, the priority, type, connection, and ASN.
在上述情况下，对等方可以提供关于其网络接口地址的可选信息，例如优先级、类型、连接和ASN。
When a peer plans to leave a previously joined swarm, it should set action type to LEAVE, regardless of the peer mode.
当一个对等方计划离开以前加入的swarm时，它应该将动作类型设置为离开，而不考虑对等方模式。
When receiving a well-formed CONNECT request message, the tracker starts by pre-processing the peer authentication information (provided as authorization scheme and token in the HTTP message) to check whether it is valid and that it can connect to the service, then proceed to register the peer in the service and perform the swarm actions requested. If successful, a response message with a corresponding response value of SUCCESSFUL will be generated.
当接收到格式良好的连接请求消息时，跟踪器首先预处理对等身份验证信息（作为HTTP消息中的授权方案和令牌提供），以检查其是否有效以及是否可以连接到服务，然后继续在服务中注册对等方并执行请求的swarm操作。如果成功，将生成相应响应值为successful的响应消息。
The valid sets of the number of swarms whose action type is combined with peer mode for the CONNECT request logic are enumerated in Table 6 (referring to the "per-Peer-ID" State Machine in Section 2.3).
表6列出了其操作类型与连接请求逻辑的对等模式相结合的群集数量的有效集合（参考第2.3节中的“每个对等ID”状态机）。
+-----------+-----------+---------+----------+-----------+----------+
| Swarm | peer_mode | action | Initial | Final | Request |
| Number | Value | Value | State | State | Validity |
+-----------+-----------+---------+----------+-----------+----------|
| 1 | LEECH | JOIN | START | TRACKING | Valid |
+-----------+-----------+---------+----------+-----------+----------+
| 1 | LEECH | LEAVE | START | TERMINATE | Invalid |
+-----------+-----------+---------+----------+-----------+----------+
| 1 | LEECH | LEAVE | TRACKING | TERMINATE | Valid |
+-----------+-----------+---------+----------+-----------+----------+
| 1 | LEECH | JOIN | START | TERMINATE | Invalid |
| 1 | LEECH | LEAVE | | | |
+-----------+-----------+---------+----------+-----------+----------+
| 1 | LEECH | JOIN | TRACKING | TRACKING | Valid |
| 1 | LEECH | LEAVE | | | |
+-----------+-----------+---------+----------+-----------+----------+
| N | SEEDER | JOIN | START | TRACKING | Valid |
+-----------+-----------+---------+----------+-----------+----------+
| N | SEEDER | JOIN | TRACKING | TERMINATE | Invalid |
+-----------+-----------+---------+----------+-----------+----------+
| N | SEEDER | LEAVE | TRACKING | TERMINATE | Valid |
+-----------+-----------+---------+----------+-----------+----------+
+-----------+-----------+---------+----------+-----------+----------+
| Swarm | peer_mode | action | Initial | Final | Request |
| Number | Value | Value | State | State | Validity |
+-----------+-----------+---------+----------+-----------+----------|
| 1 | LEECH | JOIN | START | TRACKING | Valid |
+-----------+-----------+---------+----------+-----------+----------+
| 1 | LEECH | LEAVE | START | TERMINATE | Invalid |
+-----------+-----------+---------+----------+-----------+----------+
| 1 | LEECH | LEAVE | TRACKING | TERMINATE | Valid |
+-----------+-----------+---------+----------+-----------+----------+
| 1 | LEECH | JOIN | START | TERMINATE | Invalid |
| 1 | LEECH | LEAVE | | | |
+-----------+-----------+---------+----------+-----------+----------+
| 1 | LEECH | JOIN | TRACKING | TRACKING | Valid |
| 1 | LEECH | LEAVE | | | |
+-----------+-----------+---------+----------+-----------+----------+
| N | SEEDER | JOIN | START | TRACKING | Valid |
+-----------+-----------+---------+----------+-----------+----------+
| N | SEEDER | JOIN | TRACKING | TERMINATE | Invalid |
+-----------+-----------+---------+----------+-----------+----------+
| N | SEEDER | LEAVE | TRACKING | TERMINATE | Valid |
+-----------+-----------+---------+----------+-----------+----------+
Table 6: Validity of Action Combinations in CONNECT Requests
表6:CONNECT请求中操作组合的有效性
In the CONNECT request message, multiple swarm action elements ppsp_tp_swarm_action_t could be contained. Each of them contains the request action and the peer_mode of the peer. The peer_mode attribute MUST be set to the type of participation of the peer in the swarm (SEEDER or LEECH).
在连接请求消息中，可以包含多个swarm action元素ppsp\u tp\u swarm\u action\t。它们中的每一个都包含请求操作和对等方的对等方模式。peer_mode属性必须设置为群中对等方的参与类型（播种机或水蛭）。
The CONNECT message may contain multiple peer_addr elements with attributes ip_address, port, priority, and type (if Interactive Connectivity Establishment (ICE) [RFC5245] NAT traversal techniques are used), and optionally connection, asn, and peer_protocol corresponding to each of the network interfaces the peer wants to advertise.
连接消息可以包含多个对等地址元素，这些元素具有属性ip地址、端口、优先级和类型（如果使用交互式连接建立（ICE）[RFC5245]NAT遍历技术），并且可选地包含对应于对等方想要通告的每个网络接口的连接、asn和对等协议。
The element peer_num indicates the maximum number of peers to be returned in a list from the tracker. The returned peer list can be optionally filtered by some indicated properties, such as ability_nat for NAT traversal, and concurrent_links, online_time and upload_bandwidth for the preferred capabilities.
元素peer_num表示从跟踪器返回的列表中的最大对等数。返回的对等列表可以选择性地通过一些指定的属性进行过滤，例如nat遍历的能力、首选能力的并发链接、在线时间和上传带宽。
The element transaction_id MUST be present in requests to uniquely identify the transaction. Responses to completed transactions use the same transaction_id as the request they correspond to.
元素事务id必须存在于请求中，以唯一标识该事务。对已完成事务的响应使用与其对应的请求相同的事务id。
The response may include peer_addr data of the requesting peer public IP address. Peers can use Session Traversal Utilities for NAT (STUN) [RFC5389] and Traversal Using Relays around NAT (TURN) [RFC5766] to gather their candidates, in which case peer_addr SHOULD NOT present in the response. If no STUN is used and the tracker is able to work as a "STUN-like" server that can inspect the public address of a peer, the tracker can return the address back with a "REFLEXIVE" attribute type. The swarm_result may also include peer_addr data corresponding to the peer IDs and public IP addresses of the selected active peers in the requested swarm. The tracker may also include the attribute asn with network location information of the transport address, corresponding to the Autonomous System Number of the access network provider of the referenced peer.
响应可以包括请求对等公共IP地址的对等地址数据。对等方可以使用NAT（STUN）[RFC5389]的会话遍历实用程序，并使用NAT（TURN）[RFC5766]周围的中继进行遍历，以收集其候选对象，在这种情况下，对等方地址不应出现在响应中。如果没有使用眩晕，并且跟踪器能够作为“类似眩晕”的服务器工作，可以检查对等方的公共地址，跟踪器可以使用“反射”属性类型返回地址。swarm_结果还可以包括与所请求swarm中的所选活动对等方的对等id和公共IP地址相对应的对等方addr数据。跟踪器还可以包括具有传输地址的网络位置信息的属性asn，该传输地址对应于所引用对等方的接入网络提供商的自治系统号。
If the peer_mode is SEEDER, the tracker responds with a SUCCESSFUL response and enters the peer information into the corresponding swarm activity. If the peer_mode is LEECH (or if a SEEDER includes a peer_num element in the request), the tracker will search and select an appropriate list of peers satisfying the conditions set by the requesting peer. The peer list returned MUST contain the peer IDs and the corresponding IP addresses. To create the peer list, the tracker may take peer status and network location information into consideration to express network topology preferences or operators' policy preferences with regard to the possibility of connecting with other IETF efforts such as Application-Layer Traffic Optimization (ALTO) [RFC7285].
如果peer_模式为SEEDER，则跟踪器将以成功响应进行响应，并将对等信息输入到相应的swarm活动中。如果peer_模式为LEECH（或者如果播种机在请求中包含peer_num元素），则跟踪器将搜索并选择满足请求peer设置的条件的适当的peer列表。返回的对等列表必须包含对等ID和相应的IP地址。为了创建对等列表，跟踪器可以考虑对等状态和网络位置信息，以表达网络拓扑偏好或运营商关于与其他IETF工作（例如应用层流量优化（ALTO））连接的可能性的策略偏好[RFC7285]。
IMPLEMENTATION NOTE: If no peer_num attributes are present in the request, the tracker may return a random sample from the peer population.
实现注意：如果请求中不存在peer_num属性，那么跟踪器可能会从对等群体中返回一个随机样本。
The following example of a CONNECT request corresponds to a peer that wants to start (or re-start) sharing its previously streamed content (peer_mode is SEEDER).
下面的连接请求示例对应于希望开始（或重新开始）共享其先前流式内容的对等方（对等方模式为SEEDER）。
POST https://tracker.example.com/video_1 HTTP/1.1
Host: tracker.example.com
Content-Length: 494
Content-Type: application/ppsp-tracker+json
Accept: application/ppsp-tracker+json
POST https://tracker.example.com/video_1 HTTP/1.1
Host: tracker.example.com
Content-Length: 494
Content-Type: application/ppsp-tracker+json
Accept: application/ppsp-tracker+json
{
"PPSPTrackerProtocol": {
"version": 1,
"request_type": "CONNECT",
"transaction_id": "12345",
"peer_id": "656164657220",
"connect":{
"peer_addr": {
"ip_address": {
"address_type": "ipv4",
"address": "192.0.2.2"
},
"port": 80,
"priority": 1,
"type": "HOST",
"connection": "wired",
"asn": "45645"
},
"swarm_action": [{
"swarm_id": "1111",
"action": "JOIN",
"peer_mode": "SEEDER"
},
{
"swarm_id": "2222",
"action": "JOIN",
"peer_mode": "SEEDER"
}]
}
}
}
{
"PPSPTrackerProtocol": {
"version": 1,
"request_type": "CONNECT",
"transaction_id": "12345",
"peer_id": "656164657220",
"connect":{
"peer_addr": {
"ip_address": {
"address_type": "ipv4",
"address": "192.0.2.2"
},
"port": 80,
"priority": 1,
"type": "HOST",
"connection": "wired",
"asn": "45645"
},
"swarm_action": [{
"swarm_id": "1111",
"action": "JOIN",
"peer_mode": "SEEDER"
},
{
"swarm_id": "2222",
"action": "JOIN",
"peer_mode": "SEEDER"
}]
}
}
}
Another example of the message-body of a CONNECT request corresponds to a peer (peer_mode is LEECH, meaning that the peer is not in possession of the content) requesting join to a swarm, in order to
连接请求的消息体的另一个示例对应于请求加入swarm的对等方（peer_模式为LEECH，意味着该对等方不拥有该内容），以便
start receiving the stream and providing optional information on the addresses of its network interface(s):
开始接收流并提供有关其网络接口地址的可选信息：
{
"PPSPTrackerProtocol": {
"version": 1,
"request_type": "CONNECT",
"transaction_id": "12345.0",
"peer_id": "656164657221",
"connect":{
"peer_num": {
"peer_count": 5,
"ability_nat": "STUN",
"concurrent_links": "5",
"online_time": "200",
"upload_bandwidth": "600"
},
"peer_addr": [{
"ip_address": {
"address_type": "ipv4",
"address": "192.0.2.2"
},
"port": 80,
"priority": 1,
"type": "HOST",
"connection": "wired",
"asn": "3256546"
},
{
"ip_address":{
"address_type": "ipv6",
"address": "2001:db8::2"
},
"port": 80,
"priority": 2,
"type": "HOST",
"connection": "wireless",
"asn": "34563456",
"peer_protocol": "PPSP-PP"
}],
"swarm_action": {
"swarm_id": "1111",
"action": "JOIN",
"peer_mode": "LEECH"
}
}
}
}
{
"PPSPTrackerProtocol": {
"version": 1,
"request_type": "CONNECT",
"transaction_id": "12345.0",
"peer_id": "656164657221",
"connect":{
"peer_num": {
"peer_count": 5,
"ability_nat": "STUN",
"concurrent_links": "5",
"online_time": "200",
"upload_bandwidth": "600"
},
"peer_addr": [{
"ip_address": {
"address_type": "ipv4",
"address": "192.0.2.2"
},
"port": 80,
"priority": 1,
"type": "HOST",
"connection": "wired",
"asn": "3256546"
},
{
"ip_address":{
"address_type": "ipv6",
"address": "2001:db8::2"
},
"port": 80,
"priority": 2,
"type": "HOST",
"connection": "wireless",
"asn": "34563456",
"peer_protocol": "PPSP-PP"
}],
"swarm_action": {
"swarm_id": "1111",
"action": "JOIN",
"peer_mode": "LEECH"
}
}
}
}
The next example of a CONNECT request corresponds to a peer leaving a previously joined swarm and requesting to join a new swarm. This is the typical example of a user watching a live channel but then deciding to switch to a different one:
连接请求的下一个示例对应于离开先前加入的群并请求加入新群的对等方。这是一个典型的例子，用户在观看直播频道后决定切换到另一个频道：
{
"PPSPTrackerProtocol": {
"version": 1,
"request_type": "CONNECT",
"transaction_id": "12345",
"peer_id": "656164657221",
"connect":{
"peer_num": {
"peer_count": 5,
"ability_nat": "STUN",
"concurrent_links": "5",
"online_time": "200",
"upload_bandwidth": "600"
},
"swarm_action": [{
"swarm_id": "1111",
"action": "LEAVE",
"peer_mode": "LEECH"
},
{
"swarm_id": "2222",
"action": "JOIN",
"peer_mode": "LEECH"
}]
}
}
}
{
"PPSPTrackerProtocol": {
"version": 1,
"request_type": "CONNECT",
"transaction_id": "12345",
"peer_id": "656164657221",
"connect":{
"peer_num": {
"peer_count": 5,
"ability_nat": "STUN",
"concurrent_links": "5",
"online_time": "200",
"upload_bandwidth": "600"
},
"swarm_action": [{
"swarm_id": "1111",
"action": "LEAVE",
"peer_mode": "LEECH"
},
{
"swarm_id": "2222",
"action": "JOIN",
"peer_mode": "LEECH"
}]
}
}
}
The next example illustrates the response for the previous example of a CONNECT request where the peer requested two swarm actions and not more than 5 other peers, receiving from the tracker a peer list with only two other peers in the swarm "2222":
下一个示例说明了前一个连接请求示例的响应，其中对等方请求了两个群集操作，但不超过5个其他对等方，从跟踪器接收到一个对等方列表，其中群集“2222”中只有两个其他对等方：
HTTP/1.1 200 OK
Content-Length: 1342
Content-Type: application/ppsp-tracker+json
HTTP/1.1 200 OK
Content-Length: 1342
Content-Type: application/ppsp-tracker+json
{
"PPSPTrackerProtocol": {
"version": 1,
"response_type": 0,
"error_code": 0,
"transaction_id": "12345",
{
"PPSPTrackerProtocol": {
"version": 1,
"response_type": 0,
"error_code": 0,
"transaction_id": "12345",
"peer_addr": {
"ip_address": {
"address_type": "ipv4",
"address": "198.51.100.1"
},
"port": 80,
"priority": 1,
"asn": "64496"
},
"swarm_result": {
"swarm_id": "2222",
"result": 0,
"peer_group": {
"peer_info": [{
"peer_id": "956264622298",
"peer_addr": {
"ip_address": {
"address_type": "ipv4",
"address": "198.51.100.22"
},
"port": 80,
"priority": 2,
"type": "REFLEXIVE",
"connection": "wired",
"asn": "64496",
"peer_protocol": "PPSP-PP"
}
},
{
"peer_id": "3332001256741",
"peer_addr": {
"ip_address": {
"address_type": "ipv4",
"address": "198.51.100.201"
},
"port": 80,
"priority": 2,
"type": "REFLEXIVE",
"peer_addr": {
"ip_address": {
"address_type": "ipv4",
"address": "198.51.100.1"
},
"port": 80,
"priority": 1,
"asn": "64496"
},
"swarm_result": {
"swarm_id": "2222",
"result": 0,
"peer_group": {
"peer_info": [{
"peer_id": "956264622298",
"peer_addr": {
"ip_address": {
"address_type": "ipv4",
"address": "198.51.100.22"
},
"port": 80,
"priority": 2,
"type": "REFLEXIVE",
"connection": "wired",
"asn": "64496",
"peer_protocol": "PPSP-PP"
}
},
{
"peer_id": "3332001256741",
"peer_addr": {
"ip_address": {
"address_type": "ipv4",
"address": "198.51.100.201"
},
"port": 80,
"priority": 2,
"type": "REFLEXIVE",
"connection": "wired",
"asn": "64496",
"peer_protocol": "PPSP-PP"
}
}]
}
}
}
}
"connection": "wired",
"asn": "64496",
"peer_protocol": "PPSP-PP"
}
}]
}
}
}
}
This method allows peers to request a new peer list for the swarm from the tracker whenever needed.
这种方法允许节点在需要时向跟踪器请求一个新的集群节点列表。
The FIND request may include a peer_number element to indicate to the tracker the maximum number of peers to be returned in a list corresponding to the indicated conditions set by the requesting peer, being ability_nat for NAT traversal (considering that PPSP-ICE NAT traversal techniques may be used), and optionally concurrent_links, online_time, and upload_bandwidth for the preferred capabilities.
查找请求可包括对等方编号元素，以向跟踪器指示与请求对等方设置的指示条件相对应的列表中要返回的最大对等方数量，即nat穿越能力（考虑到可使用PPSP-ICE nat穿越技术），以及可选的并发链路、在线时间，并上传首选功能的\u带宽。
When receiving a well-formed FIND request, the tracker processes the information to check if it is valid. If successful, a response message with a response value of SUCCESSFUL will be generated, and the tracker will search out the list of peers for the swarm and select an appropriate peer list satisfying the conditions set by the requesting peer. The peer list returned MUST contain the peer IDs and the corresponding IP addresses.
当收到格式良好的查找请求时，跟踪器将处理该信息以检查其是否有效。如果成功，将生成响应值为successful的响应消息，跟踪器将搜索群中的对等点列表，并选择满足请求对等点设置的条件的适当对等点列表。返回的对等列表必须包含对等ID和相应的IP地址。
The tracker may take the ability of peers and popularity of the requested content into consideration. For example, the tracker could select peers with higher ability than the current peers that provide the content if the content is relatively popular (see Section 5.1.1); the tracker could also select peers with lower ability than the current peers that provide the content when the content is relatively uncommon. The tracker may take network location information into consideration as well, to express network topology preferences or operators' policy preferences. It can implement other IETF efforts like ALTO [RFC7285], which is out of the scope of this document.
跟踪器可以考虑对等方的能力和所请求内容的流行性。例如，如果内容相对流行，跟踪器可以选择比提供内容的当前对等点具有更高能力的对等点（参见第5.1.1节）；当内容相对不常见时，跟踪器还可以选择能力低于当前提供内容的对等方的对等方。跟踪器还可以考虑网络位置信息，以表示网络拓扑偏好或运营商的策略偏好。它可以实施其他IETF工作，如ALTO[RFC7285]，这超出了本文件的范围。
The response MUST include a peer_group element that contains the peer IDs and the corresponding IP addresses; it may also include the attribute asn with network location information of the transport address, corresponding to the Autonomous System Number of the access network provider of the referenced peer.
响应必须包括包含对等ID和相应IP地址的对等组元素；它还可以包括具有传输地址的网络位置信息的属性asn，该传输地址对应于被引用对等方的接入网络提供商的自治系统号。
The response may also include a peer_addr element that includes the requesting peer public IP address. If no STUN is used and the tracker is able to work as a "STUN-like" server that can inspect the public address of a peer, the tracker can return the address back with a "REFLEXIVE" attribute type.
响应还可以包括包括请求的对等公共IP地址的对等地址元素。如果没有使用眩晕，并且跟踪器能够作为“类似眩晕”的服务器工作，可以检查对等方的公共地址，跟踪器可以使用“反射”属性类型返回地址。
IMPLEMENTATION NOTE: If no peer_num attributes are present in the request, the tracker may return a random sample from the peer population.
实现注意：如果请求中不存在peer_num属性，那么跟踪器可能会从对等群体中返回一个随机样本。
An example of the message-body of a FIND request, where the peer requests from the tracker a list of not more than 5 peers in the swarm "1111" conforming to the characteristics expressed (concurrent links, online time, and upload bandwidth level) is as follows:
查找请求的消息体的示例，其中来自跟踪器的对等方请求符合所表达特征（并发链路、在线时间和上载带宽水平）的群“1111”中不超过5个对等方的列表，如下所示：
{
"PPSPTrackerProtocol": {
"version": 1,
"request_type": "FIND",
"transaction_id": "12345",
"peer_id": "656164657221",
"swarm_id": "1111",
"peer_num": {
"peer_count": 5,
"ability_nat": "STUN",
"concurrent_links": "5",
"online_time": "200",
"upload_bandwidth": "600"
}
}
}
{
"PPSPTrackerProtocol": {
"version": 1,
"request_type": "FIND",
"transaction_id": "12345",
"peer_id": "656164657221",
"swarm_id": "1111",
"peer_num": {
"peer_count": 5,
"ability_nat": "STUN",
"concurrent_links": "5",
"online_time": "200",
"upload_bandwidth": "600"
}
}
}
An example of the message-body of a response for the above FIND request, including the requesting peer public IP address information, is as follows:
包括请求对等公共IP地址信息的上述查找请求的响应的消息体示例如下：
{
"PPSPTrackerProtocol": {
"version": 1,
"response_type": 0,
"error_code": 0,
"transaction_id": "12345",
"swarm_result": {
"swarm_id": "1111",
"result": 0,
"peer_group": {
"peer_info": [{
{
"PPSPTrackerProtocol": {
"version": 1,
"response_type": 0,
"error_code": 0,
"transaction_id": "12345",
"swarm_result": {
"swarm_id": "1111",
"result": 0,
"peer_group": {
"peer_info": [{
"peer_id": "656164657221",
"peer_addr": {
"ip_address": {
"address_type": "ipv4",
"address": "198.51.100.1"
},
"port": 80,
"priority": 1,
"peer_id": "656164657221",
"peer_addr": {
"ip_address": {
"address_type": "ipv4",
"address": "198.51.100.1"
},
"port": 80,
"priority": 1,
"type": "REFLEXIVE",
"connection": "wireless",
"asn": "64496"
}
},
{
"peer_id": "956264622298",
"peer_addr": {
"ip_address": {
"address_type": "ipv4",
"address": "198.51.100.22"
},
"port": 80,
"priority": 1,
"type": "REFLEXIVE",
"connection": "wireless",
"asn": "64496"
}
},
{
"peer_id": "3332001256741",
"peer_addr": {
"ip_address": {
"address_type": "ipv4",
"address": "198.51.100.201"
},
"port": 80,
"priority": 1,
"type": "REFLEXIVE",
"type": "REFLEXIVE",
"connection": "wireless",
"asn": "64496"
}
},
{
"peer_id": "956264622298",
"peer_addr": {
"ip_address": {
"address_type": "ipv4",
"address": "198.51.100.22"
},
"port": 80,
"priority": 1,
"type": "REFLEXIVE",
"connection": "wireless",
"asn": "64496"
}
},
{
"peer_id": "3332001256741",
"peer_addr": {
"ip_address": {
"address_type": "ipv4",
"address": "198.51.100.201"
},
"port": 80,
"priority": 1,
"type": "REFLEXIVE",
"connection": "wireless",
"asn": "64496"
}
}]
}
}
}
}
"connection": "wireless",
"asn": "64496"
}
}]
}
}
}
}
This method allows peers to send status and statistic data to trackers. The method is periodically initiated by the peer while it is active.
这种方法允许节点向跟踪器发送状态和统计数据。当对等方处于活动状态时，该方法会定期由对等方启动。
The peer MUST set the request_type to "STAT_REPORT", set the peer_id with the identifier of the peer, and generate and set the transaction_id.
对等方必须将请求类型设置为“STAT\u REPORT”，使用对等方的标识符设置对等方id，并生成和设置事务id。
The report may include multiple statistics elements describing several properties relevant to a specific swarm. These properties can be related with stream statistics and peer status information, including uploaded_bytes, downloaded_bytes, available_bandwidth, concurrent_links, etc.
该报告可能包括多个统计元素，描述与特定群相关的若干属性。这些属性可以与流统计信息和对等状态信息相关，包括上载的\u字节、下载的\u字节、可用的\u带宽、并发的\u链接等。
Other properties may be defined (see the guidelines in Section 7.1), for example, those related to incentives and reputation mechanisms. If no Statistics Group is included, the STAT_REPORT is used as a "keep-alive" message to prevent the tracker from de-registering the peer when the "track timer" expires.
可以定义其他属性（参见第7.1节中的指南），例如，与激励和声誉机制相关的属性。如果未包含任何统计组，则STAT_报告将用作“保持活动”消息，以防止跟踪器在“跟踪计时器”过期时注销对等方。
If the request is valid, the tracker processes the received information for future use and generates a response message with a response value of SUCCESSFUL.
如果请求有效，跟踪器将处理接收到的信息以备将来使用，并生成响应值为SUCCESSFUL的响应消息。
The response MUST have the same transaction_id value as the request.
响应必须与请求具有相同的事务id值。
An example of the message-body of a STAT_REPORT request is:
STAT_报告请求的消息体示例如下：
{
"PPSPTrackerProtocol": {
"version": 1,
"request_type": "STAT_REPORT",
"transaction_id": "12345",
"peer_id": "656164657221",
"stat_report": {
"type": "STREAM_STATS",
"Stat": {
"swarm_id": "1111",
"uploaded_bytes": 512,
"downloaded_bytes": 768,
"available_bandwidth": 1024000,
"concurrent_links": 5
}
}
}
}
{
"PPSPTrackerProtocol": {
"version": 1,
"request_type": "STAT_REPORT",
"transaction_id": "12345",
"peer_id": "656164657221",
"stat_report": {
"type": "STREAM_STATS",
"Stat": {
"swarm_id": "1111",
"uploaded_bytes": 512,
"downloaded_bytes": 768,
"available_bandwidth": 1024000,
"concurrent_links": 5
}
}
}
}
An example of the message-body of a response for the START_REPORT request is:
启动报告请求响应的消息体示例如下：
{
"PPSPTrackerProtocol": {
"version": 1,
"response_type": 0,
"error_code": 0,
"transaction_id": "12345",
"swarm_result": {
"swarm_id": "1111",
"result": 0
}
}
}
{
"PPSPTrackerProtocol": {
"version": 1,
"response_type": 0,
"error_code": 0,
"transaction_id": "12345",
"swarm_result": {
"swarm_id": "1111",
"result": 0
}
}
}
Table 7 indicates the response type and corresponding semantics.
表7显示了响应类型和相应的语义。
+--------------------+---------------------+
| Response Type | Semantics |
| | |
+--------------------+---------------------+
| 0 | SUCCESSFUL |
| 1 | FAILED |
+--------------------+---------------------+
+--------------------+---------------------+
| Response Type | Semantics |
| | |
+--------------------+---------------------+
| 0 | SUCCESSFUL |
| 1 | FAILED |
+--------------------+---------------------+
Table 7: Semantics for the Value of Response Type
表7：响应类型值的语义
SUCCESSFUL: Indicates that the request has been processed properly and the desired operation has completed. The body of the response message includes the requested information and MUST include the same transaction_id as the corresponding request.
成功：表示请求已正确处理，并且所需操作已完成。响应消息的主体包含请求的信息，并且必须包含与相应请求相同的事务id。
CONNECT: Returns information about the successful registration of the peer and/or of each swarm action requested. May additionally return the list of peers corresponding to the action attribute requested.
CONNECT：返回有关成功注册对等方和/或请求的每个swarm操作的信息。还可以返回与请求的操作属性相对应的对等方列表。
FIND: Returns the list of peers corresponding to the requested scope.
查找：返回与请求的范围相对应的对等方列表。
STAT_REPORT: Confirms the success of the requested operation.
统计报告：确认请求的操作成功。
FAILED: Indicates that the request has not been processed properly. A corresponding error_code SHOULD be set according to the conditions described in Section 4.3.
失败：表示请求未正确处理。应根据第4.3节所述条件设置相应的错误代码。
If the peer receives an invalid response, the same request with identical content including the same transaction_id MUST be repeated.
如果对等方收到无效响应，则必须重复包含相同事务id的相同内容的相同请求。
The transaction_id on a request can be reused if and only if all of the content is identical, including date/time information. Details of the retry process (including time intervals to pause, number of retries to attempt, and timeouts for retrying) are implementation dependent.
当且仅当所有内容（包括日期/时间信息）相同时，才能重用请求上的事务id。重试过程的详细信息（包括暂停的时间间隔、重试次数和重试超时）取决于实现。
The tracker MUST be prepared to receive a request with a repeated transaction_id.
跟踪器必须准备好接收具有重复事务id的请求。
Error situations resulting from normal operation or from abnormal conditions (Section 2.3.2) MUST be responded to with response_type set to 0x01 and with the adequate error_code, as described here:
由正常操作或异常条件（第2.3.2节）引起的错误情况必须响应，响应类型设置为0x01，并使用适当的错误代码，如下所述：
o If the message is found to be incorrectly formed, the receiver MUST respond with a 01 (Bad Request) error_code with an empty message-body (no peer_addr and swarm_result attributes).
o 如果发现消息格式不正确，则接收方必须以01（错误请求）错误代码响应，且消息正文为空（无对等地址和swarm结果属性）。
o If the version number of the protocol is for a version the receiver does not support, the receiver MUST respond with a 02 (Unsupported Version Number) error_code with an empty message-body (no peer_addr and swarm_result attributes).
o 如果协议的版本号用于接收方不支持的版本，则接收方必须使用02（不支持的版本号）错误代码响应，且消息正文为空（无对等地址和swarm结果属性）。
o In the PEER REGISTERED and TRACKING states of the tracker, certain requests are not allowed (Section 2.3.2). The tracker MUST respond with a 03 (Forbidden Action) error_code with an empty message-body (no peer_addr and swarm_result attributes).
o 在跟踪器的对等注册和跟踪状态下，不允许某些请求（第2.3.2节）。跟踪器必须响应03（禁止操作）错误代码，消息正文为空（无对等地址和swarm结果属性）。
o If the tracker is unable to process a request message due to an unexpected condition, it SHOULD respond with a 04 (Internal Server Error) error_code with an empty message-body (no peer_addr and swarm_result attributes).
o 如果跟踪程序由于意外情况而无法处理请求消息，则应使用04（内部服务器错误）错误代码响应，并带有空消息正文（无对等地址和swarm结果属性）。
o If the tracker is unable to process a request message because it is in an overloaded state, it SHOULD respond with a 05 (Service Unavailable) error_code with an empty message-body (no peer_addr and swarm_result attributes).
o 如果跟踪器由于处于过载状态而无法处理请求消息，则应使用05（服务不可用）错误代码响应，且消息正文为空（无对等地址和swarm结果属性）。
o If authentication is required for the peer to make the request, the tracker SHOULD respond with a 06 (Authentication Required) error_code with an empty message-body (no peer_addr and swarm_result attributes).
o 如果对等方需要身份验证才能发出请求，则跟踪器应以06（需要身份验证）错误代码响应，且消息正文为空（无对等方地址和swarm结果属性）。
This document only details object members used by this specification. Extensions may include additional members within JSON objects defined in this document. PPSTP implementations MUST ignore unknown members when processing PPSTP messages.
本文档仅详细说明本规范使用的对象成员。扩展可能包括本文档中定义的JSON对象中的其他成员。PPSTP实现在处理PPSTP消息时必须忽略未知成员。
This section provides the operational and management aspects that are required to be considered in implementations of PPSTP. These aspects follow the recommendations expressed in [RFC5706].
本节提供了在实施PPSTP时需要考虑的运营和管理方面。这些方面遵循[RFC5706]中提出的建议。
PPSTP provides communication between trackers and peers and is conceived as a "client-server" mechanism, allowing the exchange of information about the participant peers sharing multimedia streaming content.
PPSTP提供跟踪器和对等点之间的通信，被认为是一种“客户机-服务器”机制，允许交换关于共享多媒体流内容的参与者对等点的信息。
The "server" component, i.e., the tracker, is a logical entity that can be envisioned as a centralized service (implemented in one or more physical nodes) or a fully distributed service.
“服务器”组件，即跟踪器，是一个逻辑实体，可以设想为一个集中式服务（在一个或多个物理节点中实现）或一个完全分布式的服务。
The "client" component can be implemented at each peer participating in the streaming of content.
“客户端”组件可以在参与内容流的每个对等方上实现。
Content providers wishing to use PPSP for content distribution should set up at least a PPSP tracker and a service portal (public web server) to publish links of the content descriptions, for access to their on-demand or live original content sources. Content and service providers should also create conditions to generate peer IDs and any required security certificates, as well as chunk IDs and swarm IDs for each streaming content. The configuration processes for the PPSP tracking facility, the service portal, and content sources are not standardized, enabling flexibility for implementers.
希望使用PPSP进行内容分发的内容提供商应至少设置一个PPSP跟踪器和一个服务门户（公共web服务器），以发布内容描述的链接，以便访问其按需或实时原始内容源。内容和服务提供商还应创造条件，为每个流媒体内容生成对等ID和任何必需的安全证书，以及区块ID和swarm ID。PPSP跟踪设施、服务门户和内容源的配置过程没有标准化，这使得实施者具有灵活性。
The swarm IDs of available content, as well as the addresses of the PPSP tracking facility, can be distributed to end users in various ways, but it is common practice to include both the swarm ID and the corresponding PPSP tracker addresses (as URLs) in the MPD of the content, which is obtainable (a link) from the service portal.
可用内容的swarm ID以及PPSP跟踪设施的地址可以以各种方式分发给最终用户，但通常的做法是将swarm ID和相应的PPSP跟踪地址（作为URL）包含在内容的MPD中，该MPD可从服务门户获取（链接）。
The available content could have different importance attribute values to indicate whether the content is popular or not. However, it is a totally implementation design and outside the scope of this
可用内容可以具有不同的重要性属性值，以指示内容是否受欢迎。然而，这完全是一个实现设计，不在本手册的范围之内
specification. For example, the importance attribute values of the content could be set by content providers when distributing them or could be determined by the tracker based on the statistics of the requests from the peers that request the content. The tracker could set an upper threshold to decide that the content is popular enough when the importance attribute value is higher than the upper threshold. The tracker could also set a lower threshold to decide that the content is uncommon enough when the importance attribute value is lower than the lower threshold.
规格例如，内容的重要性属性值可以由内容提供者在分发它们时设置，或者可以由跟踪器基于来自请求内容的对等方的请求的统计信息来确定。当重要性属性值高于上限阈值时，跟踪器可以设置上限阈值来确定内容是否足够流行。当重要性属性值低于较低阈值时，跟踪器还可以设置较低阈值，以确定内容是否足够罕见。
End users browse and search for desired content in the service portal and select by clicking the links of the corresponding MPDs. This action typically requires security certificates or authorization tokens from an enrollment service (end-user registration) and then launches the Client Media Player (with PPSP awareness), which will then, using PPSTP, contact the PPSP tracker to join the corresponding swarm and obtain the transport addresses of other PPSP peers in order to start streaming the content.
最终用户在服务门户中浏览和搜索所需内容，并通过单击相应MPD的链接进行选择。此操作通常需要来自注册服务（最终用户注册）的安全证书或授权令牌，然后启动客户端媒体播放器（具有PPSP感知），然后将使用PPSP，联系PPSP跟踪器加入相应的swarm并获取其他PPSP对等方的传输地址，以便开始流式传输内容。
There is no previous standard protocol providing functionality similar to PPSTP. However, some popular proprietary protocols, e.g., BitTorrent, are used in existing systems. There is no way for PPSTP to migrate to proprietary protocols like the BitTorrent tracker protocol. Because PPSTP is an application-level protocol, there is no harm in PPSTP having no migration path. However, proprietary protocols migrating to standard protocols like PPSTP can solve the problems raised in [RFC6972]. It is also possible for systems to use PPSTP as the management protocol to work with exiting propriety peer protocols like the BitTorrent peer protocol.
以前没有提供类似于PPSTP功能的标准协议。然而，一些流行的专有协议，例如BitTorrent，在现有系统中使用。PPSTP无法迁移到像BitTorrent tracker协议这样的专有协议。因为PPSTP是一个应用程序级协议，所以PPSTP没有迁移路径是无害的。但是，迁移到标准协议（如PPSTP）的专有协议可以解决[RFC6972]中提出的问题。系统也可以使用PPSTP作为管理协议，与现有的适当对等协议（如BitTorrent对等协议）一起工作。
For security reasons, when using the Peer-to-Peer Streaming Peer Protocol (PPSPP) with PPSTP, the mechanisms described in Section 6.1 should be observed.
出于安全原因，当将对等流媒体对等协议（PPSPP）与PPSTP一起使用时，应遵守第6.1节中描述的机制。
As the messaging model of PPSTP aligns with HTTP and the semantics of its messages, the impact on network operation is similar to using HTTP.
由于PPSTP的消息传递模型与HTTP及其消息的语义一致，因此对网络运行的影响与使用HTTP类似。
The correct operation of PPSTP can be verified both at the tracker and at the peer by logging the behavior of PPSTP. Additionally, the PPSP tracker collects the status of the peers, including the peers' activity; such information can be used to monitor and obtain the global view of the operation.
通过记录PPSTP的行为，可以在跟踪器和对等机上验证PPSTP的正确操作。此外，PPSP跟踪器收集对等方的状态，包括对等方的活动；此类信息可用于监控和获取操作的全局视图。
The management considerations for PPSTP are similar to other solutions using HTTP for large-scale content distribution. The PPSP tracker can be realized by geographically distributed tracker nodes or multiple server nodes in a data center. As these nodes are akin to WWW nodes, their configuration procedures, detection of faults, measurement of performance, usage accounting, and security measures can be achieved by standard solutions and facilities.
PPSTP的管理注意事项与使用HTTP进行大规模内容分发的其他解决方案类似。PPSP跟踪器可以通过地理上分布的跟踪器节点或数据中心中的多个服务器节点来实现。由于这些节点类似于WWW节点，它们的配置过程、故障检测、性能测量、使用计费和安全措施可以通过标准解决方案和设施实现。
Interoperability refers to allowing information sharing and operations between multiple devices and multiple management applications. For PPSTP, distinct types of devices host PPSTP trackers and peers. Therefore, support for multiple standard schema languages, management protocols, and information models, suited to different purposes, was considered in the PPSTP design. Specifically, management functionality for PPSTP devices can be achieved with the Simple Network Management Protocol (SNMP) [RFC3410], syslog [RFC5424], and the Network Configuration Protocol (NETCONF) [RFC6241].
互操作性是指允许在多个设备和多个管理应用程序之间共享和操作信息。对于PPSTP，不同类型的设备承载PPSTP跟踪器和对等点。因此，在PPSTP设计中考虑了对多个标准模式语言、管理协议和信息模型的支持，以适应不同的目的。具体而言，PPSTP设备的管理功能可通过简单网络管理协议（SNMP）[RFC3410]、系统日志[RFC5424]和网络配置协议（NETCONF）[RFC6241]实现。
PPSP trackers may implement SNMP management interfaces, namely, the Application Management MIB [RFC2564], without the need to instrument the tracker application itself. The channel, connections, and transaction objects of the Application Management MIB can be used to report the basic behavior of the PPSP tracker service.
PPSP跟踪器可以实现SNMP管理接口，即应用程序管理MIB[RFC2564]，而无需对跟踪器应用程序本身进行检测。应用程序管理MIB的通道、连接和事务对象可用于报告PPSP跟踪器服务的基本行为。
The Application Performance Measurement MIB (APM-MIB) [RFC3729] and the Transport Performance Metrics MIB (TPM-MIB) [RFC4150] can be used with PPSTP to provide adequate metrics for the analysis of performance for transaction flows in the network, in direct relationship to the transport of PPSTP.
应用程序性能度量MIB（APM-MIB）[RFC3729]和传输性能度量MIB（TPM-MIB）[RFC4150]可与PPSTP一起使用，以提供与PPSTP传输直接相关的网络事务流性能分析的适当度量。
The Host Resources MIB [RFC2790] can be used to supply information on the hardware, the operating system, and the installed and running software on a PPSP tracker host.
主机资源MIB[RFC2790]可用于提供PPSP跟踪主机上的硬件、操作系统以及已安装和正在运行的软件的信息。
The TCP-MIB [RFC4022] can additionally be considered for network monitoring.
TCP-MIB[RFC4022]还可用于网络监控。
Logging is an important functionality for PPSTP trackers and peers; it is done via syslog [RFC5424].
日志记录是PPSTP跟踪器和对等机的一项重要功能；这是通过syslog[RFC5424]完成的。
As PPSP tracker failures can be mainly attributed to host or network conditions, the facilities previously described for verifying the correct operation of PPSTP and the management of PPSP tracker servers appear sufficient for PPSTP fault monitoring.
由于PPSP跟踪器故障主要归因于主机或网络状况，因此前面描述的用于验证PPSP跟踪器正确运行和管理PPSP跟踪器服务器的设施似乎足以进行PPSP故障监控。
PPSP tracker deployments, when realized by geographically distributed tracker nodes or multiple server nodes in a data center, may benefit from a standard way of replicating atomic configuration updates over a set of server nodes. This functionality can be provided via NETCONF [RFC6241].
PPSP跟踪器部署由地理上分布的跟踪器节点或数据中心中的多个服务器节点实现时，可能会受益于在一组服务器节点上复制原子配置更新的标准方法。此功能可通过NETCONF[RFC6241]提供。
PPSTP implementations, primarily in content provider environments, can benefit from accounting standardization efforts as described in [RFC2975], which indicates that accounting management is "concerned with the collection of resource consumption data for the purposes of capacity and trend analysis, cost allocation, auditing, and billing".
PPSTP实施（主要在内容提供商环境中）可以受益于[RFC2975]中所述的会计标准化工作，这表明会计管理“关注资源消耗数据的收集，以便进行容量和趋势分析、成本分配、审计和计费”。
Because PPSTP is transaction oriented, its performance in terms of availability and responsiveness can be measured with the facilities of the APM-MIB [RFC3729] and the TPM-MIB [RFC4150].
由于PPSTP是面向事务的，因此其可用性和响应性方面的性能可以通过APM-MIB[RFC3729]和TPM-MIB[RFC4150]的功能来衡量。
Standard SNMP notifications for PPSP tracker management [RFC5590] and syslog messages [RFC5424] can be used to alert operators to the conditions identified in the security considerations (Section 6).
PPSP跟踪器管理[RFC5590]和系统日志消息[RFC5424]的标准SNMP通知可用于提醒操作员注意安全注意事项（第6节）中确定的情况。
The statistics collected about the operation of PPSTP can be used for detecting attacks (e.g., the receipt of malformed messages, messages out of order, or messages with invalid timestamps). However, collecting such endpoint properties may also raise some security issues. For example, the statistics collected by the tracker may be disclosed to an unauthorized third party that has malicious intentions. To address such risk, the provider of the tracker should
收集的有关PPSTP操作的统计信息可用于检测攻击（例如，接收格式错误的消息、顺序错误的消息或时间戳无效的消息）。然而，收集这样的端点属性也可能引起一些安全问题。例如，跟踪器收集的统计数据可能被披露给具有恶意意图的未经授权的第三方。为解决此类风险，跟踪器供应商应
evaluate how much information is revealed and the associated risks. A confidentiality mechanism must be provided by HTTP over TLS to guarantee the confidentiality of PPSTP.
评估披露了多少信息以及相关风险。HTTP over TLS必须提供保密机制，以保证PPSTP的机密性。
P2P streaming systems are subject to attacks by malicious or unfriendly peers/trackers that may eavesdrop on signaling, forge/deny information/knowledge about streaming content and/or its availability, impersonate a valid participant, or launch DoS attacks on a chosen victim.
P2P流媒体系统受到恶意或不友好的对等方/跟踪器的攻击，这些对等方/跟踪器可能窃听信号、伪造/拒绝有关流媒体内容和/或其可用性的信息/知识、冒充有效参与者或对选定的受害者发起DoS攻击。
No security system can guarantee complete security in an open P2P streaming system where participants may be malicious or uncooperative. The goal of the security considerations described here is to provide sufficient protection for maintaining some security properties during tracker-peer communication even in the face of a large number of malicious peers and/or eventual distrustful trackers (under the distributed tracker deployment scenario).
在开放的P2P流媒体系统中，没有任何安全系统可以保证完全的安全，参与者可能是恶意的或不合作的。此处描述的安全注意事项的目标是提供足够的保护，以便在跟踪器对等通信期间维护某些安全属性，即使面对大量恶意对等方和/或最终不信任跟踪器（在分布式跟踪器部署场景下）。
Since the protocol uses HTTP to transfer signaling, most of the security considerations described in [RFC7230] and [RFC7231] also apply. Due to the transactional nature of the communication between peers and tracker, the method for adding authentication and data security services can be the OAuth 2.0 Authorization [RFC6749] with a bearer token, which provides the peer with the information required to successfully utilize an access token to make protected requests to the tracker.
由于协议使用HTTP传输信令，[RFC7230]和[RFC7231]中描述的大多数安全注意事项也适用。由于对等方和跟踪器之间通信的事务性，用于添加认证和数据安全服务的方法可以是OAuth 2.0授权[RFC6749]和承载令牌，该授权向对等方提供成功利用访问令牌向跟踪器发出受保护请求所需的信息。
To protect PPSTP signaling from attackers pretending to be valid peers (or peers other than themselves), all messages received in the tracker SHOULD be received from authorized peers. For that purpose, a peer SHOULD enroll in the system via a centralized enrollment server. The enrollment server is expected to provide a proper peer ID for the peer and information about the authentication mechanisms. The specification of the enrollment method and the provision of identifiers and authentication tokens is out of the scope of this specification.
为了保护PPSTP信令不受假装为有效对等方（或自身以外的对等方）的攻击者的攻击，在跟踪器中接收到的所有消息都应从授权对等方接收。为此，对等方应通过集中式注册服务器在系统中注册。注册服务器应为对等方提供适当的对等ID以及有关身份验证机制的信息。注册方法的规范以及标识符和身份验证令牌的提供超出了本规范的范围。
Transport Layer Security (TLS) [RFC5246] MUST be used in the communication between peers and tracker to provide privacy and data integrity. Software engineers developing and service providers deploying the tracker should make themselves familiar with the Best Current Practices (BCP) on configuring HTTP over TLS [RFC7525].
传输层安全（TLS）[RFC5246]必须用于对等方和跟踪器之间的通信，以提供隐私和数据完整性。开发和部署跟踪器的软件工程师和服务提供商应熟悉在TLS上配置HTTP的最佳实践（BCP）[RFC7525]。
OAuth 2.0 Authorization [RFC6749] SHOULD also be considered when digest authentication [RFC7616] and HTTPS client certificates are required.
当需要摘要身份验证[RFC7616]和HTTPS客户端证书时，还应考虑OAuth 2.0授权[RFC6749]。
Malicious peers may claim ownership of popular content to the tracker and try to serve polluted (i.e., decoy content or even virus/trojan-infected content) to other peers. Since trackers do not exchange content information among peers, it is difficult to detect whether or not a peer is polluting the content. Usually, this kind of pollution can be detected by the Peer-to-Peer Streaming Peer Protocol (PPSPP) [RFC7574] with requiring the use of Merkle Hash Tree scheme for protecting the integrity of the content. More details can be seen in Section 5 of [RFC7574].
恶意对等方可能会向跟踪器声明流行内容的所有权，并尝试向其他对等方提供受污染的内容（即诱骗内容，甚至是受病毒/特洛伊木马病毒感染的内容）。由于跟踪器不在对等方之间交换内容信息，因此很难检测对等方是否污染了内容。通常，这种污染可以通过点对点流式对等协议（PPSP）[RFC7574]检测到，需要使用Merkle哈希树方案来保护内容的完整性。更多详情见[RFC7574]第5节。
Some attackers that disrupt P2P streaming on behalf of content providers may provide false or modified content or peer list information to achieve certain malicious goals. Peers connecting to those portals or trackers provided by the attackers may be redirected to some corrupted malicious content. However, there is no standard way for peers to avoid this kind of situation completely. Peers can have mechanisms to detect undesirable content or results themselves. For example, if a peer finds that the portal returned some undesired content information or the tracker returned some malicious peer lists, the peer may choose to quit the swarm or switch to other P2P streaming services provided by other content providers.
一些代表内容提供商破坏P2P流的攻击者可能会提供虚假或修改的内容或对等列表信息，以达到某些恶意目的。连接到攻击者提供的门户或跟踪器的对等方可能被重定向到某些损坏的恶意内容。然而，对于同龄人来说，没有标准的方法可以完全避免这种情况。对等方可以有自己检测不需要的内容或结果的机制。例如，如果对等方发现门户返回了一些不需要的内容信息或跟踪器返回了一些恶意的对等方列表，则对等方可以选择退出swarm或切换到其他内容提供商提供的其他P2P流媒体服务。
To mitigate the impact of Sybil attackers impersonating a large number of valid participants by repeatedly acquiring different peer identities, the enrollment server SHOULD carefully regulate the rate of peer/tracker admission.
为了通过反复获取不同的对等身份来减轻Sybil攻击者模拟大量有效参与者的影响，注册服务器应仔细调节对等/跟踪器接纳率。
There is no guarantee that peers honestly report their status to the tracker, or serve authentic content to other peers as they claim to the tracker. It is expected that a global trust mechanism, where the credit of each peer is accumulated from evaluations for previous transactions, may be taken into account by other peers when selecting partners for future transactions, helping to mitigate the impact of such malicious behaviors. A globally trusted tracker may also take part in the trust mechanism by collecting evaluations, computing credit values, and providing them to joining peers.
无法保证对等方诚实地向跟踪器报告其状态，或向其他对等方提供真实的内容，因为他们向跟踪器声明。预计在为未来交易选择合作伙伴时，其他对等方可能会考虑到一种全局信任机制，其中每个对等方的信用都是通过对以前交易的评估来累积的，这有助于减轻此类恶意行为的影响。全局可信跟踪器还可以通过收集评估、计算信用值并将其提供给加入的对等方来参与信任机制。
Property types for STAT_REPORT messages may consider additional pro-incentive parameters (see the guidelines for extension in Section 7), which can enable the tracker to improve the performance of the whole P2P streaming system. Trustworthiness of these pro-incentive parameters is critical to the effectiveness of the incentive mechanisms. Furthermore, the amount of both uploaded and downloaded data should be reported to the tracker to allow checking for inconsistencies between the upload and download report and to establish an appropriate credit/trust system.
STATETREST消息的属性类型可以考虑附加的激励参数（参见第7节中的扩展指南），这可以使跟踪器提高整个P2P流媒体系统的性能。这些亲激励参数的可信度对于激励机制的有效性至关重要。此外，上传和下载的数据量应报告给跟踪器，以便检查上传和下载报告之间的不一致，并建立适当的信用/信任系统。
One such solution could be a reputation-incentive mechanism, based on the notions of reputation, social awareness, and fairness. The mechanism would promote cooperation among participants (via each peer's reputation) based on the history of past transactions, such as, count of chunk requests (sent and received) in a swarm, contribution time of the peer, cumulative uploaded and downloaded content, JOIN and LEAVE timestamps, attainable rate, etc.
其中一个解决方案可以是基于声誉、社会意识和公平的概念的声誉激励机制。该机制将（通过每个对等方的声誉）根据过去交易的历史，促进参与者之间的合作，例如，群中区块请求（发送和接收）的数量、对等方的贡献时间、累计上传和下载内容、加入和离开时间戳、可达到的速率等。
Alternatively, exchange of cryptographic receipts signed by receiving peers can be used to attest to the upload contribution of a peer to the swarm, as suggested in [Contracts].
或者，接收对等方签署的加密收据交换可用于证明对等方对swarm的上传贡献，如[合同]中所述。
PPSTP provides mechanisms in which the peers can send messages containing IP addresses, ports, and other information to the tracker. A tracker or a third party who is able to intercept such messages can store and process the obtained information in order to analyze peers' behaviors and communication patterns. Such analysis can lead to privacy risks. For example, an unauthorized party may snoop on the data transmission from the peer to a tracker in order to introduce some corrupted chunks.
PPSTP提供了一些机制，在这些机制中，对等方可以向跟踪器发送包含IP地址、端口和其他信息的消息。能够截获此类消息的跟踪器或第三方可以存储和处理获得的信息，以便分析对等方的行为和通信模式。这种分析可能导致隐私风险。例如，未经授权的一方可能窥探从对等方到跟踪器的数据传输，以便引入一些损坏的数据块。
The Peer-to-Peer Streaming Peer Protocol (PPSPP) [RFC7574] has already introduced some mechanisms to protect streamed content; see Sections 12.3 and 12.4 of [RFC7574]. For PPSTP, peer implementations as well as tracker implementations MUST support the "https" URI scheme [RFC2818] and Transport Layer Security (TLS) [RFC5246]. In addition, a peer should be cognizant about potential trackers tracking through queries of peers, e.g., by using HTTP cookies. PPSTP as specified in this document does not rely on HTTP cookies. Thus, peers may decide not to return cookies received from the tracker, in order to make additional tracking more difficult.
对等流媒体对等协议（PPSPP）[RFC7574]已经引入了一些机制来保护流媒体内容；见[RFC7574]第12.3节和第12.4节。对于PPSTP，对等实现以及跟踪器实现必须支持“https”URI方案[RFC2818]和传输层安全性（TLS）[RFC5246]。此外，对等方应了解通过对等方查询（例如，通过使用HTTP cookie）进行跟踪的潜在追踪器。本文档中指定的PPSTP不依赖HTTP cookies。因此，对等方可能决定不返回从跟踪器接收到的cookie，以使额外的跟踪更加困难。
Extension mechanisms allow designers to add new features or to customize existing features of a protocol for different operating environments [RFC6709].
扩展机制允许设计人员为不同的操作环境添加新功能或自定义协议的现有功能[RFC6709]。
Extending a protocol implies either the addition of features without changing the protocol itself or the addition of new elements creating new versions of an existing schema and therefore new versions of the protocol.
扩展协议意味着要么在不更改协议本身的情况下添加特性，要么添加新元素，创建现有模式的新版本，从而创建协议的新版本。
In PPSTP, this means that an extension MUST NOT alter an existing protocol schema as the changes would result in a new version of an existing schema, not an extension of an existing schema, typically non-backwards-compatible.
在PPSTP中，这意味着扩展不能更改现有协议模式，因为更改将导致现有模式的新版本，而不是现有模式的扩展，通常是不向后兼容的。
Additionally, a designer MUST remember that extensions themselves may also be extensible.
此外，设计者必须记住，扩展本身也可能是可扩展的。
Extensions MUST adhere to the principles described in this section in order to be considered valid.
扩展必须遵守本节中描述的原则才能被视为有效。
Extensions MUST be documented in Standards Track RFCs if there are requirements for coordination, interoperability, and broad distribution.
如果需要协调、互操作性和广泛分发，则必须在标准跟踪RFC中记录扩展。
In PPSTP, two extension mechanisms can be used: a Request-Response Extension or a Protocol-Level Extension.
在PPSTP中，可以使用两种扩展机制：请求-响应扩展或协议级扩展。
o Request-Response Extension: Adding elements or attributes to an existing element mapping in the schema is the simplest form of extension. This form should be explored before any other. This task can be accomplished by extending an existing element mapping.
o 请求-响应扩展：向模式中的现有元素映射添加元素或属性是最简单的扩展形式。这种形式应该在任何其他形式之前进行探索。这个任务可以通过扩展现有的元素映射来完成。
For example, an element mapping for the Statistics Group can be extended to include additional elements needed to express status information about the activity of the peer, such as online time for the stat element.
例如，可以扩展统计组的元素映射，以包括表示对等方活动状态信息所需的其他元素，例如stat元素的在线时间。
o Protocol-Level Extension: If there is no existing element mapping that can be extended to meet the requirements and the existing PPSTP request and response message structures are insufficient, then extending the protocol should be considered in order to define new operational requests and responses.
o 协议级扩展：如果没有可扩展以满足要求的现有元素映射，且现有PPSTP请求和响应消息结构不足，则应考虑扩展协议，以定义新的操作请求和响应。
For example, to enhance the level of control and the granularity of the operations, a new version of the protocol with new messages (JOIN, DISCONNECT), a retro-compatible change in semantics of an existing CONNECT request/response, and an extension in STAT_REPORT could be considered.
例如，为了提高控制水平和操作的粒度，可以考虑使用新消息（连接、断开连接）、现有连接请求/响应语义的追溯兼容更改以及STAT_报告中的扩展的新版本协议。
As illustrated in Figure 6, the peer would use an enhanced CONNECT request to perform the initial registration in the system. Then it would join a first swarm as SEEDER, later join a second swarm as LEECH, and then disconnect from the latter swarm but remain as SEEDER for the first one. When deciding to leave the system, the peer disconnects gracefully from it:
如图6所示，对等方将使用增强的连接请求在系统中执行初始注册。然后它会加入第一个群体作为播种者，然后加入第二个群体作为水蛭，然后与后一个群体断开连接，但仍然作为第一个群体的播种者。当决定离开系统时，对等方会优雅地断开与系统的连接：
+--------+ +---------+
| Peer | | Tracker |
+--------+ +---------+
| |
|--CONNECT--------------------->|
|<--------------------------OK--|
|--JOIN(swarm_a;SEEDER)---------->|
|<--------------------------OK--|
: :
|--STAT_REPORT(activity)------->|
|<--------------------------Ok--|
: :
|--JOIN(swarm_b;LEECH)--------->|
|<-----------------OK+PeerList--|
: :
|--STAT_REPORT(ChunkMap_b)----->|
|<--------------------------Ok--|
: :
|--DISCONNECT(swarm_b)--------->|
|<--------------------------Ok--|
: :
|--STAT_REPORT(activity)------->|
|<--------------------------Ok--|
: :
|--DISCONNECT------------------>|
|<---------------------Ok(BYE)--|
+--------+ +---------+
| Peer | | Tracker |
+--------+ +---------+
| |
|--CONNECT--------------------->|
|<--------------------------OK--|
|--JOIN(swarm_a;SEEDER)---------->|
|<--------------------------OK--|
: :
|--STAT_REPORT(activity)------->|
|<--------------------------Ok--|
: :
|--JOIN(swarm_b;LEECH)--------->|
|<-----------------OK+PeerList--|
: :
|--STAT_REPORT(ChunkMap_b)----->|
|<--------------------------Ok--|
: :
|--DISCONNECT(swarm_b)--------->|
|<--------------------------Ok--|
: :
|--STAT_REPORT(activity)------->|
|<--------------------------Ok--|
: :
|--DISCONNECT------------------>|
|<---------------------Ok(BYE)--|
Figure 6: Example of a Session for a PPSTP Extended Version
图6:PPSTP扩展版本的会话示例
There are several issues that all extensions should take into consideration.
所有扩展都应该考虑几个问题。
o Overview of the Extension: It is RECOMMENDED that extensions to PPSTP have a protocol overview section that discusses the basic operation of the extension. The most important processing rules for the elements in the message flows SHOULD also be mentioned.
o 扩展概述：建议PPSTP的扩展有一个协议概述部分，讨论扩展的基本操作。还应该提到消息流中元素最重要的处理规则。
o Backward Compatibility: The new extension MUST be backward compatible with the base PPSTP specified in this document.
o 向后兼容性：新扩展必须与本文档中指定的基本PPSTP向后兼容。
o Syntactic Issues: Extensions that define new request/response methods SHOULD use all capitals for the method name, keeping with a long-standing convention in many protocols, such as HTTP. Method names are case sensitive in PPSTP. Method names SHOULD be shorter than 16 characters and SHOULD attempt to convey the general meaning of the request or response.
o 语法问题：定义新请求/响应方法的扩展应该使用方法名称的所有大写字母，这与许多协议（如HTTP）中的长期约定保持一致。方法名称在PPSTP中区分大小写。方法名称应少于16个字符，并应尝试传达请求或响应的一般含义。
o Semantic Issues: PPSTP extensions MUST clearly define the semantics of the extensions. Specifically, the extension MUST specify the behaviors expected from both the peer and the tracker in processing the extension, with the processing rules in temporal order of the common messaging scenario.
o 语义问题：PPSTP扩展必须明确定义扩展的语义。具体来说，扩展必须指定对等方和跟踪器在处理扩展时预期的行为，处理规则按照公共消息传递场景的时间顺序。
Processing rules generally specify actions to be taken on receipt of messages and expiration of timers.
处理规则通常指定在收到消息和计时器过期时要采取的操作。
The extension SHOULD specify procedures to be taken in exceptional conditions that are recoverable. Handling of unrecoverable errors does not require specification.
扩展应规定在可恢复的特殊情况下应采取的程序。不可恢复错误的处理不需要规范。
o Security Issues: As security is an important component of any protocol, designers of PPSTP extensions need to carefully consider security requirements, e.g., authorization requirements and requirements for end-to-end integrity.
o 安全性问题：由于安全性是任何协议的重要组成部分，PPSTP扩展的设计者需要仔细考虑安全性要求，例如授权要求和端到端完整性要求。
o Examples of Usage: The specification of the extension SHOULD give examples of message flows and message formatting and include examples of messages containing new syntax. Examples of message flows should be given to cover common cases and at least one failure or unusual case.
o 用法示例：扩展规范应给出消息流和消息格式的示例，并包括包含新语法的消息示例。应给出消息流示例，以涵盖常见情况和至少一种故障或异常情况。
This document registers "application/ppsp-tracker+json" media types.
本文档注册了“应用程序/ppsp跟踪器+json”媒体类型。
Type name: application
类型名称：应用程序
Subtype name: ppsp-tracker+json
子类型名称：ppsp tracker+json
Required parameters: n/a
所需参数：不适用
Optional parameters: n/a
可选参数：不适用
Encoding considerations: Encoding considerations are identical to those specified for the "application/json" media type. See [RFC7159].
编码注意事项：编码注意事项与为“application/json”媒体类型指定的注意事项相同。见[RFC7159]。
Security considerations: See Section 6 of RFC 7846.
安全注意事项：见RFC 7846第6节。
Interoperability considerations: This document specifies the format of conforming messages and the interpretation thereof.
互操作性注意事项：本文件规定了一致性消息的格式及其解释。
Published specification: RFC 7846.
已发布规范：RFC 7846。
Applications that use this media type: PPSP trackers and peers either stand alone or are embedded within other applications.
使用此媒体类型的应用程序：PPSP跟踪器和对等机可以独立运行，也可以嵌入其他应用程序中。
Additional information:
其他信息：
Magic number(s): n/a
Magic number(s): n/a
File extension(s): n/a
File extension(s): n/a
Macintosh file type code(s): n/a
Macintosh file type code(s): n/a
Fragment identifier considerations: n/a
片段标识符注意事项：不适用
Person & email address to contact for further information: See Authors' Addresses section.
联系人和电子邮件地址以了解更多信息：请参阅作者地址部分。
Intended usage: COMMON
预期用途：普通
Restrictions on usage: none
使用限制：无
Author: See Authors' Addresses section of RFC 7846.
作者：参见RFC 7846的作者地址部分。
Change controller: IESG (iesg@ietf.org)
更改控制器：IESG(iesg@ietf.org)
IANA has created the "PPSTP Version Number Registry". Values are integers in the range 0-255, with initial assignments and reservations given in Table 2. New PPSTP version types are assigned after IETF Review [RFC5226] to ensure that proper documentation regarding the new version types and their usage has been provided.
IANA已创建“PPSTP版本号注册表”。值是0-255范围内的整数，表2中给出了初始赋值和保留。在IETF审查[RFC5226]后分配新的PPSTP版本类型，以确保提供了关于新版本类型及其使用的适当文档。
IANA has created the "PPSTP Request Type Registry". Values are strings listed in Table 8. New PPSTP request types are assigned after IETF Review [RFC5226] to ensure that proper documentation regarding the new request types and their usage has been provided.
IANA已经创建了“PPSTP请求类型注册表”。值是表8中列出的字符串。新的PPSTP请求类型在IETF审查[RFC5226]后分配，以确保提供了关于新请求类型及其使用的适当文件。
+----------------------+-------------------------------------------+
| request_type | Description |
+----------------------+-------------------------------------------+
| "CONNECT" | Returns information about the successful |
| | registration of the peer and/or of each |
| | swarm action requested. May additionally |
| | return the list of peers corresponding to |
| | the action attribute |
| | requested. |
| | |
| "FIND" | Returns the list of peers corresponding |
| | to the requested scope. |
| | |
| "STAT_REPORT" | Confirms the success of the requested |
| | operation. |
+----------------------+-------------------------------------------+
+----------------------+-------------------------------------------+
| request_type | Description |
+----------------------+-------------------------------------------+
| "CONNECT" | Returns information about the successful |
| | registration of the peer and/or of each |
| | swarm action requested. May additionally |
| | return the list of peers corresponding to |
| | the action attribute |
| | requested. |
| | |
| "FIND" | Returns the list of peers corresponding |
| | to the requested scope. |
| | |
| "STAT_REPORT" | Confirms the success of the requested |
| | operation. |
+----------------------+-------------------------------------------+
Table 8: The PPSTP Request Type Registry
表8:PPSTP请求类型注册表
IANA has created the "PPSTP Error Code Registry". Values are the strings listed in Table 9. New PPSTP error codes are assigned after IETF Review [RFC5226] to ensure that proper documentation regarding the new error codes and their usage has been provided.
IANA已创建“PPSTP错误代码注册表”。值是表9中列出的字符串。新的PPSTP错误代码在IETF审查[RFC5226]后分配，以确保提供了关于新错误代码及其使用的适当文件。
+---------------+-------------------------------------------+
| error_code | Description |
+---------------+-------------------------------------------+
| 00 | No Error |
| 01 | Bad Request |
| 02 | Unsupported Version Number |
| 03 | Forbidden Action |
| 04 | Internal Server Error |
| 05 | Service Unavailable |
| 06 | Authentication Required |
+---------------+-------------------------------------------+
+---------------+-------------------------------------------+
| error_code | Description |
+---------------+-------------------------------------------+
| 00 | No Error |
| 01 | Bad Request |
| 02 | Unsupported Version Number |
| 03 | Forbidden Action |
| 04 | Internal Server Error |
| 05 | Service Unavailable |
| 06 | Authentication Required |
+---------------+-------------------------------------------+
Table 9: The PPSTP Error Code Registry
表9:PPSTP错误代码注册表
[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>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC 2818，DOI 10.17487/RFC2818，2000年5月<http://www.rfc-editor.org/info/rfc2818>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，DOI 10.17487/RFC3629，2003年11月<http://www.rfc-editor.org/info/rfc3629>.
[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，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<http://www.rfc-editor.org/info/rfc3986>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, <http://www.rfc-editor.org/info/rfc5245>.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 5245，DOI 10.17487/RFC5245，2010年4月<http://www.rfc-editor.org/info/rfc5245>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[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>.
[RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem for the Simple Network Management Protocol (SNMP)", STD 78, RFC 5590, DOI 10.17487/RFC5590, June 2009, <http://www.rfc-editor.org/info/rfc5590>.
[RFC5590]Harrington，D.和J.Schoenwaeld，“简单网络管理协议（SNMP）的传输子系统”，STD 78，RFC 5590，DOI 10.17487/RFC5590，2009年6月<http://www.rfc-editor.org/info/rfc5590>.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, DOI 10.17487/RFC5766, April 2010, <http://www.rfc-editor.org/info/rfc5766>.
[RFC5766]Mahy，R.，Matthews，P.，和J.Rosenberg，“使用NAT周围的中继进行遍历（TURN）：NAT（STUN）会话遍历实用程序的中继扩展”，RFC 5766，DOI 10.17487/RFC5766，2010年4月<http://www.rfc-editor.org/info/rfc5766>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, <http://www.rfc-editor.org/info/rfc5952>.
[RFC5952]Kawamura，S.和M.Kawashima，“IPv6地址文本表示的建议”，RFC 5952，DOI 10.17487/RFC5952，2010年8月<http://www.rfc-editor.org/info/rfc5952>.
[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.，Ed.，Bjorklund，M.，Ed.，Schoenwaeld，J.，Ed.，和A.Bierman，Ed.，“网络配置协议（NETCONF）”，RFC 6241，DOI 10.17487/RFC6241，2011年6月<http://www.rfc-editor.org/info/rfc6241>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <http://www.rfc-editor.org/info/rfc6749>.
[RFC6749]Hardt，D.，Ed.“OAuth 2.0授权框架”，RFC 6749，DOI 10.17487/RFC6749，2012年10月<http://www.rfc-editor.org/info/rfc6749>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7159]Bray，T.，Ed.“JavaScript对象表示法（JSON）数据交换格式”，RFC 7159，DOI 10.17487/RFC7159，2014年3月<http://www.rfc-editor.org/info/rfc7159>.
[RFC7230] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<http://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7231]Fielding，R.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 7231，DOI 10.17487/RFC72312014年6月<http://www.rfc-editor.org/info/rfc7231>.
[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]Alimi，R.，Ed.，Penno，R.，Ed.，Yang，Y.，Ed.，Kiesel，S.，Previdi，S.，Room，W.，Shalunov，S.，和R.Woundy，“应用层流量优化（ALTO）协议”，RFC 7285，DOI 10.17487/RFC7285，2014年9月<http://www.rfc-editor.org/info/rfc7285>.
[RFC7574] Bakker, A., Petrocco, R., and V. Grishchenko, "Peer-to-Peer Streaming Peer Protocol (PPSPP)", RFC 7574, DOI 10.17487/RFC7574, July 2015, <http://www.rfc-editor.org/info/rfc7574>.
[RFC7574]Bakker，A.，Petrocco，R.，和V.Grishchenko，“对等流媒体对等协议（PPSP）”，RFC 7574，DOI 10.17487/RFC7574，2015年7月<http://www.rfc-editor.org/info/rfc7574>.
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, <http://www.rfc-editor.org/info/rfc7616>.
[RFC7616]Shekh Yusef，R.，Ed.，Ahrens，D.，和S.Bremer，“HTTP摘要访问认证”，RFC 7616，DOI 10.17487/RFC76162015年9月<http://www.rfc-editor.org/info/rfc7616>.
[Contracts] Piatek, M., Krishnamurthy, A., Venkataramani, A., Yang, R., Zhang, D., and A. Jaffe, "Contracts: Practical Contribution Incentives for P2P Live Streaming", NSDI: USENIX Symposium on Networked Systems Design and Implementation, April 2010.
[合同]Piatek，M.，Krishnamurthy，A.，Venkataramani，A.，Yang，R.，Zhang，D.，和A.Jaffe，“合同：P2P直播的实际贡献激励”，NSDI:USENIX网络系统设计和实施研讨会，2010年4月。
[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]Kalbflesch，C.，Krupczak，C.，Presohn，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，“主机资源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，“会计管理导论”，RFC 2975，DOI 10.17487/RFC2975，2000年10月<http://www.rfc-editor.org/info/rfc2975>.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, DOI 10.17487/RFC3410, December 2002, <http://www.rfc-editor.org/info/rfc3410>.
[RFC3410]Case，J.，Mundy，R.，Partain，D.，和B.Stewart，“互联网标准管理框架的介绍和适用性声明”，RFC 3410，DOI 10.17487/RFC3410，2002年12月<http://www.rfc-editor.org/info/rfc3410>.
[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>.
[RFC4022] Raghunarayan, R., Ed., "Management Information Base for the Transmission Control Protocol (TCP)", RFC 4022, DOI 10.17487/RFC4022, March 2005, <http://www.rfc-editor.org/info/rfc4022>.
[RFC4022]Raghunarayan，R.，Ed.“传输控制协议（TCP）的管理信息库”，RFC 4022，DOI 10.17487/RFC4022，2005年3月<http://www.rfc-editor.org/info/rfc4022>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <http://www.rfc-editor.org/info/rfc4122>.
[RFC4122]Leach，P.，Mealling，M.和R.Salz，“通用唯一标识符（UUID）URN名称空间”，RFC 4122，DOI 10.17487/RFC4122，2005年7月<http://www.rfc-editor.org/info/rfc4122>.
[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，“运输性能指标MIB”，RFC 4150，DOI 10.17487/RFC4150，2005年8月<http://www.rfc-editor.org/info/rfc4150>.
[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，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, DOI 10.17487/RFC5424, March 2009, <http://www.rfc-editor.org/info/rfc5424>.
[RFC5424]Gerhards，R.，“系统日志协议”，RFC 5424DOI 10.17487/RFC54242009年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]Harrington，D.，“考虑新协议和协议扩展的操作和管理指南”，RFC 5706，DOI 10.17487/RFC5706，2009年11月<http://www.rfc-editor.org/info/rfc5706>.
[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，“点对点流协议（PPSP）的问题陈述和要求”，RFC 6972，DOI 10.17487/RFC6972，2013年7月<http://www.rfc-editor.org/info/rfc6972>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015年5月<http://www.rfc-editor.org/info/rfc7525>.
[SARACEN] Sarecen P2P, <http://www.saracen-p2p.eu/>.
[SARACEN]Sarecen P2P<http://www.saracen-p2p.eu/>.
Acknowledgments
致谢
The authors appreciate the contributions made by Yingjie Gu in the early stages of the specification. Also, they thank the following people for their help and comments: Zhang Yunfei, Liao Hongluan, Roni Even, Dave Cottlehuber, Bhumip Khasnabish, Wu Yichuan, Peng Jin, Chi Jing, Zong Ning, Song Haibin, Chen Wei, Zhijia Chen, Christian Schmidt, Lars Eggert, David Harrington, Henning Schulzrinne, Kangheng Wu, Martin Stiemerling, Jianyin Zhang, Johan Pouwelse, Riccardo Petrocco, and Arno Bakker.
作者赞赏Gu Yingjie在规范早期阶段所做的贡献。此外，他们还感谢以下人士的帮助和评论：张云飞、廖宏銮、罗尼·埃文、戴夫·科特勒胡伯、普密普·哈斯纳比什、吴一川、彭进、池静、宗宁、宋海滨、陈伟、陈志嘉、克里斯蒂安·施密特、拉尔斯·艾格特、大卫·哈林顿、亨宁·舒尔兹林纳、吴康恒、马丁·斯蒂默林、张建音、，约翰·普韦尔斯、里卡多·彼得罗科和阿诺·巴克。
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 SARACEN project [SARACEN], the European Commission, Huawei, or China Mobile.
本文包含的观点和结论是作者的观点和结论，不应被解释为代表SARACEN项目[SARACEN]、欧盟委员会、华为或中国移动的官方政策或支持，无论明示或暗示。
Authors' Addresses
作者地址
Rui Santos Cruz
IST/INESC-ID/INOV
Phone: +351.939060939
Email: rui.cruz@ieee.org
Rui Santos Cruz
IST/INESC-ID/INOV
Phone: +351.939060939
Email: rui.cruz@ieee.org
Mario Serafim Nunes IST/INESC-ID/INOV Rua Alves Redol, n.9 1000-029 Lisboa Portugal Phone: +351.213100256 Email: mario.nunes@inov.pt
Mario Serafim Nunes IST/INESC-ID/INOV Rua Alves Redol，n.9 1000-029葡萄牙里斯本电话：+351.21310256电子邮件：Mario。nunes@inov.pt
Jinwei Xia Huawei Nanjing, Baixia District 210001 China Phone: +86-025-86622310 Email: xiajinwei@huawei.com
南京市白下区华为金威夏210001中国电话：+86-025-86622310电子邮件：xiajinwei@huawei.com
Rachel Huang (editor) Huawei Email: rachel.huang@huawei.com
黄瑞秋（编辑）华为电子邮箱：瑞秋。huang@huawei.com
Joao P. Taveira IST/INOV Email: joao.silva@inov.pt
Joao P.Taveira IST/INOV电子邮件：Joao。silva@inov.pt
Deng Lingli China Mobile Email: denglingli@chinamobile.com
邓玲莉中国移动邮箱：denglingli@chinamobile.com