locked
PollingDuplex InactivityTimeout Problem RRS feed

  • Question

  • I have developed a Silverlight based push application, utilising PollingDuplex over a basicHttp binding.

    Since upgrading the library components on client / server side to Silverlight 4, I have noted that channel faults occur on the exact same interval as the InactivityTimeout setting used in the PollingDuplexBindingElement.

    If only the server is pushing, with no message activity originating from the client side, the error occurs.

    Whenever the client posts a message over the channel, the error goes away. Seems to be the only way activity is detected.

    I would prefer to utilise the latest version of Silverlight 4, and would appreciate it if some assistance can be given.

    Friday, October 15, 2010 9:04 AM

Answers

  • Corneille,

    This is the correct behavior. You need to maintain some kind of activity within the InactivityTimeout period, otherwise the client will be disconnected. Sending a single ping once every few minute should do it.



    Casimodo,

    It turns out a regression was introduced in Silverlight 4 GDR 1 that caused this to happen when the following condition are combined:

    -PollingDuplex with MultipleMessagesPerPoll duplexMode
    -Use of the browserhttpwebrequest stack (default)
    -Use of IE8

    To restore the proper behavior without waiting for a fix, you should consider using the ClientHttpWebRequest stack. You can also revert to SingleMessagePerPoll which does not get impacted by this regression.

    Wednesday, December 15, 2010 6:07 PM

All replies

  • Hi,

    What kind of error did you encounter, could you please show me some error message?

    Besides, silverlight4 support nettcpTransport, which would be more efficient than http polling way, you may take a look at this blog

    http://mogliang.blogspot.com/2010/08/how-to-consume-wcf-service-with.html

    Thanks,

    Wednesday, October 20, 2010 4:07 AM
  • Hi


    The channel faulted, but I will try to obtain more detail.


    I have previously experimented with the NetTcp functionality, but it is unfortunately not feasible in a public space, due to port 80 not being accessible.

    To utilise this functionality, a form of proxy would have to be implemented running on the client side, which I am busy assembling at the moment.


    Regards

    Corneile Britz

    Wednesday, October 20, 2010 4:40 AM
  • I can't help you here, so just an info: I've never managed to make the PollingDuplexMode.MultipleMessagesPerPoll work for me (I'm using it with RIA Services side-by-side). On the other hand, things work fine for me with PollingDuplexMode.SingleMessagePerPoll. Which mode are you using?

    Maybe of interest: http://blogs.msdn.com/b/silverlightws/archive/2010/07/16/pollingduplex-multiple-mode-timeouts-demystified.aspx

    Regards,

    Kasimier Buchcik

    Wednesday, October 20, 2010 10:58 AM
  • Corneille,

    This is the correct behavior. You need to maintain some kind of activity within the InactivityTimeout period, otherwise the client will be disconnected. Sending a single ping once every few minute should do it.



    Casimodo,

    It turns out a regression was introduced in Silverlight 4 GDR 1 that caused this to happen when the following condition are combined:

    -PollingDuplex with MultipleMessagesPerPoll duplexMode
    -Use of the browserhttpwebrequest stack (default)
    -Use of IE8

    To restore the proper behavior without waiting for a fix, you should consider using the ClientHttpWebRequest stack. You can also revert to SingleMessagePerPoll which does not get impacted by this regression.

    Wednesday, December 15, 2010 6:07 PM