This message was discovered on microsoft.public.dotnet.framework.remoting.
Responses highlighted in red are from those people who are likely to be able to contribute good, authoratitive information to this discussion. They include Microsoft employees, MVP's and others who IMHO contribute well to these kinds of discussions.
| Roland (VIP) |
I'm trying to get a remoting project running in a WAN. The application works
well in LAN and local but does not from outside the company (fails with
different error messages or hangs, mostly "underlying connection has been
closed). Myself I'm not an network expert - on the other hand our network
professional doesn't know dotNet at all. That makes it difficult to find out
what's going on.
Is there something like a "checklist" (that a networker is able understand)
what has to be enabled, configured and so on on clients and servers?
The application uses http or tcp, binary protocol. The server sits behind
firewalls in a DMZ and has only port 9000 enabled.
Below is the (very simple and very common) code of my test app. Is there
anything I've forgotten? Any way to test the connection (ping, tracert ...
does not work because of the firewall)?
This is the server code:
if (pType.ToUpper() == "TCP") {
BinaryServerFormatterSinkProvider p = new
binaryServerFormatterSinkProvider();
p.TypeFilterLevel =
System.Runtime.Serialization.Formatters.TypeFilterLevel.Full;
IDictionary properties = new Hashtable();
properties["port"] = 9000;
properties["machineName"] = url;
TcpChannel vTCPChannel = new TcpChannel(properties, null,p);
ChannelServices.RegisterChannel(vTCPChannel);
} else {
BinaryServerFormatterSinkProvider p = new
BinaryServerFormatterSinkProvider();
p.TypeFilterLevel =
System.Runtime.Serialization.Formatters.TypeFilterLevel.Full;
IDictionary properties = new Hashtable();
properties["port"] = 9000;
properties["machineName"] = url;
HttpChannel vHTTPChannel = new HttpChannel (properties,null,p);
ChannelServices.RegisterChannel(vHTTPChannel);
}
RemotingConfiguration.RegisterActivatedServiceType(typeof(TestRemotingClass));
This is the client code:
private TestRemotingClass remoteClass;
private void Register {
RemotingConfiguration.Configure("test.config");
RemotingConfiguration.RegisterActivatedClientType(typeof(TestRemotingClass),url);
efMessage.Text = "registriert ";
cmdRegister.Enabled=false;
}
private void Instatiate {
remoteClass=new TestRemotingClass(msg);
efMessage.Text = "Instantiert!";
}
test.config is
<configuration>
<system.runtime.remoting>
<application>
<channels>
<channel ref="http" >
<clientProviders>
<formatter ref="binary"/>
</clientProviders>
</channel>
</channels>
</application>
</system.runtime.remoting>
</configuration>
the constructor of the class:
private static long Instances = 0;
private int called = 0;
private string m;
public TestRemotingClass(string msg) {
Instances += 1;
Console.WriteLine("instatiiert " + Instances.ToString() );
m = Instances.ToString();
msg = m;
}
|
|
| |
| |
| Ken Kolda |
What kind of value are you setting for the "machineName" property when you
initialize the channel? You show a variable named "url", but this shouldn't
be a URL -- it should just be the name/IP by which the clients will address
the server, e.g. "abc.mycompany.com" (not http://abc.mycompany.com/).
Assuming that's set correctly, the next thing to check is that your server
is accessible to the client. Do this by telneting to port 9000 of the server
(i.e. "telnet www.youserver.com 9000"). If all you get is "Waiting for
response...", then you're not getting through. If the server answers, you're
good there (not that even if the server answers you won't see any data come
from it -- you just won't have the Waiting for Response message showing
anymore).
Assuming the above is working, your server-activated object should be
working at a minimum (i.e. those you fetch using Activator.GetObject()). If
your SAOs work but not your CAOs, then the probalem is almost certainly with
the "machineName" parameter. To see what the client is actually receiving
from your server, your best bet is to serialize the ObjRef it returns and
look inside.
For example, say I have a remoted CAO named myCAO. To serialize the
underlying ObjRef, the code would look like:
ObjRef objref =
System.Runtime.Remoting.RemotingServices.GetObjRefForProxy(myCAO);
using (FileStream fs = new FileStream(filename, FileMode.Create,
FileAccess.Write, FileShare.None))
new SoapFormatter().Serialize(fs, objref);
Look in this resulting file. At the bottom will be a section that looks
like:
<SOAP-ENC:Array id="ref-14" SOAP-ENC:arrayType="xsd:string[1]">
<item id="ref-15">tcp://129.65.45.3/</item>
</SOAP-ENC:Array>
The URL it shows here is what it is using to connect to the server for
subsequent calls to the CAO. It should reflect the value you set in
"machineName". If this URL is invalid (or it's not a URL that's accessible
from the client), then your CAO will not work.
Hope that helps -
Ken
"Roland" <Click here to reveal e-mail address> wrote in message
news:Click here to reveal e-mail address...
> I'm trying to get a remoting project running in a WAN. The application
works
[Original message clipped]
);
[Original message clipped]
url);
[Original message clipped]
|
|
| |
| |
| Roland (VIP) |
Hi Ken, thanks for your advices!
Before I'm going to check your proposals I have some remarks:
1.) of course you're right the variable name url is wrong.In fact I'm using
the ip-address.
2.) telnet doesn't work, because the telnet port (I guess 23) is not open -
nothing else but the port 9000. (That doesn't make it easier to check if a
connection exists at all). From outside the DMZ you won't see anything.
Everything is masked and filtered in order to avoid port scanning.
3.) from my machine the CAO doesn't even seem to be instantiated. The
"logWriteline", (first statement in the contructor) doesn't appear to be
executed.
At a different machine (which is intended be more restricted than mine!),
the logWriteline was at least executed before it hang (the situation
described in the earlier thread, that I'm trying to solve with the machine
name). No one is having an explanation for that.
The question is: what are you going to tell a network administrator, he has
to do to configure a line. Documentation says "you need an open port for a
winsock connection". That's all I know and that's the only information I can
pass to the admin.No idea what else might be necessary. All our professionals
tell me the port is open to everyone ....
Roland.
|
|
| |
| |
| Ken Kolda |
Using telnet you should be able to connect to any port. At a commen prompt,
simply type:
C:\> telnet somecomputer 9000
The third parameter tells the port number to try to connect to. It sounds
like your first computer can't access the server. The second computer sounds
like the ObjRef has a URL which can't be accessed (try serializing the
ObjRef and see what it says).
Ken
"Roland" <Click here to reveal e-mail address> wrote in message
news:Click here to reveal e-mail address...
[Original message clipped]
|
|
| |
| |
| Roland (VIP) |
Regarding telnet: this is the message from a computer in the LAn where the
application runs (unfortunately in german):
C:\>telnet 161.230.17.232:9000
Verbindungsaufbau zu 161.230.17.232:9000...Es konnte keine Verbindung
hergestell
t werden mit Host auf Port 23 : Verbinden fehlgeschlagen
Translated: couldn't connect to Host on port 23...
I'm afraid I need something different to check the connection.
"Ken Kolda" wrote:
[Original message clipped]
|
|
| |
| | |
|
|
|
|
|
|
|
|
