|
The server's IP address came from a response packet. Any time computers communicate over TCP/IP, the packets contain a "source" and "destination" IP address. You will get the error you saw when the IP address the client sent the request to does not match the IP address the server returns. The error is the result of basic remoting security so that the client does not get directed to the wrong server. The client was expecting a response from the Public IP address specified in the remoting URL and received a different IP which it interprets as a connection to the wrong server. Also, the Private IP address range is not routable over the Internet so you can't use the server's IP from the client's side in order to get an IP address match. The server placed its Private IP address into the return packet since that is the default unless you specifiy a different one in the Web.config for an IIS deployment or an App.config for a Console/Windows Service server. In our tutorials and in our Developers Guide, we address this problem which is encountered any time the server is behind a firewall with Network Address Translation (NAT) enabled.
Below is an example application configuration file with instructions. Just paste the content into a text file and then rename it as per instruction #3 below. Also, make sure the service name in the "objectUri" of the app config matches the <serviceName> you used in the client's IdeaBlade.ibconfig.
<!-- Sample configuration file for the ServerConsole.exe or the ServerService.exe
In most cases, the IdeaBlade.ibconfig file (either loose or
embedded in an assembly) is all that's required to configure
remoting in the console or Windows Service servers. You can use a config
file if further customization is needed, such as for NAT.
To use:
1) Change the port="" value to the port to be used. Be sure the port is open.
2) Customize the <channel> element attributes as needed. This sample
shows a machineName attribute waiting to be set. Do not change the
channel ref type nor any provider information.
Consult .NET documentation for channel properties and appropriate values.
http://msdn2.microsoft.com/en-us/library/kw7c6kwc.aspx - http://msdn2.microsoft.com/en-us/library/kw7c6kwc.aspx
3) Rename the file for the BOS used: ServerConsole.exe.config or ServerService.exe.config
and place the file in the application folder with the executables.
4) If an appropriately named config file is found in the same directory
as the executable, DevForce will first attempt to configure the
Remoting channel using the config file instead of the remoting information
in IdeaBlade.ibconfig.
5) Be sure that your IdeaBlade.ibconfig file is still available, and that the
communicationsTechnology element in the remoting section does not say "Wcf".
-->
<configuration> <system.runtime.remoting> <application> <service> <wellknown mode="Singleton" type="IdeaBlade.Persistence.RemotingPersistenceService, IdeaBlade.Persistence" objectUri="PersistenceService" /> </service> <!-- IdeaBlade uses a compressed binary formatted channel --> <!-- You can change the channel attributes as needed --> <channels> <channel ref="http" port=" 9009" machineName=" Public IP address goes here"> <serverProviders> <provider ref="compression" /> <formatter ref="binary" typeFilterLevel="Full" /> </serverProviders> </channel> </channels> </application> <!-- Compression is done thru a custom channel sink - do not change --> <channelSinkProviders> <serverProviders> <provider id="compression" type="IdeaBlade.Persistence.CompressedServerChannelSinkProvider, IdeaBlade.Persistence" /> </serverProviders> </channelSinkProviders> <!-- setting customErrors off ensures that client receives full error information -->
<customErrors mode="Off"/>
</system.runtime.remoting>
</configuration>
|