Problem with Silverlight Glacier2 Callback demo

[JvD]

When I run the Glacier2 Callback demo with the democs server everything work fine as long as server, glacier2, policyserver and client run on the same machine.
I have a problem in the following case:
1. Server, and glacier2 run on one machine.
2. The client and the policyserver runs on the other machine.

My first try was just to run the policyserver using ip-address 127.0.0.1 at the commandline and run the code. When I press the login button I get a ConnectionRefused exception.

Of course the client is not able to get to glacier2 at the server side. So I changed the Ice.Default.Router property inisde the client-code to make it point to the IP address of the machine with glacier2. The policyserver remains to run using 127.0.0.1. When I then run the code I get an AccessDenied exception.

When reading the INSTALL.WINDOWS of the chatdemo I found out the policyserver must listen to the same IP-address as where the website is hosted. So instead of using 127.0.0.1 I let the policyserver run using the IP address of the client. In this case I also get an AccessDenied exception.

However when I let the policyserver run at the server using the IP address of the server I am able to establish a connection.

This is not as I expected since:
1. The policyserver is only required in case of using a Silverlight client, so I wuold expect the policyserver to run on the client side.
2. In my case the server side runs Linux and I am not able to run a policyserver there.

I expect to be able to let a silverlight client run on top of a linux server, without the need to change the server.

I have the following questions:
1. Is it true that I should be able to run a Silverlight client on top of a linux server?
2. In case that it should be possible, how must I configure/use the policyserver to get things to work?

Hope to read from you soon.

Joost van Doorn

[xdm]

Hi Joost,

The policy server should listen in same ip address that the webserver that is hosting the silverlight client. This is a requisite of Silverlight 2.

Glacier2 could listen on a different ip as far as the policy allow connection to that ip address port and the client application use the right glacier2 ip.

For be able to host your application on linux you need to compile the policy server with mono and run it there.

We have already tested that, but unfortunately the Makefile for build policyserver with mono was not include yet in IceSl, most probably we will include a Makefile for build PolicyServer with mono and posible a mono binary policy server in next IceSl release. Meanwhile you could use the attached Makefile.gz to build policyserver with mono from sources.

Just download IceSl-0.3.3 sources
unzip sources
untar the attached Makefile.gz there

cd IceSL-0.3.3/sl/src/PolicyServer
tar xvf Makefile.gz
make

Then you could run it with following command

mono ../../bin/policyserver.exe 0.0.0.0 ../../bin/PolicyResponse.xml
Policy Server started...
Accepting Policy Requests...

Note that in linux policysever.exe need to be run as root as it binds to a privileged port < 1024

Hope this help and let us know if you have more questions with this setup,

Regards José

[JvD]

Hi José,

There is on thing that I do not understand in your reply. You say that the policyserver must listen to the same IP address as the server where the client is hosted. But in my situation this is exactly the case:
1. Machine 1: running the server and glacier2.
2. Machine 2: hosting the silverlight client and running the policyserver.
Inside the code of the silverlight client the Ice.Default.Router property points to the machine with glacier2. The policyserver is started using 'policyserver 127.0.0.1 PolicyResponse.xml'.

In this case (which corresponds to the requirements of Silverlight2) a get the accessdenied exception.

On machine2 I run Visual Web Developer with the solution of the Galcier2-callback demo. I run the silverlight client from Visual Web developer.

Could you explain why I get an exception in a situation matching the requirements.

Best regards, Joost

[xdm]

Hi Joost,

You are right the requisites are incorrect , Silverlight required that the policyserver listen on the target site. in that case the Glacier2 adddress.

We should fix this requisites in IceSl and ChatDemo releases thanks for pointed this.

If the connection request was from sockets to the site (cross-domain or site of origin), the Silverlight 2 runtime tries to open a connection using TCP to a well-known port (port 943) on the target site. If a TCP connection can be established, the Silverlight 2 runtime sends the special string <policy-file-request/> to the server to request a Silverlight policy file. The Silverlight 2 runtime then waits to receive a reply from the target site that contains a Silverlight policy file. If this Silverlight policy file is returned (even if there is an error in parsing the file), it is used as the policy file for that socket request and all subsequent requests to that target site for the entire session of the Silverlight application.

From Silverlight 2 doc Network Security Access Restrictions in Silverlight 2

[JvD]

Hi José,

Thanks for the reply. It is now clear to me. I have one more question considering the use of the policyserver as you described:

In case of using glacier2 to get through firewalls, the server side firewall has to forward a port to the glacier2 router. In the Silverlight scenario one other port has to be forwarded to make sure the policyserver is reached. And also it is only possible to use one policyserver since the policyserver uses a fixed port.

Are the two consequences I stated here true?

Regards, Joost van Doorn

[xdm]

Hi Joost

In Galcier2 host you should allow connections to port 943 used by the policyserver and to Glacier2 port, this both should be listen in the same public address that is reachable from clients network.

Is right that you could only run one policyserver per network interface as the port is fixed.