netTcpBinding RemoteAddress fails in Internet Scenario

Mar 17, 2010 at 5:17 PM

Dear All,

I want to use the AppSpace in an Internet scenario. As wsHttpBinding is not supported yet, I am trying to get the netTcpBinding working.

However, I am facing a problem that I can't solve:
When the server starts to set up the TCP connection, it tries to connect to the client using the clients machine name instead of it's IP address.
(it tries to connect to pc070664:8033  instead of, the latter of which is the external IP address of the client.

I was wondering where the service got the machine name from.
I analyzed the SOAP messages sent between client and server for initial negotiation and found the following entry within the body of the second message from the client to the server:


Here it is: pc070664. ----------------------------------------------------------^

Have you got any idea out there how to solve this problem?
Have many thanks! 


Mar 19, 2010 at 12:13 PM

Dear Ralf, Dear Thomas,

might it be that the problem is of a more conceptual nature than I initially thought it would be? I started investigating the XcoAppSpace code in order to find some answers and / or possibilities to enable the framework to support internet scenarios. To my eyes now, the problem is as follows (correct me if I am wrong):

You are making CCR ports remotable. In the CCR world, all communication is oneway communication: From an anonymous client to a known port. If the client wants to receive a response, he simply adds information to the request about the port where the service should send the response to.

Now, in XcoAppSpaces you managed to extend the CCR ports to be remotable, and carried the oneway paradigm to the underlying WCF infrastructure: WCF services with its corresponding channels do only serve for receiving messages (and relay them to local ports and their wired workers). If any service wants to respond to a client, he sends a message to the response port that the client transmitted together with his request message. Hence, this second communication step is not operated on the same WCF channel that was established for the incoming message, but the service in turn tries to open a connection to the WCF service on the client side that hosts the response port. This symmetric oneway - oneway pattern works well as long as the "callback" service on the client side has a well-known address and is reachable on this address from the outside.

This of course works in an intranet scenario, but not when the client is an unknown client on the internet. Even if the client's "callback" service knows its external IP address and is able to communicate that to the server side, the server will hardly be able reach the client's WCF service through NATs, firewalls etc. This is somewhat an internet peer-to-peer problem.

I am not a WCF expert, but I assume that the chosen WCF infrastructure might also be a problem when it comes to supporting wsHttpBinding in the XcoAppSpace framework. Simply because the "callback" server built into any distributed client app will not be reachable by the server-side AppSpace.

Ok, what might be solution?

Using jabber protocol? I promise to take a look at that. (But I worry a little that every client might need to have an own jabber-id. How to automate that..?)

Or is it conceivable to not use a second WCF channel from the server to the client for the callback communication - but may be to project both CCR oneway communications onto only one WCF duplex channel, namely the one that the client established to the server. OK, that would imply some limitations with respect to the idea of highly distributed workers. That is, a client would not be able to tell a service that it should please send the response not back to him (a port hosted in the client's AppSpace), but to someone else (a port that is hosted within a third AppSpace / a third machine).

But is this a major conceptual limitation?  Honestly: I don't know.
But I realize that I might be unable to get my AppSpace running on the internet, what makes me somewhat sad these days.. :-)

'Will be glad to hear your opinion on this subject.


Mar 19, 2010 at 12:24 PM

Hi, Claas!

Thx for digging into AppSpace code. Hope you did not find it too complex ;-) We´ve spent quite some time to structure it well.

What you call out as the root cause really seems to be a problem. In intranet scenario this works well - but over the internet it sure does not.

I guess, what we need to do is either configure the WCF transport differently or write another one which works on a duplex channel. Thomas and Markus sure will look into this. Stay tuned!


Mar 19, 2010 at 1:07 PM
Edited Mar 19, 2010 at 1:07 PM

Hi, Claas!

You are abolsutely right: The problem with the WCF service in internet scenarios is that it uses one way communication, so it needs two different channels as soon as the client that is sending a request wants to receive a response on a response port. If the client knows its external IP address, it would be possible to configure the service by instantiating it like this:

new XcoWCFTransportService("net.tcp://externalip:port/XcoAppSpace");

However, as you say there is still the problem with NAT and firewalls. Until now the wcf transport service was in fact mainly centered on intranet scenarios. But with the need for http communication we will surely make some changes here in the near future. Right now as you say a possible solution is the jabber transport service which we designed especially for internet scenarios. Another possibility is our new Azure Transport Service, which you can download from SVN and is currently undergoing some final tests (unfortunately you need an azure account for that). You could also try the tcp transport service, which supports anonymous clients by using a bidirectional channel, but may lack security features and other things wcf provides for free. We will definitely do some research if we can make a wcf transport service supporting http and using a duplex channel.

By the way: It may not help now with the problem of anonymous clients, but we added support for wsHttpBinding to the wcf transport service. You can get it by checking out the latest version from SVN. Best take a look at the test.XcoAppSpaces.Transport.WCF.wshttp project on how to use configure the transport services.


Mar 19, 2010 at 1:28 PM

Dear Ralf, Dear Thomas,

thanks for sharing your thoughts. Summarizing what you said, for the moment I will have to concentrate on one of the follwing three options:
1) pure TCP communication
2) Jabber
3) Azure

However, I still think that mapping both oneway-communications onto one duplex channel might be a good option for the future in order to get the WCF transports run on the internet.

Have my best regards!


Mar 19, 2010 at 2:49 PM

'just remembered a session held by I think Jörg Neumann or Dominick Baier on the Prio 08, which dealt with WCF P2P Communication and how two peers can manage to reach one another even via firewalls etc. 'Dont remember it exactly but I found it interesting and it exactly targeted the problem of a client dynamically turning into a server, which I am sure is a kind of  "old" communication problem.
(as it often is: One of the few things you can be sure of is that someone else likely came across the pretty same issue before you did..                  ..which I claim to be true for me at least :-)  )

OK, just a thought. 
Maybe the P2P pattern sheds some light on the double oneway communication.


Mar 19, 2010 at 4:46 PM

Funny, I attended this session at Prio 08 as well :-)
This could really be something interesting in our situation.


Aug 5, 2010 at 4:13 PM
There is a third solution: Hook all computers onto a vpn. This way they can all see each other, and you have the bonus that all traffic is encrypted I understand that this is not viable for all scenarios, but for some of them this might even be the preferred way.