Wowza Community

Defer accept/reject of RTMP client?

I have a use case where I’d like to make an asynchronous remoting call and receive results before I process RTMP clients. While I’m waiting for the response from the remoting request, I’d like to defer handling of RTMP connections, as I’ll need the data from the remoting call to make logical decisions.

I find that I can store references to the IClient objects in a map, but if I don’t invoke acceptConnection or rejectConnection on a client object in a module’s onConnect method, Wowza will invoke acceptConnection for me (I assume there is a handler in ModuleBase that’s doing this for me).

Is there a way to prevent this behavior, and just leave my IClients in my map until I’m ready to deal with them?




Not sure if it is enough, but you can set the Application.xml /Connections /AutoAccept to “false”


That should work. I think if you set that in a client context it will affect all others, at least till the app is unloaded. So do it in onAppStart


hm, setting AutoConnect to “false” should be all you need. It works in my test.


The only way I can suggest is while loop in onConnect. This kind of thing is not recommended, you know. What about offloading to the client somehow? Validate before netconnection.connect()



There is nothing built-in. I will ask around for ideas…



I brought it up, but can only confirm: there is not a practical way to do this.



You might try IVHost.killClient(clientID) to stop an encoder. I’m not sure, but from what I was reading that might do a better job of disconnecting an FMLE or Wirecast client.


Thanks Richard. I’ll give that a try.

I found the IApplicationInstance.setAcceptConnection() method, but that seems to have no effect. Is that supposed to work as well?

Well, I tried both methods… setting appInstance.setAcceptConnection(false) in my onAppStart, and setting the value in application.xml, but neither seem to work. The client is accepted as soon as the onConnect method returns (the access log confirms)

Any other ideas or input on this one?

Ok… after adding a class that implements IClientNotify, I see that Wowza is actually rejecting the connection, not accepting it. The access log is a little misleading… it logs an entry with an x-event of connect-session.

But, that’s not really the behavior I’m looking for. What I need is to neither accept nor reject the client in the onConnect method. In the onconnect, I need to move the client into a queue and wait for a remoting response before I accept or reject the connection, which I handle in a method invoked after the remoting response comes in.

Yeah… loops or sleep in the onconnect have brought me problems before, especially on busy servers.

Unfortunately, I can’t offload the issue to the client, as I don’t control the encoders (could be any encoder really).

Thanks for looking into it Richard.

I guess I’ll need to go the route of doing a synchronous remoting request in my onAppStart (which has been working fine for me), and then set a timer after the response comes in to let Wowza process the blocked connections before do my result dependent processing. I suppose an alternate solution would be to accept all until I get my data and then drop clients selectively, but that would cause encoders like Wirecast and FMLE to go into their routine of trying to reconnect once a second until the end of time.

If you could add the ability to defer connection processing to the future feature wish list, I’d appreciate it.