How to store per-session director data / VSLP director design

[Poul-Henning Kamp]

In message <4BAC9494.40909 at schokola.de>, Nils Goroll writes:
>Hi Poul-Henning,
>
>> Don't you overlook the fact that the active VCL may change between
>> two requests on the same session ?
>
>Hm. At this point I don't understand what I'd need to consider regarding a
>change of the VCL.

You may not have the same VCL code, directors or backends for all requests
on a given session.

That opens a number of cans of worms:

1. You cannot cache pointers to any of these bits between requests,
   unless as an opaque token (see uintptr_t use) that does not get
   dereferenced.

2. Memory allocated, needs to be freed.  A different VCL may not know
   how to do that.  Not that VCL is consulted about session retirement
   in the first place anyway.


My plan for the functionality you propose, is to add a "client.identity"
string variable you could set in vcl_recv{} and let the client
director operate on that string.  If the string is not set, client.ip
will be used, like today.

You get to decide what to put in the string: you can pull it out
of a cookie, X-F-F, from the URL or whatever.


I have also pondered a scheme where we cache an opaque cookie to
the last backend used in the session, and let directors attempt to
use this to gain affinity, since that could provide some stability
across a director modification (in a new VCL).

This is likely a lot less useful than you think, as many sites have
a separate backend for images and other primitive static content.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.