Remote Clients with Duplex communications RRS feed

  • Question

  • The is a general question, but one which I hope someone can comment on.


    We have an application that we want remote clients to talk to, so I have created an HTTP service that is exposed on the web. The client application will need to send a message, then receive a reply probably in about 20-30 seconds as our Service needs to process and send a message to an external system then receive a reply which the client needs to see. Given this, I thought a Duplex callback solution suits us down to the ground, however, we now have a fundamental problem. Correct me if I am wrong, but for a client to process a callback, the client needs to give the Service an endpoint so the Service can invoke the callback method. This means that the client needs to sit and process the HTTP post from the Service, and, therefore, act as an HTTP server. In fact I know this to be true because if I have my local IIS running and a client using an endpoint on port 80, the client will error because it is clashing with the IIS. Most of our remote clients will probably be simple PCs probably connected to the web via a hub to a Broadband connection or via a Proxy Server if sitting on a network. If this is the case, the client will not be able to give a URL which the Service can respond to because the URL will not be exposed on the Web. I have tried this and found this to be true 


    So, my question is, is there a way that these remote clients without direct exposure to the Web can specify an endpoint that the Service can use and the client can process callbacks from? If not, does this mean that duplex communications can only be used by clients on the same network as the Service or who are connected directly to the web?



    Friday, April 13, 2007 11:36 AM


  • Hello Mr B,


    Looking at the requirements for your application, you might not need a Duplex contract. You are trying to accomodate the 20-30 second time processing time that your service needs, so it looks like you could use an asyncrhonous callback. This this tells the service to call back your client when it is finished executing, without having the cilent expose an endpoint.


    Take a look at this article:



    Does this help?


    Friday, April 13, 2007 11:54 PM