WCF上的TextReader和TextWriter

Question

I'm trying to write this question for the fourth time, as I'm unfortunately not sure what I actually want. Please excuse me being vague or a bit off.

I have a command line .NET4.5 C# application. I'll run it at the same time at two geographically distant locations. I want to be able to turn one instance into host and the other into client.

In the heart of it, I want a TextReader implementation, that upon Read/ReadLine awaits for an input from a remote client. I also want a TextWriter that upon Write/WriteLine will call a remote client and pass text to it.

The TextWriter is of course fairly simple matter, as I basically do that: on write, call client.SendText(s); to the other instance.

How do I go about implementing TextReader.ReadLine() in that scenario? A naive aproach would be to have, in the WCF service, a method:

class Service : IService{
    void SendText(string s){
        Console.WriteLine(s); // or whatever is the destination TextWriter
    }
    string ReadLine(){
        return Console.ReadLine(); // or whatever is the source TextReader
    }
}

but is keeping the WCF operation call open for minutes or even hours a good idea?

Another way I can see is to have:

class Service : IService{
    void RegisterClient(string url){/* url points to an IService endpoint in client*/}
    void SendString(string s){...}
}

And then host it in both instances, call RegisterClient from client providing own endpoint url and then if host wants to return some data to client - just calls SendString, no problem. But if hosts must wait for input from client, how to solve that reasonably?

class WCFTextReader : TextReader{
   public override string ReadLine(){
       // what here? it should return whatever comes in the next SendString call from client...
   }
}

I could have a Queue<string> of incoming messages and then do a while(true) and either return first from Queue or Thread.Sleep for a short while and re-check, but every time I feel that I need while(true) and Thread.Sleep I'd rather come here, because I think I'm missing something....

Answer 1

The default WCF message pattern is request/response; a client sends a request, and the server responds to it.

There is, however, a duplex message pattern, in which the service interface contract identifies another interface as its callback interface contract; the client must implement this callback interface contract, similar to how the service must implement the service interface contract.

This message pattern should allow your server to arbitrarily send a message to the client without the client having to prompt it to do so.

http://msdn.microsoft.com/en-us/library/ms731064%28v=vs.110%29.aspx

http://msdn.microsoft.com/en-us/library/ms731184%28v=vs.110%29.aspx

** Fair warning: in my experience, you potentially still have to deal with the issue of keeping the connection alive, in case you plan to have the server send a message back to the client after a significant period of inactivity.

If keeping the connection open is acceptable to you, then you can implement some kind of keep-alive mechanism.

If keeping the connection open is not acceptable, then I think you'd need to look at a more complex approach that would involve the client periodically checking in with the server in order to give the server an opportunity to send the client any queued up messages that it has for the client.