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,结果下载也是正常的。

 

你可能感兴趣的:(ping)