none
Best Practices for Duplex Connection & Heartbeat/KeepAlive or Messaging Service Practices? RRS feed

  • Question

  • Okay, this has been a frustrating project because I'm not able to use all the WCF niceties like everyone else.  I develop for our business and am not part of our IT group which means I'm subject to their rules.  For one, I can't create a Windows Service and two I am blocked from using MSMQ. 

    So the scenario is this... I have a WCF service that I'm hosting from an external exe.  We'll call it the Host.exe.  I have a Client.exe and a client.dll (is loaded into a Third-Party.exe).  The Client.exe and the Client.dll have to communicate with each other.  Because of the complications of using a dll that is loadedinto a third-party's application, I've built this framework to encapsulate the WCF goodies such that I can configure, host, connect, etc with the service.  The scenario is that the Client.exe and Client.dll have to be able to communicate information back and forth to each other while the Service is also tracking the state of their requests.

    The question is a two-parter:

    1.)  Heartbeat best practice?  Since the Client.exe and Client.dll have to communicate with each other, it seems that Duplex is the way to go.  With normal oneway services, the MSDN recommendation is to open, run operations, then close the connection on the client-side within the same try/catch block, but there are no recommendations for Duplex services.  It's my understanding that Duplex's like this typically require the connection to stay open and many suggest a heartbeat approach.  What's best practices for this? 

             A.) Use a multi-threaded timer in the Client.exe and Client.dll? 

             B.) Use a multi-threaded timer in the Service?

    2.)  If it's a big performance buster or just very, very not-recommended to keep the connection open (I've heard a variety of reasons for this with OneWay connections) what is best practice for this scenario?  Maybe use a waithandle to keep the connection open just during a particular transaction between the two?  But if that's the case and the other end is closed, how else would it know to start the connection?

    I've spent several weeks working on developing a framework to support this, any help ensuring I'm doing everything the way I should would be greatly appreciated!


    Jason

    Saturday, September 7, 2013 7:52 PM

Answers

  • Hi,

    For your first question:

    A.) Use a multi-threaded timer in the Client.exe and Client.dll?
    B.) Use a multi-threaded timer in the Service?

    In my mind, I will choose to use a mutil-threas timer in the Client.exe and Client.dll.

    In WCF it has provided three ways to control the instance management:Percall,Persession,Sinle

    Per session instance mode
    In per session mode, only one instance of a WCF service object is created for a session interaction. So a service will be created for many proxy client. When the client finishes its activity, the WCF instance is destroyed.

    Single instance mode
    A wcf service instance will be created for all client. And even if the client finishes its activity, the service still not be destroyed.

    Both the Persession and Single mode can help you to work with many client in good performance.

    For more information, please try to refer to:
    #WCF instance management:
    http://www.codeproject.com/Articles/86007/3-ways-to-do-WCF-instance-management-Per-call-Per .


    For your second quetion:

    If it's a big performance buster or just very, very not-recommended to keep the connection open (I've heard a variety of reasons for this with OneWay connections) what is best practice for this scenario? Maybe use a waithandle to keep the connection open just during a particular transaction between the two? But if that's the case and the other end is closed, how else would it know to start the connection?
    Yes it is good practice to close the channel as soon as it is not needed any more. But it is not usual in case of Duplex communication. When you are using duplex communication you need opened channel to allow server send messages back to the client. WCF communication is always initiated by the client. Callback is allowed only by keeping channel initiated by the client openned.

    Duplex communication involves some additional tasks to handle connection failures. Your service should contain some ping mechanism to allow client to check the connection in regular interval. If the connection fails client receives exception and you will be able to reestabilish connection. Also service should handle exception when sending callback message to faulted channel.

    Best Regards,
    Amy Peng


    <THE CONTENT IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, WHETHER EXPRESS OR IMPLIED>
    Thanks
    MSDN Community Support

    Please remember to "Mark as Answer" the responses that resolved your issue. It is a common way to recognize those who have helped you, and makes it easier for other visitors to find the resolution later.


    Tuesday, September 10, 2013 2:39 AM
    Moderator