DanisHack / rtmplite

Automatically exported from code.google.com/p/rtmplite
0 stars 0 forks source link

StreamID switches randomly and breaks existing streaming #14

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
First reported by Gabor Janak <g.janak@addoma.de> on Jun 25, 2010.

> Hello,
>
> I'm experimenting with your rtmplite component. And notice a little
> Problem. Is this known ?
>
> I connect to a svn  rtmlite server from a Flash Applet
> 1 netconnection.
> 2 NetStreams - server assigns streamId 1 and streamdid2
>
> now i start rtmpclient  file.flv  rtmp://url/app?id=test
>
> it call createstream, and server assigns streamId=1
>
> after some seconds a weired happen.
>
> the server thinks, it get an Message from the rtmpclient
> with streamId=2 .... Ough ?
> now an assert throws.. because server don't know this streamId in this
> Client Instance.
>
> I'm currently debugging the rtmp.py and try to add debug code
> but i could not find where the streamId changes...
>
> If the server is started, without connected the doublestream Applet ...
> the error doesn't happen.
>
> If the double-stream client is disconnected... the error doesn't happen.
>
>
> Can you give me a Hint where to search ?
>
>
> Thanks in advantage...
>
> Bye
> Gabor

---

Hello again,

i found my Failure. I used a flv file which i recorded with the rtmpClient.
I don't know why,but at the beginning of the file a TextData Message is
written.

hexdump a.flv -C -n 100
00000000  46 4c 56 01 05 00 00 00  09 00 00 00 00 09 00 00
|FLV.............|
00000010  1d 00 09 cd 00 00 00 00  02 00 0d 73 74 61 74 75
|...........statu|
00000020  73 4d 65 73 73 61 67 65  02 00 0a 57 65 6c 63 6f
|sMessage...Welco|
00000030  6d 65 2e 2e 2e 00 00 00  28 09 00 07 ca 00 13 9a
|me......(.......|
00000040  00 00 00 00 12 00 00 84  02 82 a6 20 20 20 21 ff  |...........
 !.|
00000050  ff 31 01 01 01 0f ff f9  88 08 08 08 7f ff cc 40
|.1.............@|
00000060  40 40 43 ff                                       |@@C.|
00000064

sended by NetStream.send("statusMessage","Welcome...");
it seems the rtmpclient wrote this Message into the FLV,
and now the old streamID 0x02 is inserted into the new Stream...

I will patch the rtmpClient, that this type of messages arn't written
into the flv :) or is this behavior planned ?

Bye

Gabor

---
> Hello,
>
> sorry, but this is the Last Email.
>
> I send you a small fix.
>
> the Problem is, that you cache the header in lastReadHeader
> by reference. and this Reference is in the message,too.
> if this Message is send over a stream, the stream send function
> calls msg.streamId=self.id (streamId)
> this changes the streamId of the cached Header ...
> and if the next message is not type0 it use the wrong streamId
>
> solution:
> @@ -523,7 +530,13 @@
>         '''Method to send a Message or Command on this stream.'''
>         if isinstance(msg, Command):
>             msg = msg.toMessage()
> -        msg.streamId = self.id
> +        if msg.streamId != self.id:
> +               #make a copy of the message, changing the orginal       +
>           #messages is BAD, because it can hold
> +               #a reference to a cached header
> +               old_msg=msg
> +               msg=copy.deepcopy(old_msg)
> +               msg.streamId = self.id
>         # if _debug: print self,'send'
>         if self.client is not None: self.client.writeMessage(msg)
>
> Attached a patch...
>
> I hope this helps.
>
> Thanks.
>

---
Hey,

Thanks a lot for identifying the problem. We will add your suggestion
to the SVN code soon.

Original issue reported on code.google.com by voiprese...@gmail.com on 4 Feb 2011 at 11:35

GoogleCodeExporter commented 9 years ago
Hi Gabor,

Thanks for the fix.

Can you please check if the fix in SVN r22 will work for you?
Basically it uses a copy of Header when dispatching the incoming
message event, so that changing the header will not affect the
lastReadHeader values. This is different than your patch which uses a
copy during the Stream.send() function. But I think using a copy
initially itself is more safe and clean.

I am also attaching the diff here. Thanks again and please let us know
when you get time if your problem is solved with this patch.

--- rtmp.py     (revision 21)
+++ rtmp.py     (working copy)
@@ -279,7 +279,9 @@
                else:
                    # if _debug: print 'Protocol.parseMessage updated
old incomplete'
                    data, self.incompletePackets[channel] =
data[:header.size], data[header.size:]
-                msg = Message(header, data)
+
+                hdr = Header(header.channel, header.time,
header.size, header.type, header.streamId)
+                msg = Message(hdr, data)
                if _debug: print 'Protocol.parseMessage msg=', msg
                try:
                    if channel == Protocol.PROTOCOL_CHANNEL_ID:

---

Hi,

I have changed it after this email in a similar way.
Only a short note: please watch at lastWriteHeader, too.
There is the same :)

I will check the subversion patch and notice you. :)

Bye

Original comment by voiprese...@gmail.com on 4 Feb 2011 at 11:36