>Kaz,
>It depends on what type of application server you are using.
Nah, sorry, but the problem in Kaz' setup does not have to do with the
live-servers behind pen. The problem is that pen uses the same
live-server as last time, if the request comes from an IP which has
accessed a live-server through pen before.
>[...]
>I believe that Pen has the capability to not associate an IP with a
>webserver (most people call this capability "stickyness"; obviously you
>would want "un-stickyness" to prevent the load balancer from making the
>association).
As his question is aiming towards https:// sessions, I doubt it would
help to modify Pen so that it does not act "sticky" anymore. What you
mean would be a simple round-robin-thing, it's possibly quite easy to
get rid of the code in Pen that makes Pen be more than just a
round-robin rinetd, but that probably wouldn't help with https://
sessions.
>If your webserver stores session data in a database, then you should be
>able to do what you're asking. This is strictly speaking from a
webserver
>perspective; I haven't fully examined the Pen man page (although I'm
pretty
>sure that you can do this with pen).
I'm pretty sure that you cannot do this with Pen. To make Pen be a
round-robin rinetd it would be necessary to dig in the code, besides it
most probably wouldn't solve his problem.
>Brantley Hobbs
From my point of view, the only thing that would help Kaz would be to
convince the admin of those networks, that tunneling https:// through a
proxy does not make a lot of sense. But as their firewall is probably
doing NAT on outside connections, that wouldn't help either, because
then all request would come from that NAT IP rather that the IP of the
proxy.
The only thing that I could imagine that could solve Kaz' problem would
be a high level protocol load sharer (F5, Allot, TopLayer, maybe
Rainfinity). The problem is, that you probably won't get such for less
than 20.000 $US.
Torsten
This archive was generated by hypermail 2.1.2 : Wed Sep 18 2002 - 09:25:23 CEST