Hi ,

Recently we had to ask our hosting facility to generate cookie on load 
balancer , F5, to maintain sessions. It worked fine . We had to do 
nothing on application end.
Load balancer inserts a session cookie for each connection and than 
maintains session to the proper back-end using this session cookie.
Is it possible to insert session cookie in pound based load balancer ?

Regards



[...]

aT schrieb:
[...]

Hi,
[...]

This sounds like a great feature. Actualy we have the problem that we
use pound to serve request to a shared webhosting platform. We don't
know if there is a session cookie and the name of it, so we use TYPE=IP
for session tracking. But a session cookie generated by pound would be
the more gentle way, I think.

Regards,

Falk

Falk Brockerhoff wrote:

  aT schrieb:

  
  
    Hi ,
    
  
  
Hi,

  
  
    Is it possible to insert session cookie in pound based load balancer ?
    
  
  
This sounds like a great feature. Actualy we have the problem that we
use pound to serve request to a shared webhosting platform. We don't
know if there is a session cookie and the name of it, so we use TYPE=IP
for session tracking. But a session cookie generated by pound would be
the more gentle way, I think.

Regards,

Falk


  

Type=ip will fail most of the time as a lot for
countries/organizations  use proxy servers or NAT , which could create
problems in type = ip

It would be great if inserting session cookie is available in pound. 

Cheers



[...]

At Musicmatch, we used cookie based sessioning for a long time with pretty
good results.

More recently, however, I have become a fan of IP based session assignment.
My reasons are:

A) the load balancing is just about as good since even though some pretty
large groups are behind a single NAT, this is balanced by other groups
behind different NAT's.

B) it works for people who refuse cookies.


The upshot is that it feels about the same and doesn't share the key failure
mode of cookie based load balancing.


On 10/3/06 3:33 AM, "Falk Brockerhoff" <noc(at)smartterra.de> wrote:
[...][...][...][...][...]

On 10/3/06 4:00 AM, "aT" <pakistan(at)gmail.com> wrote:

[...]

Actually, type=IP SUCCEEDs most of the time.  It balances some groups of
users as groups rather than as individuals, but if you have enough traffic
to really need load-balancing, you probably will be fine with IP based
balancing.

I know that IP based balancing is theoretically not as sound and there are
indeed situations that provide a challenge (especially if ywhen balancing
internal traffic from just a few hosts).  In practice, it works very well.

Remember that cookie based sessions will fail for a significant number of
users.  One client I had reported that 20% of visitors were disabling
cookies in some fashion or other.  IP based sessions definitely work better
than 80% of the time.
[...]

It is always nice to provide people with options.

On Tue, 2006-10-03 at 11:36 +0400, aT wrote:[...]

I must admit I am really puzzled by this: why exactly is it needed?

If you have some sessioning mechanism Pound will happily use it: cookie,
URL, header or identity. You don't need to change your application in
any way - just tell Pound what is it you use and you're done.

For those very few cases where this doesn't work (for example when your
application uses more than one mechanism at the same time) Pound offers
the IP-based sessions. This works always, though the balancing is less
than perfect. If you have enough traffic this is not a problem.

On the other hand if you have no sessioning mechanism you obviously have
no sessions, and you need none. Adding a session cookie here brings no
advantages.
[...]

Yes, it would be possible, but not particularly easy or simple. I
suggest you start with a very convincing explanation why would it be
desirable.[...]

In my experience, we used a load balancer determined session cookie to
balance things because there were various implicit session state variables
that were helped by more locality of transactions.  I am referring to cache
state and such.  When a user sticks to one machine, then the caches adapt to
that users behavior and you get better performance than if the user hops
around.  The server, however, has no idea of session.

In my current systems, we have a large Lucene index that is incrementally
updated each minute.  Some real-time updates are stored locally for up to
several minutes (and then thrown away) to give the appearance of an
instantaneous update.  This bridging cache only works if the user comes back
to the same machine over the time scale of the incremental update.

In all of this, I have less and less desire for cookie based session
persistence.  As I mentioned before, if you have high enough volume, the
balance based on IP is plenty good enough and if you don't have high volume
then you by definition can accept higher imbalance because you have to have
more spare capacity (i.e. If you need 2 servers, then you really need to
have 4 so that one can be off-line and still have some reserve ...
Alternately, if you need 30 servers, you probably will only have 35-40
on-line which is much less than the 50-100% spare capacity of the smaller
system).

All in all, I really don't find that there is a very big need for this
feature in pound itself.  If you really, really want it, you can just have
your backends push a random session cookie down to the browser.



On 10/3/06 9:47 AM, "Robert Segall" <roseg(at)apsis.ch> wrote:
[...][...][...][...][...]

I've always thought that a fallback mechanism would be great.  If  
Cookies are disabled fallback to IP, etc.  That way you could cater  
to many different configurations.

-Blake

On Oct 3, 2006, at 10:27 AM, Ted Dunning wrote:
[...]
>>> Hi ,
>>>
>>> Recently we had to ask our hosting facility to generate cookie on 

>>> load
>>> balancer , F5, to maintain sessions. It worked fine . We had to do
>>> nothing on application end.
>>> Load balancer inserts a session cookie for each connection and
than
>>> maintains session to the proper back-end using this session
cookie.[...]
>>> balancer ?[...][...]