views:

2012

answers:

2

I am trying to establish a basic .NET Remoting communication between 2x 64bit windows machines. If Machine1 is acting as client and Machine2 as server, then everything works fine. The other way around the following exception occurs:

System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 172.16.7.44:6666

The server code:

TcpChannel channel = new TcpChannel(6666);
ChannelServices.RegisterChannel(channel);
RemotingConfiguration.RegisterWellKnownServiceType(
  typeof(MyRemotableObject),"HelloWorld",WellKnownObjectMode.Singleton);

The client code:

TcpChannel chan = new TcpChannel();
ChannelServices.RegisterChannel(chan);
// Create an instance of the remote object
remoteObject = (MyRemotableObject)Activator.GetObject(
  typeof(MyRemotableObject), "tcp://172.16.7.44:6666/HelloWorld");

Any idea whats wrong with my code?

+8  A: 

Windows Firewall? (Question author says this is not it.)

To track down connection issues the standard approach applies (apply in any order):

  • ping the machine
  • double check if some process really is listening in port 6666 (netstat -an)
  • telnet the machine on port 6666
  • try to use a different service on the machine.
  • check if some configuration upsets the server process listening on 6666 and causes it to refuse you. (don't know if that is possible with .NET remoting)
  • watch communication with the machine using a packet sniffer (Packetyzer, for example) to find out what's going on at the TCP/IP level.
  • maybe active network infrastructure components between server and client (layer-3 switches, firewalls, NAT-routers, whatever) are interfering
Tomalak
Same idea by me, vote +1
mkoeller
Ahh come on :). I know better than that. The windows firewall is definitely off.
Daniel Stanca
Well sometimes I stumble over something simple as that.
Tomalak
+3  A: 

Assuming that the same binaries/configs work one-way but not the other would tell me something amiss in the networking side of the house to start with.

  • You're using IP addresses - double check the bound addresses on target machine against config/code with IPCONFIG /ALL.
  • Does the "server" machine have multiple NICs? Is the service bound to one NIC not both for example?
  • pinging the server will tell you that ICMP is routable between machines - can you create session orient requests e.g. opening UNC paths on the server from the client.

Beyond Firewall, the only other connection refused experiences I've had have been:

  • Name Resolution - preexisting host entry was wrong. Shouldn't be an issue here though.
  • IPSEC oriented - different policies between machines prevented one from accepting inbound connections from the other. Possible if you work in a corporate secured environment. If you do work in an IPSec environment check for simple stuff like clocks, valid machine certs. All of these can prevent IPSec sessions from being established.
  • stress issue - IP stack exhausted free TCP control blocks through misconfiguration of a server. Equally sounds like you can't get any connection going - probably not the issue.

I'd start with Firewall 1st - either by setting policy to exempt inbound requests on that socket, trust all sockets from the source IP, or by disabling it all-together. (personally the latter is quick and dirty as a test, but I would do the former in a production environment)

Beyond that event logs, audit trail if you do have firewall enabled but punched through. Netmon etc. all become your friends.

stephbu