[Red5] RTMPT caveats?

Tyler Kocheran rfkrocktk at gmail.com
Mon Feb 23 21:17:23 PST 2009 

Yeah, give 'er a run on the latest trunk. I remember reading something a few
days back about how RTMPT connections won't be able to use SharedObjects,
but that was about Flash Media Server in a book that's from 2004. Hopefully
that's not the case with Red5 :)
I'm fairly certain that what you're trying to do will work. There were a few
SharedObject related fixes between RC1 and RC2, and there are probably more
that are happening right now.

And if not, there are always workarounds to recommend!

On Mon, Feb 23, 2009 at 8:52 PM, Christopher Walzl <cwalzl at gmail.com> wrote:

> Yeah, you're right.  I had always been getting those when using regular
> RTMP as well - I just hadn't noticed them.  They don't appear to have any
> effect on the app.
> No luck yet - adding the parameters that you pasted from Paul's e-mail
> didn't seem to have any effect(same behavior, with or without them). I think
> it may have something to do with my bad Red5 hack/fix to get AMF3 sorta
> working with shared object method invocations. As I said before, everything
> works fine under regular RTMP.  Under RTMPT, clients can join fine, and can
> communicate properly with a SharedObject that transmits nothing but String
> objects. However, when I throw a SharedObject into the mix that deals with
> AMF ByteArray objects, that's when things stop working(clients connected
> with regular RTMP continue to work fine).  Something bad happens as soon as
> that ByteArray is pushed onto the SharedObject(via a method invocation), so
> bad in fact, that all of the clients listening to that SharedObject over
> RTMPT are disconnected!
>
> I just tried my application with RC2(currently running RC1), but that
> version still has the following issue with AMF3 ByteArray's:
>
> "[ERROR] [pool-4-thread-15]
> org.red5.server.net.rtmp.codec.RTMPProtocolEncoder - Error encoding
> object: java.lang.RuntimeException: ByteArray objects not supported with
> AMF0"  - (yes, AMF3 is specified :-))
>
> I'm going to try running my application on the 0.8.0 trunk, and see if that
> makes any difference.  Here's hoping! :-)
>
> Chris Walzl
> cwalzl at gmail.com
> (972) 974-6728
>
> Sent from my MacBook Pro
>
> On Feb 23, 2009, at 10:31 PM, Tyler Kocheran wrote:
>
> Any luck on this, Chris?
> I get Bean lookup failures sometimes, but it's usually not an exception,
> just a warning. And for some reason, mine are caused by beans I didn't
> define... which is weird.
>
> On Mon, Feb 23, 2009 at 2:21 PM, Christopher Walzl <cwalzl at gmail.com>wrote:
>
>> Apparently something is failing in the 'http-8088-exec-#' thread.  It says
>> "org.red5.server.Context - Bean lookup failed for
>> customSharedObject_so_3..soservice in the application context".
>> It appears this is the reason the data isn't being sent out to the clients
>> connected via RTMPT!  At least I have some sort of clue! :-)
>>
>> Chris Walzl
>> cwalzl at gmail.com
>> (972) 974-6728
>>
>> Sent from my MacBook Pro
>>
>> On Feb 23, 2009, at 1:46 PM, Tyler Kocheran wrote:
>>
>> Oh, and you can't run RTMPT on port 80 if another process is using that
>> port (eg Apache)
>> See the thread here:
>> http://www.nabble.com/Automated-ports-switch-tp21703561p21715580.html
>>
>> On Mon, Feb 23, 2009 at 11:44 AM, Tyler Kocheran <rfkrocktk at gmail.com>wrote:
>>
>>> I think so. Aha! It was sent by Paul, here it is:
>>>
>>>
>>>           <servlet>
>>>  <servlet-name>rtmpt</servlet-name>
>>>  <servlet-class>org.red5.server.net.rtmpt.RTMPTServlet</servlet-class>
>>>  <load-on-startup>1</load-on-startup>
>>>  </servlet>
>>>
>>>   <servlet-mapping>
>>>  <servlet-name>rtmpt</servlet-name>
>>>  <url-pattern>/fcs/*</url-pattern>
>>>  </servlet-mapping>
>>>
>>>  <servlet-mapping>
>>>  <servlet-name>rtmpt</servlet-name>
>>>  <url-pattern>/open/*</url-pattern>
>>>  </servlet-mapping>
>>>
>>>   <servlet-mapping>
>>>  <servlet-name>rtmpt</servlet-name>
>>>   <url-pattern>/close/*</url-pattern>
>>> </servlet-mapping>
>>>
>>>   <servlet-mapping>
>>>  <servlet-name>rtmpt</servlet-name>
>>>  <url-pattern>/send/*</url-pattern>
>>>  </servlet-mapping>
>>>
>>>  <servlet-mapping>
>>>  <servlet-name>rtmpt</servlet-name>
>>>  <url-pattern>/idle/*</url-pattern>
>>>  </servlet-mapping>
>>>
>>> Add it to each application's web.xml file.
>>>
>>> On Mon, Feb 23, 2009 at 11:29 AM, Christopher Walzl <cwalzl at gmail.com>wrote:
>>>
>>>> Cool, thanks Tyler.  I'll check it out.  Yeah, it looks like tunneling
>>>> over HTTP may be our only option for some of our clients.  Some of our
>>>> clients have their firewalls locked down such that only http/port 80 traffic
>>>> can get through to their network.  Others are using proxies which only allow
>>>> HTTP traffic.  The plan is to first try regular RTMP over port 80, and if
>>>> that fails, attempt to connect via RTMPT - performance may not be good, but
>>>> at least they'll be able to connect(hopefully).
>>>> So you need to setup a servlet for each individual Red5 server
>>>> application? I'll try to craft my search a little more carefully this time!
>>>> Thanks again!
>>>>
>>>> Chris Walzl
>>>> cwalzl at gmail.com
>>>> (972) 974-6728
>>>>
>>>> Sent from my MacBook Pro
>>>>
>>>> On Feb 23, 2009, at 1:18 PM, Tyler Kocheran wrote:
>>>>
>>>> I think you have to set up a servlet in your web.xml file. Dominick or
>>>> Paul posted it a while back. Search the list for RTMPT servlet.
>>>> And you understand the concept behind RTMPT right? It's more or less a
>>>> failover mechanism for a connection that doesn't support RTMP directly. It's
>>>> a lot less performant than RTMP as well and I think it uses more server
>>>> memory, I remember reading that in the list a while back.
>>>>
>>>> On Mon, Feb 23, 2009 at 11:09 AM, Christopher Walzl <cwalzl at gmail.com>wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> >From my understanding, Red5 abstracts out the type of connection being
>>>>> used (RTMP, RTMPT etc) from the server application.  So in theory, once I
>>>>> have an application running under Red5 that works with regular RTMP, it
>>>>> should be a matter of the client specifying RTMPT instead of RTMP, and the
>>>>> appropriate port.  Are there any other caveats?  Any other pieces of advice
>>>>> that one needs to know when wanting to support both RTMP and RTMPT?  Does
>>>>> RTMPT support the AMF3 encoding?
>>>>>
>>>>> I'm currently running with Red5 0.8.0 RC1, and the demo applications
>>>>> appear to be working fine with simultaneous RTMP and RTMPT client
>>>>> connections.  However, of course, my application is not working.  It looks
>>>>> like data is being sent to the server fine(via a client talking over RTMPT),
>>>>>  but the clients who are listening on the other end are not receiving the
>>>>> data.  Of course, the application works fine using RTMP.  :-)
>>>>>
>>>>> Sorry for my rambling, but if there are any 'hidden steps', tricks,
>>>>> tips etc when getting an app working with RTMPT, I'm all ears!
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Chris Walzl
>>>>> cwalzl at gmail.com
>>>>> (972) 974-6728
>>>>>
>>>>> Sent from my MacBook Pro
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Red5 mailing list
>>>>> Red5 at osflash.org
>>>>> http://osflash.org/mailman/listinfo/red5_osflash.org
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> And do this, knowing the time, that now it is high time to awake out of
>>>> sleep;
>>>> for now our salvation is nearer than when we first believed.
>>>> _______________________________________________
>>>> Red5 mailing list
>>>> Red5 at osflash.org
>>>> http://osflash.org/mailman/listinfo/red5_osflash.org
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Red5 mailing list
>>>> Red5 at osflash.org
>>>> http://osflash.org/mailman/listinfo/red5_osflash.org
>>>>
>>>>
>>>
>>>
>>> --
>>> And do this, knowing the time, that now it is high time to awake out of
>>> sleep;
>>> for now our salvation is nearer than when we first believed.
>>>
>>
>>
>>
>> --
>> And do this, knowing the time, that now it is high time to awake out of
>> sleep;
>> for now our salvation is nearer than when we first believed.
>> _______________________________________________
>> Red5 mailing list
>> Red5 at osflash.org
>> http://osflash.org/mailman/listinfo/red5_osflash.org
>>
>>
>>
>> _______________________________________________
>> Red5 mailing list
>> Red5 at osflash.org
>> http://osflash.org/mailman/listinfo/red5_osflash.org
>>
>>
>
>
> --
> And do this, knowing the time, that now it is high time to awake out of
> sleep;
> for now our salvation is nearer than when we first believed.r
> _______________________________________________
> Red5 mailing list
> Red5 at osflash.org
> http://osflash.org/mailman/listinfo/red5_osflash.org
>
>
>
> _______________________________________________
> Red5 mailing list
> Red5 at osflash.org
> http://osflash.org/mailman/listinfo/red5_osflash.org
>
>


-- 
And do this, knowing the time, that now it is high time to awake out of
sleep;
for now our salvation is nearer than when we first believed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://osflash.org/pipermail/red5_osflash.org/attachments/20090223/8fd2d2be/attachment-0001.html>

More information about the Red5 mailing list