Not sure how you are configuring your network but your "load balancer"
domain name should be the domain name of your servers so it shouldn't
be a problem.
browser/applet -----> (xyz.com) loadbalance ----> cluster
In this case there is no security problem since the browser/applet is
sending requests to one server.
If the load blancer is configured to keep the cluster machine sticky
then all you have to be sure of is that the technique that it uses to
track the stickyness is supported by your applets request. Say that
the load balancer uses an embedded cookie to track the request you
need to make sure that that information is sent back in each request
to enusre that the load balancer can react accordingly. If this cookie
is not sent then the second request will be treated as new.
All load balancers balance connections, the difference is how the
sticky algorithm works. Remember that the source IP's of many of your
customers can be the same when they all sit behind the same proxy
server, so the application level is the only level that will work for
sticky tracking. The info has to get back to the users browser and get
resubmitted again.
But this doesn't sound like you problem. If your load balancer is not
treating the second request as sticky then you would just get a new
session, not a security exception. The problem must reside in your
applet and how it determines the domain name to make the request to.
It needs to get this from the getCodeBase or getDocumentBase method
and only make requests to this domain.
On 11/19/06, Ashish Narvekar <ashish.narvekar@xxxxxxxxx> wrote:
Yup,
the sessions are sticky. So, if the load balancer also balances pure socket
calls, it has to be in synchronization with the http load balancing (maybe
would happen automatically if it is the same load balancer doing the work
for both).
Thanks.
On 11/19/06, Johnn Tinch <JTinch@xxxxxxxxxxxxxxxxxxxxx> wrote:
> Are the sessions set to sticky on the load balancer?
> --------------------------
> Sent from my BlackBerry Wireless Handheld
>
>
>
> -----Original Message-----
> From: Ashish Narvekar <ashish.narvekar@xxxxxxxxx>
> To: users@xxxxxxxxxx < users@xxxxxxxxxx>
> Sent: Sun Nov 19 21:48:59 2006
> Subject: [cinjug-users] Unsigned applet question
>
> We have an unsigned applet that creates a socket connection (new
java.net.Socket) to the host that it was downloaded from. This works fine in
a single server environment. However, if we try this in a clustered
environment where there is a load balancer in front of the appservers, this
obviously does not work and we get a security exception because the console
shows it as being downloaded from the load balancer and is trying to connect
to the appserver which is a different host (which violates the default java
policy on the client).
>
> The reason we don't want to sign the applet is that most of the users of
the app are minimalist users and we have got panic calls in the past when
they have been faced with 'expired certificate' or other such messages. And
for the same reason, editing the client java policy file is also not an
option.
>
> Is there any way to still use an unsigned applet for the scenario
described above? Is there any load balancer out there which can load balance
not just http invocations but also, pure socket connection invocations.
Then, I could try and have the applet code always make a connection to the
loadbalancer and the loadbalancer would load balance to the appservers. I am
not sure if this is even viable.
>
--
Ed
|