RTMP协议中未公开的类型为0x1F(31)的ping

众所周知，adobe的RTMP的ping类型公开的类型为（0～7），被人破解的有0x1A和0x1B类型分别是swfverification服务器端请求和客户端回应。

但是今天我在调试rtmpdump时收到了类型为0x1F
ping，并且在收到此ping后数据立即断掉，再也没有任何数据。
452.549 KB (20.8%)
DEBUG: RTMP_LIB::CRTMP::HandlePing, received ping. type: 31, len: 6
00 1F 00 00 00 01

ERROR: RTMP_LIB::CRTMP::ReadN, RTMP recv error 998

ERROR: RTMP_LIB::CRTMP::ReadPacket, failed to read RTMP packet header

DEBUG: zero read!

WARNING: Download may be incomplete (downloaded about 20.8%), try --resume!
Closing connection... done!

 

在网上找了半个上午，也有一个人是遇到了此种类型的ping，但是没有找到解决办法。

我回想一下，昨天无论是在RTMP还是在RTMPE的下载测试中都没有遇到此ping，那么就是一些语句出了问题，使用排除法，发现如果不向服务器发送ping类型为3(设置缓冲区)的消息时到一定时间后就会出现此ping，那么我推测此ping是由于服务器端认为发送的数据已经超过客户端的缓冲区了，就向客户端提出警告，如果得不到回应就断掉数据。

 

然后我屏蔽掉ping类开为3的消息发送代码，在处理ping类型为0x1F的消息时，再次发送设置buffer的消息，这样下载流程就正常了，嘿嘿，俺也破解了rtmp的一小小部分。不过只是推测，没有严格验证仅供参考。

 

2010/3/8 追加：

项目代码成熟后我发现，这个ping跟bufferlength消息没有必然的联系，因为我在多次下载中还是接收到这个消息，但是我没有继续设置bufferLength，结果下载也是正常的。