A client on the primary network adapter network works well with the
server, but a client on the secondary fails to invoke any of a remote
object's methods.
With a debugger, we can see that the server receives the client request
to create a remote object, but when the client tries to invoke any method, it
fails with the error it can not find the remote object.

The way remoting works is that when a client is passed a reference to a CAO,
the server generates an ObjRef that's passed to the client and from which
the client creates a proxy. One of the pieces of data contained in the
ObjRef is the URI the client should use for subsequent accesses to the
object -- that URI includes the server's IP address. Unfortunately, this
will be the IP of the primary adapter, even if the request was received on
the secondary adapter. So, the client gets the ObjRef from the server and
then attmpts to use an IP which isn't accessible to him, thus you get the
error.

There are a couple of potential solutions. The first is, if the server has a
unique name which can be resolved to the correct IP address from each client
(i.e. ClientA resolves it to an IP valid for ClientA and ClientB resolves it
to an IP valid for ClientB), then you can solve this problem using the
"machineName" property for the channel.

If no such name exists, then the options get trickier. For a good
description of those options, see Allen Andersen's article:

http://www.glacialcomponents.com/ArticleDetail/CAOMN.aspx

Another, more drastic but easier-to-implement solution is to go with a
third-party product such as GenuineChannels (www.genuinechannels.com) which
replaces the TcpChannel and HttpChannel objects and resolves this problem as
well as others with the native remoting channels.

Good luck -
Ken


[quoted text, click to view]