Flow event callback process and considerations for RED5 projects

Callback Process

Reference: Red5 's general client connection trigger sequence for each event, the actual process is verified as follows:

The program starts (will automatically start the app when RED5 starts, triggering the above event)

Start:mychatroom
Appstart:mychatroom

First client connection (Mychatroom/lobby/rooma)

Start:/lobby
Roomstart:/lobby
Start:/lobby/rooma
Roomstart:/lobby/rooma
appconnect:0
Connect
appjoin:0:
roomconnect:0
Connect:/lobby
Roomjoin:0:/lobby
roomconnect:0
Connect:/lobby/rooma
Roomjoin:0:/lobby/rooma

A second client connection

Appconnect:1
Connect
Appjoin:1:
Roomconnect:1
Connect:/lobby
Roomjoin:1:/lobby
Roomconnect:1
Connect:/lobby/rooma
Roomjoin:1:/lobby/rooma

A second client leaves

Roomdisconnect:1
Disconnect:/lobby/rooma
roomleave:1:/lobby/

Rooma roomdisconnect:1
Disconnect:/lobby
Roomleave:1:/lobby

Appdisconnect:1
Disconnect
Appleave:1:

The first client leaves

roomdisconnect:0
Disconnect:/lobby/rooma
Roomleave:0:/lobby/rooma

Stop:/lobby/rooma
Roomstop:/lobby/rooma

roomdisconnect:0
Disconnect:/lobby
Roomleave:0:/lobby

Stop:/lobby
Roomstop:/lobby

Appdisconnect
Disconnect
appleave:0:

Program exit

Stop
Appstop:

Precautions

1. In my first test, the adapter I inherited implemented the three methods of Connect, AppConnect, and Roomconnect. It is found that the program will only call back to connect at any time and will not callback the other two. View the code and comments for connect discover to differentiate between calling Appconnet and Roomconnect, you do not need to implement the Connect function, only the two are sufficient. Otherwise, RED5 only calls connect, and the parameters passed in scope are different.

For disconnect, Appdisconnect, Roomdisconnect.

It is important to stress this point. Because I was using the RED5 Challenge Certification (CRAM) example, I found that when I registered the example in AppStart as listener in my application, the application would not recall the appconnect of the example, which is the solution. The application distributes events to connect instead of AppConnect.

Also, if we change the cram example to connect instead of appconnect, there may be some difference in scope. The code in the example is only executed when the value of scope is app name. Otherwise, the authentication process may be performed more than once. (not verified)

2. The test results in my program differ from the order in which the referenced posts are called on start and AppStart, stop, and Appstop, due to what is not known for the time being. Let's start by recording the following clues:

1. The execution thread is always, such as a log

   [WARN] [red5_scheduler_worker-10] Org.red5.core.application-stop scope name:test
   [WARN] [Red5_scheduler_worker-10] Org.red5.core.application-roomstop

2. The parent Class I inherited was Multithreadapplicationadapter, and the blog I was referring to was using Applicationadapter
3. The version number may not be the same, I use 1.0.5, the other side uses the version unknown, the time to look at its posts should obviously be much earlier than mine.

Flow event callback process and considerations for RED5 projects