I'm using the version built from the last repository version (1.0.0.17) on
Windows 2008 Server machine.
As you know both tunneled and non tunneled RTMP communication goes through
RtmpServerConnection. All is fine if non tunneled protocol is used. However
problems begin if the tunneled protocol is used. The RtmpServerConnection hands
the request over to the RtmptEndpoint, which in turn hands it over to
RtmptServer, which then creates an RtmptConnection. The problem lies in the
fact that the RtmpServerConnection is totally unaware of what's going on with
RtmptConnection.
For example the RtmptConnection may receive a "close" command and will close
itself. This however doesn't close the RtmpServerConnection.
I did some testing on Flex client and discovered that it doesn't close it's
connection to the server even after it has issued an Unsubscribe or "close"
command. The result is that the server may keep the connection open even after
the client has been unsubscribed.
Here's how this can be reproduced:
1) create an RTMPT endpoint in the FluorineFX (I created a MSMQ destination)
2) create a Flex client (a Consumer) and set it up to resubscribe automatically
if the connection is dropped. Have the client connect to the destination from
the 1. step
3) start the web application (i.e. open up FluorineFX console)
4) open the Flex client and make it connect to the endpoint
5) open up IIS console and recycle the application pool in which the FluorineFX
sits
6) quickly reload the FluorineFX console so that the web application starts
again
7) use the process explorer to check the number of connections opened by the
client - it should be 2
This might not work at first - you may need to repeat steps 5-7 a few times
before more than one connections are opened by the client.
The first instance of the connection has been established due to the fact that
the client tries to reconnect - probably an Idle command was sent. The server
has replied with a "wrong client ID" message, so client opens up a new
connection. However it doesn't close the old one. Since the
RtmpServerConnection is unaware of what just happened in the RtmptConnection -
it does nothing.
The second connection is a valid one.
To solve this I changed the RtmpServer.Service method so that it returns a
boolean value indicating if the RtmpServerConnection should close the
connection or not. I have attached both of the files. In addition to the
described fixes they contain also some other changes (ie. performance counters)
Original issue reported on code.google.com by nikola.d...@gmail.com on 25 Aug 2010 at 12:31
Original issue reported on code.google.com by
nikola.d...@gmail.comon 25 Aug 2010 at 12:31Attachments: