The diagram shown above is an abstract representation of how a connection flows through Red5 core. On connection attempt, Red5 verifies the basic protocol specific handshake as per the connection type (RTMP/RTSP/WebRTC).
Once the handshake is verified Red5 pro translates the connection to a registered Red5 pro connection and sets a reference to it using the static method – Red5.setConnectionLocal(IConnection) in the context of the current thread.
It is very important to understand the context of the term current thread in a Red5 pro application.
If another client tries to connect to the server, it generated a new thread in Red5 core and thus Red5.setConnectionLocal(IConnection) is storing the new connection’s reference in a different thread.
Now once the connection is connected to the application scope, it can generate application events, stream events etc: which can be captured from within the application adapter (MultiThreadedApplicationAdapter) or using callback handlers such as the IApplication interface.
Now if you wish you gain access to the current IConnection object which is responsible for those events, you can use the Red5 class’s static method -> Red5.getConnectionLocal(). This method will automatically return the IConnection object associated with the event callback within which you execute the method.
Here it is necessary to understand the complexity and the need for this method. Java is multithreaded by nature. The main application class extends the MultiThreadedApplicationAdapter class. Each connection to the application actually interacts with the same application class. So if you imagine about 1000 connections interacting with the application at the same time, how do you know which connection is causing a specific event in the application? – That’s what the Red5.getConnectionLocal() does.
Example 1: – Who is broadcasting the stream?
The code example below shows how we can gain access to the broadcaster connection object within the application adapter’s streamBroadcastStart & streamBroadcastClose methods. You will notice that both methods dont pass in the IConnection object responsible for the broadcast start and stop callbacks. However the Red5.getConnectionLocal() method manages to get us the correct IConnection reference.
public void streamBroadcastClose(IBroadcastStream arg0) {
IConnection broadcaster = Red5.getConnectionLocal();
log.info("Connection {}", broadcaster);
}
@Override
public void streamBroadcastStart(IBroadcastStream stream) {
IConnection broadcaster = Red5.getConnectionLocal();
log.info("Connection {}", broadcaster);
}
Example 2: – Who is subscribing to the stream?
The code example below shows how we can gain access to the subscriber connection object within the application adapter’s streamSubscriberStart & streamSubscriberClose methods. You will notice that both methods do not pass in the IConnection object responsible for the subscribe start and stop callbacks. However the Red5.getConnectionLocal() method once again manages to get us the correct IConnection reference.
public void streamSubscriberClose(ISubscriberStream stream) {
IConnection subscriber = Red5.getConnectionLocal();
log.info("Connection {}", subscriber);
}
@Override
public void streamSubscriberStart(ISubscriberStream stream) {
IConnection subscriber = Red5.getConnectionLocal();
log.info("Connection {}", subscriber);
}
Conclusion:
The Red5.getConnectionLocal() can be universally used in Red5 Pro application as well as plugins to access the current connection object with respect to the executing thread accurately at any given time.
