Skip to main content
May 19, 2008
Question

Authorize plugin notify, on connection timeout + remote function execution

  • May 19, 2008
  • 9 replies
  • 934 views
When a client application stops the stream I normally get an E_STOP notify. But if a client dies due to network outage or the client computer dies (or something other unforseen that doesnt give a FIN/RST on the TCP connection), then it seems there is no way to get a notification about this..

Or have I missed something?
If not, that is a big feature request for us, and probably other people developing pay-per-view-stuff..

Also, is there some way to catch remote executions? Ie if my client calls a function on my SSAS, can I catch that invocation in my authorize module somehow? (Or in some other way get trigger some code in my plugin, when a client calls a function)

Is there somewhere on the adobe site one can submit feature requests to FMIS?

Thanks!
    This topic has been closed for replies.

    9 replies

    Known Participant
    September 2, 2008
    Participating Frequently
    September 2, 2008
    I belive you should receive E_DISCONNECT event in this case and treat one also as E_STOP event. To submit a feature request I think you need to subscribe to Adobe Prerelease programm.

    Thanks
    Known Participant
    August 31, 2008
    i tried that ping function, but when a user plug off, the ping still return sucessfull, what a big bug !

    application.lapel=function() {
    for (i = 0; i < application.clients.length; i++){
    if (application.clients .ping()){ trace("ping successful: "+ i); } else { trace("ping failed: "+i); }
    }
    }
    Known Participant
    August 31, 2008
    i find NO WAY to detect "plugged out" deconnexion !
    Known Participant
    August 31, 2008
    Hello, i go same problem.
    Unplug clients appears still connected for ever.
    AutoCloseIdleClients should kick theym, but it does not work.

    Looks a FMS bug there.
    June 3, 2008
    Hello, thanks for your answer!

    Okay, well but sooner or later the underlying system should time out a socket? I never ever got a a E_STOP for the clients which I "pulled out" (if i recall correct..), server is on RHEL4 currently.

    About my app-level ping above, how should I know that it fails, when I never get any notification about the failed (due to timeout) call? I guess I could store a per client timestamp at every ping response, and each time i send the pings I check if this value is older than 5 minutes or so..


    For the other question, my idea was that I'd want to, upon receiving a message from my middleware (which is connected in the auth plugin), I'd like to send an IFmsDisconnectAction that disconnected a specific user (ie I receive a stop message from our central app, which kills of the client).

    Now i've managed to get around this by pushing the incomming events into a queue and when I receive an auth/notify event I check this queue and append any events required. This mostly works nice, since its usually an incomming event that is actually trigging the sending of this message, and the events are "posted" immediatly. But this is not always the case, in which case the actual sending of the message is forced to wait until I receive some other event.

    Another approach to this would be if i was able to access the client list immediatly from my plugin, instead of having to work with the IFms*Actions.
    May 26, 2008
    Any clues?

    One ugly way to do it would be to add a timer for each call i dispatch and then terminate the timer when I get the response.. But that is one **** ugly solution and not something I want to do..
    Participating Frequently
    June 2, 2008
    This is because FMS did not get notified of the socket closure. This is where application level ping and keep-alive socket option help to determine when a client is toast due to a network output or some other abnormal termination (or simply yanking the network cable or disabling the network card).
    When FMS knows about the socket closure, and we close the client, we’ll stop any stream he has playing at the time, and E_STOP will get notified. So there is no bug here except we need to be able to detect the network disconnect faster.

    "The only thing i've found is the addNotifyAction on IFmsAuthEvent that allows me to call a a SSAS function from my plugin (when I process an actual event). But not the other way arround (dispatching an authorize/notify event in my plugin, from SSAS) as far as I've seen..."

    That is true. Today you could receive in Auth adaptor events such as: play, stop, publish … executed by SSAS but not a remote call. I am not sure if this is a valuable feature since SSAS and Auth managed by you. Could you please clarify what you trying to achieve by using that?

    Thanks



    May 20, 2008
    Hi, thanks for your answer!

    Yes, that would be one solution that I've thought of.. But then the question is how to interconnect SSAS/remote events with the authorization plugin..

    The only thing i've found is the addNotifyAction on IFmsAuthEvent that allows me to call a a SSAS function from my plugin (when I process an actual event). But not the other way arround (dispatching an authorize/notify event in my plugin, from SSAS) as far as I've seen...

    I guess if I implement the server pinging feature, and do a disconnect, i should get a E_DISCONNECT that I can use, so that might be a (very ugly) solution.

    Okay so I tried that now, with the following code:

    application.onAppStart = function()
    {
    setInterval(application.pingAll, 30000);
    }

    Client.prototype.onStatus = function(info)
    {
    trace("client "+this.id+ "/"+this.ip+" onStatus with "+info.code+", "+ info.level +": " +info.details);
    };

    Client.prototype.onResult = function(info)
    {
    trace("client "+this.id+ "/"+this.ip+" onResult with "+info);
    };

    application.pingAll = function()
    {
    trace("Pinging "+application.clients.length+" clients");
    for (i = 0; i < application.clients.length; i++)
    {
    var c = application.clients[ i ];
    var r = c.call("ping", c);
    trace("Pinging " + c.id + "/"+c.ip+ ", result "+r);
    }
    }


    The result of this was, when pinging a client that was alive I got "NetConnection.Call.Failed" immediately, but that was expected since I haven't implement the ping function in my client. So far so good.. Then I started another connection/stream on a laptop, and pulled the plug.. A while later it tried to ping.. No call to onStatus nor onResult.. waited a bit, after 5 minutes still no call to onResult??.. return value from c.call was always true, but after around 6-7 minutes, it started to return false instead. But no call to onResult..
    To me this seems like a bug? Or do I have to enable timeouts or something?
    I do have <AutoCloseIdleClients enable="true"> (with 60s check interval and 300 max idle) in my config, but still it seems that the client object is alive in application.clients way longer than 5 minutes..

    Seems Adobe got a few quirks to sort out?

    Thanks for any help or input!
    May 20, 2008
    connection timeout when client dies for pay per view>
    - I guess implementing a custom timeout mechanism in server side would help much e.g. pinging each client every 10 second using client.call("onPing", null, <somedata>) in server side. and forcefully disconnecting them (cllient.disconnect) if the reply from your client-side function "onPing" is not received by next iteration.

    I don't have much experience with FMS3 authorization module