DMZ issue?, Func: CheckWorkerResolveResponse, Port`1 could not be resolved

Dec 1, 2010 at 10:22 PM

Hello XcoAppSpace Team.

And here the second issue.

Our application which creates and holds the AppSpace workers is running inside an DMZone. By default the DMZ makes sure the server can only establish connections to other network end-points. But the client can connect the server by all ports.

We have used wcf.port=9001 as transport type and port.

            using (var space = new XcoAppSpace("wcf.port=9001"))

But by starting the client and try to connect a server worker an error appears at function: "CheckWorkerResolveResponse" and telling: "Worker at with type Port`1 could not be resolved. Reason: Noresponse"

If I switch the transport type to: "tcp.port=9000". Then all working fine by using "only" an REQUEST/RESPONSE pattern.

            using (var space = new XcoAppSpace("tcp.port=9001"))

I read an kind of similar dicussion here. It was about XcoAppSpace working in an online szenario. But not sure if realy similar and could not find an new status about this issue.

Some extra: In addional to my previous discussion start here The described problem there happens after around 1 minute running inside the DMZ infrastructure enviroment even if the client application hav'nt closed cause of abnormal reasons but using the "SUBSCRIBE/ UNSUBSCRIBE patern" and not "REQUEST/ RESPONSE". There is no different if the publisher publish messages or not.


Dec 3, 2010 at 6:26 PM

Hi Roberto,

Unfortunately this kind of communication is currently not possible with the WCF transport service. This is because the WCF transport service establishes an own connection in every direction, meaning when the server wants to send a message to the client, it tries to open a direct connection to this client, which as you say is not possible. We will probably also have a WCF transport service that supports such scenarios somewhere in the future, but for now this is only possible with the TCP transport service or one of the transport services that are specialized for internet scenarios (Jabber, Azure).

The problem you are having with the TCP transport service (communication stopping after arount 1 minute) is probably coming from the communication timeout. In the current version, this timeout only refreshes when sending messages, but not when receiving. This means that when the client doesn't send any messages for 1 minute, it will close the connection to the server (even if the server regularly publishes messages to the client). You could work around this for example by letting the client send alive-messages to the server every 30 seconds or so. But, since this behavior of closing the connection actually isn't really that good understand, I made some changes to the TCP transport service so that the connection timeout is refreshed also when receiving messages . If you are publishing a message at least every 60 seconds, this should solve your problem (if not, letting the client send alive messages would probably be the best way to solve this). 
To get the improved version, just download the source code and compile it with the buildXcoAppSpaces.bat file in the build folder.

Hope I could help you!


Dec 7, 2010 at 12:32 PM

Hi Thomas.

About the Wcf issue ok I understand. Thats fine as I can use TCP.

For the conncetion timeout, good to known i understand your solutution and will test it as well with your timeout improvement done by the Xco worker.

So you have helped me yes! Thanks for!


Jun 17, 2011 at 4:56 PM

Hi Thomas.


Sorry for long time no contribution reponse on your advice.

I have implemented and tested to get rid of the timeout issue. And it works well now.