Results 1 to 9 of 9

Thread: onDisconnect sould not be fired if the client connection rejected.

  1. #1

    Default onDisconnect sould not be fired if the client connection rejected.

    Isn't there a missing piece of logic to firing onDisconnect event when clients rejected from server? I accept clients if their authentication succeed, so if I accept a client, then it's a user anymore for my application. For example; every user has a 'level' property for sure and I implement some blocks in 'onDisconnect', thinking of that client has already accepted and became a user and it has a 'level' property for sure. If it was an invalid user, it should have been rejected from the server at the beginning and should not have been 'connected' to the application.

  2. #2
    Join Date
    Dec 2007
    Posts
    22,013

    Default

    I'm not sure if I understand. If you use onConnect handler to do client.rejectConnection() I don't think onDisconnect will ever fire for that client. If you allow a client connection, then sometime later do client.setShutdownClient(true), then onDisconnect should fire.

    Richard

  3. #3

    Default

    Quote Originally Posted by rrlanham View Post
    I'm not sure if I understand. If you use onConnect handler to do client.rejectConnection() I don't think onDisconnect will ever fire for that client. If you allow a client connection, then sometime later do client.setShutdownClient(true), then onDisconnect should fire.

    Richard

    This is how my code and output looks like. Is it something that I'm missing about settings?

    public void onConnect(IClient client, RequestFunction function, AMFDataList params)
    {
      client.rejectConnection();
    }
    .
    .
    public void onConnectReject(IClient client)
    {
      System.out.println("---- RJ ----");
    }
    .
    .
    public void onDisconnect(IClient user)
    {
      System.out.println("---- DC ----");
    }

    INFO session connect 127.0.0.1 -
    ---- RJ ----
    INFO session disconnect 856568361 -
    ---- DC ----

  4. #4
    Join Date
    Dec 2007
    Posts
    22,013

    Default

    It works for me. I tested this:
    package test;
    
    import com.wowza.wms.amf.*;
    import com.wowza.wms.client.*;
    import com.wowza.wms.module.*;
    import com.wowza.wms.request.*;
    
    public class ModuleTestRejectFlow extends ModuleBase {
    
    	public void onConnect(IClient client, RequestFunction function,
    			AMFDataList params) {
    		client.rejectConnection();
    		getLogger().info("onConnect: " + client.getClientId());
    	}
    
    	public void onConnectReject(IClient client) {
    		getLogger().info("onConnectReject: " + client.getClientId());
    	}
    
    	public void onDisconnect(IClient client) {
    		getLogger().info("onDisconnect: " + client.getClientId());
    	}
    
    }
    I added the module to /conf/vod/Application.xml, started Wowza, then played sample.mp4 in SimpleVideoStreaming. The log output was:

    INFO session connect-pending 0:0:0:0:0:0:0:1 -
    INFO server comment - onConnect: 1096280867
    INFO session connect 0:0:0:0:0:0:0:1 -
    INFO server comment - onConnectReject: 1096280867
    INFO session disconnect 1096280867 -
    INFO server comment - onDisconnect: 1096280867
    Richard

  5. #5

    Default

    INFO server comment - onDisconnect: 1096280867
    That's what I meant. Client rejected, so only 'onConnectReject' should fired right? But 'onDisconnect' method also fired even though client has been rejected by server. Shouldn't 'onDisconnect' method be fired only for clients that are accepted by server?

  6. #6

    Default

    iriscay,

    Are you calling rejectConnection() yourself? The API says not to do this. It looks like onConnectReject() fires for only a few things such as license/count limits. I'm curious to know if you've integrated rejectConnection() with your authentication...

    Regarding your question of when onDisconnect should fire, think of it like this: If onConnect has fired, then onDisconnect will fire.

  7. #7
    Join Date
    Dec 2007
    Posts
    22,013

    Default

    That is how it works. Why is it a problem?

    Does this help?
    package test;
    
    import com.wowza.wms.amf.*;
    import com.wowza.wms.client.*;
    import com.wowza.wms.module.*;
    import com.wowza.wms.request.*;
    
    public class ModuleTestRejectFlow extends ModuleBase {
    
    	public void onConnect(IClient client, RequestFunction function,
    			AMFDataList params) {
    		client.rejectConnection();
    		client.getProperties().setProperty("rejected", true);
    		
    		getLogger().info("onConnect: " + client.getClientId());
    	}
    
    	public void onConnectReject(IClient client) {
    		getLogger().info("onConnectReject: " + client.getClientId());
    	}
    
    	public void onDisconnect(IClient client) {
    		
    		Boolean isRejected = client.getProperties().getPropertyBoolean("rejected", false);
    
    // you can handle client that was rejected differently
    		
    		getLogger().info("onDisconnect: " + client.getClientId());
    	}
    
    }
    Richard

  8. #8

    Default

    Quote Originally Posted by randall View Post
    iriscay,

    Are you calling rejectConnection() yourself? The API says not to do this. It looks like onConnectReject() fires for only a few things such as license/count limits. I'm curious to know if you've integrated rejectConnection() with your authentication...

    Regarding your question of when onDisconnect should fire, think of it like this: If onConnect has fired, then onDisconnect will fire.
    I put an authentication layer between onConnect event and client accept method. Depending on that class's response I can reject connections with a reason. Is it a bad practice in Wowza?

    Quote Originally Posted by rrlanham View Post
    That is how it works. Why is it a problem?

    Does this help?
    package test;
    
    import com.wowza.wms.amf.*;
    import com.wowza.wms.client.*;
    import com.wowza.wms.module.*;
    import com.wowza.wms.request.*;
    
    public class ModuleTestRejectFlow extends ModuleBase {
    
    	public void onConnect(IClient client, RequestFunction function,
    			AMFDataList params) {
    		client.rejectConnection();
    		client.getProperties().setProperty("rejected", true);
    		
    		getLogger().info("onConnect: " + client.getClientId());
    	}
    
    	public void onConnectReject(IClient client) {
    		getLogger().info("onConnectReject: " + client.getClientId());
    	}
    
    	public void onDisconnect(IClient client) {
    		
    		Boolean isRejected = client.getProperties().getPropertyBoolean("rejected", false);
    
    // you can handle client that was rejected differently
    		
    		getLogger().info("onDisconnect: " + client.getClientId());
    	}
    
    }
    Richard
    Right now I'm handling the situation in the same way. I've recently moved from FMS to Wowza and that was how it work in FMS. Putting FMS aside, I think it makes sense to having such a flexible control over connections. Due to my former works it's easier for me to think accept-reject phase as something like 'Login Server' which clients yet to authenticated and afterwards it's a 'Game Server' which clients has became physical users. So, from my perspective, when client rejected, 'onConnectReject' should be triggered and 'onDisconnect' should be triggered if client accepted. I'm not writing a game server and it's not actually a big deal but still it feels kinda wrong.
    Last edited by iriscay; 08-01-2012 at 01:57 PM.

  9. #9
    Join Date
    Dec 2007
    Posts
    22,013

    Default

    Well, it is the way it works, there is almost no chance that this is going to change.

    Richard

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •