M
Michael Bray
Ok guys here's a tough one... I have a client/server application that
uses remoting for communication. I am using Activator.GetObject to create
a remoting instance with an URL that specifies the client machine by name.
The *application* server in this case is the *remoting* client. In other
words, the "application server" needs to talk to the "application client"
to tell it that there is a new configuration available for it, and that it
should communicate back to the "application server" to download this new
configuration. From this point on, I will refer to each machine's
*application* role, not the *remoting* role. OK?
Each client (application-wise) is configured to use DHCP, as you would
expect client machines to be. Apparently, it does occasionally change IP
addresses. OK fine - this is not unreasonable.
My problem is that when this change occurs, it appears that my server
application is caching the old DNS information, and thus the remoting call
from the server to client fails. I know that its trying to communicate to
the wrong IP address because I sniffed the IP packets. This is *NOT* an
operating-system level caching issue, because from the server's CMD prompt,
I can ping the client machine and I get the correct IP address. This
effect persists until I restart the server application.
Even after I have pinged the client, the server application still tries to
communicate with the machine using the old DNS info.
So to summarize:
- Server connects to client using tcp://clientPC:48000/MyRemotingApp - ok
- After a while (days/weeks/whatever), Client IP address changes by DHCP
- Server fails to connect using tcp://clientPC:48000/MyRemotingApp because
it is trying to communicate to the OLD IP Address
- I 'ping clientPC' and everything works fine
- I re-issue command to connect and it still fails because it communicates
to the old IP address.
- I restart the server application
- I reissue the connect command again and everything works great.
Its almost as if the .NET framework, specifically the remoting portion, is
caching the DNS information.
Has anyone seen anything like this? Is this a known bug? Is there a fix?
If not then I can probably just connect by IP address, but I'd prefer not
to have to do that if possible?
-mdb
uses remoting for communication. I am using Activator.GetObject to create
a remoting instance with an URL that specifies the client machine by name.
The *application* server in this case is the *remoting* client. In other
words, the "application server" needs to talk to the "application client"
to tell it that there is a new configuration available for it, and that it
should communicate back to the "application server" to download this new
configuration. From this point on, I will refer to each machine's
*application* role, not the *remoting* role. OK?
Each client (application-wise) is configured to use DHCP, as you would
expect client machines to be. Apparently, it does occasionally change IP
addresses. OK fine - this is not unreasonable.
My problem is that when this change occurs, it appears that my server
application is caching the old DNS information, and thus the remoting call
from the server to client fails. I know that its trying to communicate to
the wrong IP address because I sniffed the IP packets. This is *NOT* an
operating-system level caching issue, because from the server's CMD prompt,
I can ping the client machine and I get the correct IP address. This
effect persists until I restart the server application.
Even after I have pinged the client, the server application still tries to
communicate with the machine using the old DNS info.
So to summarize:
- Server connects to client using tcp://clientPC:48000/MyRemotingApp - ok
- After a while (days/weeks/whatever), Client IP address changes by DHCP
- Server fails to connect using tcp://clientPC:48000/MyRemotingApp because
it is trying to communicate to the OLD IP Address
- I 'ping clientPC' and everything works fine
- I re-issue command to connect and it still fails because it communicates
to the old IP address.
- I restart the server application
- I reissue the connect command again and everything works great.
Its almost as if the .NET framework, specifically the remoting portion, is
caching the DNS information.
Has anyone seen anything like this? Is this a known bug? Is there a fix?
If not then I can probably just connect by IP address, but I'd prefer not
to have to do that if possible?
-mdb