TCP Keep Alive connection hosted in WCF

Question

I am attempting to host a TCP client connection in a wcf service that communicates with a 3rd party app. The WCF service will wrap the tcp calls to the third party app so that any application connecting to the WCF service will have no knowledge of the TCP connection. Due to the protocol that the 3rd party app requires, the tcp connection must be kept alive. I have implemented the logic to handle errors and reconnecting, but the issue I'm running into is how to open and close this connection. Is there a way for me to override the host Open and Close calls so that I can do the same with my CommunicationService?

My Code:

public partial class HostService : ServiceBase
{
    private ServiceHost _host;

    public HostService()
    {
        InitializeComponent();
    }

    protected override void OnStart(string[] args)
    {
        Type serviceType = typeof(MessageProcessor);
        var serviceUri = new Uri("http://localhost:9091/");
        _host = new ServiceHost(serviceType, serviceUri);
        _host.Open();
    }

    protected override void OnStop()
    {
        _host.Close();
    }
}

[ServiceContract]
public interface IMessageProcessor
{
    [OperationContract]
    void ProcessMessage(string message);
}

public class MessageProcessor : IMessageProcessor
{
    //This is handling my TCP connection.
    private CommunicationService _communicationService;

    public MessageProcessor()
    {
        _communicationService = new CommunicationService();
    }

    public void ProcessMessage(string message)
    {
        if(_communicationService.Connected)
        {
            var request = new QueryMessage();
            var result = _communicationService.TransmitMessage(request);
        }
        else
        {
            //Error handling, not necessary for now
        }
    }
    //I want to do this
    public override Open()
    {
        _communicationService.Open();
    }
    public override Close()
    {
        _communicationService.Close();
    }
}

Answer 1

When you should setup/tear down your TCP connection depends on when and how many of your service object (MessageProcessor) are created / disposed.

WCF is very flexible and handles many different models. These are controlled by the InstanceContextMode and the ConcurrencyMode of your service. These can be set in your config file or in code when the service is created.

InstanceContextMode controls when your service object is created. There are three options.

1) Per Call . Every time a client calls one of your service methods, a new instance of your MessageProcessor will be created. Even if it's the same client calling two methods, you'll get two MessageProcessor objects. This is the default.

2) Per Session : Some transports (eg TCP) support reliable sessions. The client connects which will start a new sessions and an instance of your MessageProcessor object will be created. The client can call many methods and the same instance will process them. When the client disconnects, the object will be destroyed. Note that many clients will still result in many MessageProcessor objects (each client has their own session).

3) Single : All service calls use the same instance of your MessageProcessor object. The object lives for as long as the service host is alive.

ConcurrencyMode controls how many threads are allowed into the same service object. For example, with a Single instanceContext, you might allow multiple client calls to be serviced all at once on different threads, or you might want to force WCF to only allow one thread at a time into your MessageProcessor if it's not thread safe.

Given that you want to keep your TCP connection live as long as clients need it, it depends on what InstanceContextMode you are using as to where and how you connect/disconnect your TCP connection. If using Single mode for instance, you would simply connect at the time you create your service host and disconnect when the host is shutdown. If using Per Call mode, you would maybe disconnect when all service objects have been destroyed, or perhaps wait for a short time in case another call comes in. It's really up to you.