Specification of the RTMPT protocol
Overview
This document describes the RTMPT tunneling protocol as implemented by the Red5 Open Source Flash Server. Please note that this document is _not_ an official specification by Macromedia but hopefully helps other people to write software that makes use of RTMPT.
RTMPT basically is a HTTP wrapper around the RTMP protocol that is sent using POST requests from the client to the server. Because of the non-persistent nature of HTTP connections, RTMPT requires the clients to poll for updates periodically in order to get notified about events that are generated by the server or other clients.
During the lifetime of a RTMPT session, four possible request types can be sent to the server which will be described below.
URLs
The URL to be opened has the following form:
http://server//[/]
denotes the RTMPT request type (see below)
specifies the id of the client that performs the requests (only sent for established sessions)
is a consecutive number that seems to be used to detect missing packages
Request / Response
All HTTP requests share some common properties:
* They use HTTP 1.1 POST.
* The content type is application/x-fcs.
* The connection should be kept alive by the client and server to reduce network overhead.
The HTTP responses also share some properties:
* The content type is application/x-fcs.
* For all established sessions the first byte of the response data controls the polling interval of the client where higher values mean less polling requests.
Polling interval
The server always starts with a value of 0×01 after data was returned and increases it after 10 emtpy replies. The maximum delay is 0×21 which causes a delay of approximately 0.5 seconds between two requests.
Red5 currently increases the delay in the following steps: 0×01, 0×03, 0×05, 0×09, 0×11, 0×21.
Initial connect (command “open”)
This is the first request that is sent to the server in order to register a client on the server and start a new session. The server replies with a unique id (usually a number) that is used by the
client for all future requests.
Note: the reply doesn’t contain a value for the polling interval! A successful connect resets the consecutive index that is used in the URLs.
Client updates (command “send”)
The data a client would send to the server using RTMP is simply prefixed with a HTTP header and otherwise sent unmodified.
The server responds with a HTTP response containing one byte controlling the polling interval and the RTMP data if available.
Polling requests (command “idle”)
If the client doesn’t have more data to send to the server, he has to poll for updates to receive streaming data or events like shared objects.
Disconnect of a session (command “close”)
If a client wants to terminate his connection, he sends the “close” command which is replied with a 0×00 by the server.
概述
——–
此文档描述RTMPT通道协议在Red5开源FLASH服务器上的实现。请注意：此文档不是Macromedia官方规范说明书，但是可以帮助人们开始使用RTMPT开发软件。
RTMPT基本上是一个RTMP协议的HTTP包装。它发送POST请求从客户端到服务端。因为HTTP连接是非持久性的，RTMPT需要客户端获得周期性的更新，顺序的得到从服务端或其它客户端产生的事件通告。
在一个RTMPT会话周期，下面描述四个可能会发送到服务端的请求类型。
URLs
—-
URL以以下形式打开：
http://server//[/]
``
指示RTMPT请求类型。
``
指定执行请求的客户端编号(只发送已确定的会话)
``
是一个连续的数字，好象是用于侦测丢失的包。
请求/响应(Request / Response)
——————
所有的HTTP请求共享一些公用属性：
- 使用HTTP 1.1 POST。
- 内容类型为`application/x-fcs`。
- 连接会保持活动，这样客户端和服务端会减少网络开销。
HTTP响应也共享一些属性：
- 内容类型为`application/x-fcs`.
- 所有已确定会话的响应数据的首字节控制客户端检测间隔时间，更高的值表示较少的检测请求。
(译注：polling，检测，可能翻译得不够准确)
检测间隔时间(Polling interval)
—————-
在数据返回后，服务器会以0×01开始，在10次空的回复之后自动增长这个值。最大的延时是0×21，在两次请求之间的延时大约在0.5秒左右。
Red5通常按下列步骤增长延时：
0×01, 0×03, 0×05, 0×09, 0×11, 0×21.
初始化连接(命令”open”)
——————————–
这是首次请求，会顺序的发送到服务器，注册一个客户端并开始一个新的会话。服务器回复一个惟一的ID(通常是一个数字)给客户端，以便于之后的请求。
注意：回复不会包含检测间隔时间值。成功的连接会重设连续索引以用于URL。
客户端更新(命令”send”)
——————————-
从客户端发送到服务器的数据会加一个HTTP头作为RTMP的前缀(译注：即RTMPT)。
如果有效的话，服务器响应以HTTP响应，包含一个字节的控制检测间隔时间和RTMP数据，。
检测请求(命令”idle”)
———————————
如果客户端没有包含更多的数据发送到服务器，他可以检测更新，会收到流数据或事件，例如共享对象。
断开会话连接(命令”close”)
—————————————–
如果客户端希望终止连接，他可以发送close命令到服务器，服务器会回复0×00。