This message was discovered on microsoft.public.dotnet.framework.remoting.
| Linus Girdland |
| GOOD ANSWER |
Hello,
I have a problem with .NET Remoting over TCP Channel though a router
and local access.
I have read the excellent article "How to use CAOs behind a firewall"
at http://www.dotnetremoting.cc/FAQs/CAOS_INTERNET_FIREWALL.asp and
noticed that I had to set the machineName of the TcpChannel to get the
..NET Remoting call to work through a NAT Router (using port forward to
an internal machine).
The thing is that this server I am working on have two clients. One
that connects from an external machine through the NAT Router and one
client that is just locally installed on my server machine. The
external client is a aspx web server, and the internal is a client
used to configure the server. Both uses .NET Remoting over
TcpChannels.
As soon as I set the machineName property of the TcpChannel to the
router's IP Addres calls from the external client works, but stops
working from the local client. Well, that is quite obvious I realized
after thinking a while. Replies to the local client are deliverd to
the client as if they came from a computer with the address set by the
machineName property, and thus the local client will ignore that
reply. So how do I solve that?
Well, I tried to solv it by using two TcpChannel objects, on two
differerent ports. One TcpChannel where I set the machineName to the
routers address (used by the external client) and one that is not
using the machineName property.
The odd thing is if I register the TcpChannel used by the external
client first (using ChannelServices.RegisterChannel) the external
client will work, but not the internal. If I switch the order of
registration it is the other way around.
I can see that the requests are received and processed by the server
but the reply never reaches the client.
Might this be a bug in the .NET Framework? Or how do I solve the
problem?
Please help me!
Regards,
Linus Girdland
Click here to reveal e-mail address
Here is some code from my server:
IDictionary prop = new Hashtable();
prop["name"] = "RouterChannel";
prop["port"] = 1998;
prop["machineName"] = "aaa.bbb.ccc.ddd"; // removed the actual ip
number from the code sample
s_tcpChannelThroughRouter = new TcpChannel(prop, null, null);
prop = new Hashtable();
prop["name"] = "InternalChannel";
prop["port"] = 1997;
s_tcpChannelInternal= new TcpChannel(prop, null, null);
ChannelServices.RegisterChannel(s_tcpChannelThroughRouter);
ChannelServices.RegisterChannel(s_tcpChannelInternal);
RemotingConfiguration.RegisterWellKnownServiceType(typeof
(ServerSingleton), ServerProperties.ServerName,
WellKnownObjectMode.Singleton);
|
|
|
| |
|
|
| |
| |
| Linus Girdland |
| GOOD ANSWER |
I would like to add some more details to the problem I just described
below.
The reply only reaches the client when the reply is a basic type such
as bool, int etc. When I pass an object to the client as an interface,
an object that inherits from MarshalByRefObject, that object does NOT
reach the client.
Well, maybe they do reach the client but get rejected or something.
Since the client expects a reply from the same computer that the
request was sent to.
If I sent the request to the router from the external client, the
MarshalByRef object only gets received by the client if the server
sets the machineName property if the TcpChannel to the IP address of
the router. And the internal client (running on the same machine as
the server) only receives the reply from the server if the server does
NOT set the machineName to something.
My though was that by using two TcpChannels, on two different ports, I
could set the machineName of one of them and use that for the requests
through the router and the other channel for local requests (by local,
I mean from the same subnet as the server).
By for some reason that does not work. Depending on the order in which
I register the channel, both channels seems to get the machineName
property set or not.
Here is some client code:
serverURL = "tcp://213.15.68.xxx:1998/CheckPointServer
IServerSingleton server = (IServerSingleton)
Activator.GetObject(typeof(IServerSingleton), serverURL);
// This does not work, I get timeout waiting for the call to return
ICitectSyncReport tagsSyncReport = null;
tagsSyncReport = server.synchronizeCitectTags(AdminProperties.getInstance().CurrentUser);
// This works - since the return value is a simple type
bool result
result = server.validateUser("myuser", "mypassword");
I hope someone has an answer or workaround to this problem.
/Linus
[Original message clipped]
|
|
|
| |
|
|
| |
| |
| Ingo Rammer |
| GOOD ANSWER |
Hi Linus,
your observation is absolutely correct. In .NET Remoting the server
generates the URL for a CAO. When registering more than one TCPChannel,
either the sequence (as in your case) or the priority="" attribute specifies
the channel for which the URL will be transferred first - this is also the
channel which will be used by the client to place further calls on the CAO.
The first solution which I can think about right now is to use different
channels for internal and external communication. For example, use a
TCPChannel for the internal comm and an HTTPChannel for the external
communication. When doing it this way, the clients will both receive both
URLs to the CAOs but each will choose the transport channel which is
registered at the client. This way, one will contact the CAO via HTTP
whereas the other will contact it via TCP. In this case, you can use a
different machineName="" value for both channels.
The second solution is to reconfigure your router so that it will also
forward all requests from the LAN back to your real server.
The third way - which is a little bit of a hack - would be to introduce a
custom channel sink at your LAN client which would then rewrite the URLs for
each method call so that it points directly to your internal server. I guess
this would be about 30 lines of code so it shouldn't be too hard ...
-Ingo
Author of "Advanced .NET Remoting"
and "Advanced .NET Remoting in VB.NET"
http://www.dotnetremoting.cc
"Linus Girdland" <Click here to reveal e-mail address> wrote in message
news:Click here to reveal e-mail address...
[Original message clipped]
|
|
|
| |
|
|
| |
|
|
|
|
|
|
