search

OpenRTMFP / Cumulus

CumulusServer is a complete open source and cross-platform RTMFP server extensible by way of scripting
http://groups.google.com/group/openrtmfp-cumulus
GNU General Public License v3.0
593 stars 221 forks source link

keepAliveServer message #96

Closed mikefrank closed 11 years ago

mikefrank commented 11 years ago

Setting the keepAliveServer parameter to 180 doesn't seem to work since the client still sends the messages to the server every few other seconds, and server keep responding to it. The Cumulus server was restarted after making changes to the CumulusServer.ini file to make sure the settings are pickup. Below is the content of the CumulusServer.ini file:

;CumulusServer.ini port = 1935 udpBufferSize = 114688 keepAlivePeer = 180 keepAliveServer = 180

Another issue is sometimes the server thinks the client failed to send the keep alive message although the client keep sending to it. Below is from the Cumulus server log:

15/12 05:30:25.9 WARN RTMFPServer(3067747184) Server.cpp[150] Client failed : Timeout keepalive attempts 15/12 05:30:43.9 INFO RTMFPServer(3067747184) Sessions.cpp[106] 0 clients 15/12 06:20:44.1 INFO RTMFPServer(3067747184) Sessions.cpp[106] 1 clients 15/12 06:21:12.1 INFO RTMFPServer(3067747184) Sessions.cpp[106] 0 clients 15/12 06:21:14.1 INFO RTMFPServer(3067747184) Sessions.cpp[106] 1 clients 15/12 06:23:37.6 WARN RTMFPServer(3067747184) Server.cpp[150] Client failed : failed on client side

The seems to be quite different in how it handles the keepalive message. If we connect to the Adobe's Cirrus server the flahs player client sends two messages to the server at startup and the server never response to it, and this seems to work fine because our p2p session was able chat to each other. Below is the trace from the network sniffer show what client was sending to the Cirrus server:

0x0000 00 26 5A B0 EB A4 00 24-21 60 FB 27 08 00 45 00 .&Z°ë¤.$!û'..E. 0x0010 00 60 D1 EF 00 00 80 11-1A D1 C0 A8 00 65 32 39 .Ñï..€..ÑÀ¨.e29 0x0020 5A 86 08 A3 07 8F 00 4C-4A DF 48 AE 17 7B 94 27 Z†.£..LJßH®.{”' 0x0030 D3 5C DC 89 C4 27 B3 56-E0 12 E6 C5 1A FB FA 2F Ó\܉Ä'³Và.æÅ.ûú/ 0x0040 09 08 B2 99 5A 20 2B 51-0E F2 B8 48 70 10 54 AC ..²™Z +Q.ò¸Hp.T¬ 0x0050 6B 68 B8 39 DF B6 CA 2C-80 82 65 DE 78 32 3B 55 kh¸9߶Ê,€‚eÞx2;U 0x0060 C5 E0 15 C7 07 98 B8 5E-76 CB 0F A1 08 3A Åà.Ç.˜¸^vË.¡.:

image

Can we just disable the keepAliveServer message so client doesn't have to keep sending it to the server? And why is the server thinks the client was sending the keepAliveServer message although it was keep sending to it.

Thanks! -Mike

cumulusdev commented 11 years ago

Hi Mike,

Keepalive server message is mandatory to allow "UDP hole punching" exploit, and Cirrus does exactly the same thing. I guess you to read this post of Michael Thornburgh (the developper of RTMFP): http://forums.adobe.com/thread/638240

Here he says even that they have decreased its default value, to get more keepalive messages. By this way, to convince you, here a dump session of the "keepalive server" message on a "cirrus" session (in using /cirrus and /dump Cumulus starting options):

   Request from 127.0.0.1:4458
   0D B5 8C C8 5E 01 00 00 FF FF FF FF FF FF        .Áî╚^...      
   Response to 127.0.0.1:4458
   4E C8 8D B5 8C 41 00 00                          N╚ìÁîA..

And as expected, it's sent every 15 sec (same default value that in my server).

Then, I have checked that if when I change this value in my server, the peer uses the new value, I have configured a value of 180 second (instead of the value of 15 sec), and it works as expected, nothing happen before 180 sec.

So beware with your "scanning" tool, it seems that they mislead yourself ;-)