During my implementation for a client/server application I encountered the follwing problem:
Let's say we have a client application C which is the remoting client and that connect to a Server application S which is the remoting server.
C has two NICs which are both activated.
The problem is when both cards are activated, the client application C is having a hard time establishing a connection with the remoting server S. It seems that the client cannot detect what card to use. Whenever we disable one card, Everything works fine.
Some sites adviced to configure the "bind to" attribute but it does not work.
Note that when running both application on the same machine, no problem occurs. This occurs only when the client and server application are run in different machines.
Thank you for your feedback. This solution may work but it will not be the best approach. The thing is that we cannot oblige the end users to configure that since that it may affect other applications.
I think that this should be handled in the application level and so on it will be transparent to the user.
Any idea about how to make that configured in .Net Remoting?
- but I think this is a pure low level windows setting/config. Routes have to be configured/added like IP, gateway, mask, mac, etc of both network cards. I don't think this is a per-application domain (but don't hold my word to it).
- there probably is a way to add a route from your .net program, but it probably requires administrative privileges (instead of configuring it manually).
- I think "other applications" are already using a route that is configured right
btw Why are they using dual nic? I'm curious on what is the use case.
Thank you for the feedback
First, I have just fixed this by configuring with the machine name instead of the IP address. That is a kind of workaround about that
To answer your question, there is no use for dual nic actually. I was testing my application on a new machine and I got the error (since it does have 2 network cards) so I was figuring out if I could manage that
Last Visit: 31-Dec-99 19:00 Last Update: 1-Dec-15 0:21