Mailing List Archive

Here is where I profess my ignorance about PHP. I am not sure how the PHP
session vairables are stored. I can image only one of two ways:

(1) in the requested URI (e.g.
http://example.com/path/to/script.php?sessionid=<sessionvariable>)

or

(2) in a Cookie (e.g. an HTTP headers like:
Cookie: sessionid=<sessionvariable>; path=/; domain=.example.com)

Either way, mod_backhand calls the candidacy functions with the Apache
request_rec structure. This structure contains headers and the URI, so with a
few lines of C, you will be able to extract the session "key" from either of
the above embedding mechanisms.

Because each application/site uses a different form of session tracking, there
isn't a default catch-all. It should be as simple as figuring out how your
application stores session state, decoding it and making a decision.

For example, store the hex encoded IP address of the server in a variable in
the sessions state. Then when the request comeback in, get the "Cookie"
header (out of r->headers_in) and look for the IP address. Hex decode it and
try to find it in the serversstats, if you find it (n) and it is alive, then
you just set servers[0].id = n; *n=1; return 1;

Then mod_backhand will choose that server over all others (assuming that this
candidacy function is called last. If you don't find your server alive in the
list, don't modify "servers" or "n" and just return *n;.

If anyone sets this up to work with PHP in particular, I would be very
interested in posting your PHP code and you candidacy function on the mailing
list and in the FAQ. We get this question alot :-)

Martin Domig wrote:
> I just came across mod_backhand while searching for a web-clustering
> solution for my site. mod_packhand looks great and just like the thing
> i was looking for, only that i haven't tested it yet.
>
> The question for I was looking an answer on the homepage is:
> Can I use mod_backhand with sessions? (PHP session variables)
>
> I.e. can mod_backhand be configured to redirect all requests of an
> established session to the same host over and over again?

--
Theo Schlossnagle
1024D/A8EBCF8F/13BD 8C08 6BE2 629A 527E 2DC2 72C2 AD05 A8EB CF8F
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7

mod_backhand wont work with PHP based sessions unless you are using a
network drive... As PHP sessions are file based .. So you will wind up
with missmatching session data as each request is backhanded to another
machine. I've been using PHPLIB sessions that are database based.. And
have had no problems for some time... (About a year?)


On Sat, 20 Jan 2001, Theo E. Schlossnagle wrote:

|Here is where I profess my ignorance about PHP. I am not sure how the PHP
|session vairables are stored. I can image only one of two ways:
|
|(1) in the requested URI (e.g.
|http://example.com/path/to/script.php?sessionid=<sessionvariable>)
|
|or
|
|(2) in a Cookie (e.g. an HTTP headers like:
| Cookie: sessionid=<sessionvariable>; path=/; domain=.example.com)
|
|Either way, mod_backhand calls the candidacy functions with the Apache
|request_rec structure. This structure contains headers and the URI, so with a
|few lines of C, you will be able to extract the session "key" from either of
|the above embedding mechanisms.
|
|Because each application/site uses a different form of session tracking, there
|isn't a default catch-all. It should be as simple as figuring out how your
|application stores session state, decoding it and making a decision.
|
|For example, store the hex encoded IP address of the server in a variable in
|the sessions state. Then when the request comeback in, get the "Cookie"
|header (out of r->headers_in) and look for the IP address. Hex decode it and
|try to find it in the serversstats, if you find it (n) and it is alive, then
|you just set servers[0].id = n; *n=1; return 1;
|
|Then mod_backhand will choose that server over all others (assuming that this
|candidacy function is called last. If you don't find your server alive in the
|list, don't modify "servers" or "n" and just return *n;.
|
|If anyone sets this up to work with PHP in particular, I would be very
|interested in posting your PHP code and you candidacy function on the mailing
|list and in the FAQ. We get this question alot :-)
|
|Martin Domig wrote:
|> I just came across mod_backhand while searching for a web-clustering
|> solution for my site. mod_packhand looks great and just like the thing
|> i was looking for, only that i haven't tested it yet.
|>
|> The question for I was looking an answer on the homepage is:
|> Can I use mod_backhand with sessions? (PHP session variables)
|>
|> I.e. can mod_backhand be configured to redirect all requests of an
|> established session to the same host over and over again?
|
|

Hi Everybody


On 0, "Theo E. Schlossnagle" <jesus@omniti.com> wrote:
> For example, store the hex encoded IP address of the server in a variable in
> the sessions state. Then when the request comeback in, get the "Cookie"
> header (out of r->headers_in) and look for the IP address. Hex decode it and
> try to find it in the serversstats, if you find it (n) and it is alive, then
> you just set servers[0].id = n; *n=1; return 1;
>
> Then mod_backhand will choose that server over all others (assuming that this
> candidacy function is called last. If you don't find your server alive in the
> list, don't modify "servers" or "n" and just return *n;.

Said, done.

> If anyone sets this up to work with PHP in particular, I would be very
> interested in posting your PHP code and you candidacy function on the mailing
> list and in the FAQ. We get this question alot :-)

Here you are:

I've hacked a "byPHPsession" handler into builtins.c. I could not get it to work
as a module because every access to the global serverstats variable caused
a segfault on my machine (the example byHostname.c did not work either). Getting
it to work as a bult in handler required me to change more than one file, and as
I am not used to handle diff/patch and a README.byPHPsession file is included,
there is a new .tar.gz to download. It still contains my changed byHostname.c,
so please think of that being trash.

Get it from:
http://domig.ims.at/otherstuff/mod_backhand-1.1.0a.tar.gz
** THIS IS NO OFFICIAL RELEASE! **

Some information about what happened:
As suggested, the host address is encoded into the php session_id. The handler
searches for that host address, searches for a matching host in mod_backhand's
structure and returns the correct server if found. This works only when the
PHP scripts encode the Host address correctly into the php session_id. A sample
is included in READMe.byPHPsession, included in the .tar.gz above.

Please note, I haven't tested this very lot yet. It just seems to work in my
test environment containing 2 Web servers. Some bad things might happen if the
host has more than one IP address assigned to it and the adress encoded by the
PHP script is not the same as mod_backhand sees in it's server information.
Some fizzling around with PHP should solve that problem if it occours.
I've done this on two i686 Debian-Linux (2.2r?), so I cannot confirm it to
work on other platforms as well.
Yet.


For more details see README.byPHPsession and the source (builtins.c).
Feedback is welcome. And, please, test it.

Greetings,
Martin

--
If the only tool you have is a hammer, every problem looks like a nail.

Concerning the serverstats==NULL for dynamically loaded candidacy functions:

Just as a note.. This is a recurring problem. It has something to do with
cached symbol resolution when calling dl_open twice, maybe. It looks like a
problem in the way Apache initializes its modules. It may just be saying that
becuase I have looked and looked and have not been able to find anything wrong
in mod_backhand :-)

A solution is to statically compile in mod_backhand and then you should be
able to dynamically load candidacy functions. I tis a trade off. Personally,
I think that if you run into this problem, it is still more flexible to leave
mod_backhand as a shared module and just build your candidacy functions in.

The strange thing is that I have only (heard of and replicated) this problem
on Solaris. I have it running on many many linux boxes for testing purposes
and I have never been able to cause the serverstats==NULL problem. Hmmm.

Martin Domig wrote:
> I've hacked a "byPHPsession" handler into builtins.c. I could not get it to work
> as a module because every access to the global serverstats variable caused
> a segfault on my machine (the example byHostname.c did not work either). Getting

--
Theo Schlossnagle
1024D/A8EBCF8F/13BD 8C08 6BE2 629A 527E 2DC2 72C2 AD05 A8EB CF8F
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7

On 0, "Theo E. Schlossnagle" <jesus@omniti.com> wrote:
> Concerning the serverstats==NULL for dynamically loaded candidacy functions:

It isn't a serverstats==NULL problem, the module segfaults when accessing the
serverstats variable in ANY way. For example the following snipped segfaulted
on my system:

if(serverstats) { ...

I've post-compiled mod_backhand and byHostname using apxs. Perhaps this
doesn't work when both the mod_backhand and the byHostname modules are post
compiled? Humm...

Greetings, Martin

> Just as a note.. This is a recurring problem. It has something to do with
> cached symbol resolution when calling dl_open twice, maybe. It looks like a
> problem in the way Apache initializes its modules. It may just be saying that
> becuase I have looked and looked and have not been able to find anything wrong
> in mod_backhand :-)
>
> A solution is to statically compile in mod_backhand and then you should be
> able to dynamically load candidacy functions. I tis a trade off. Personally,
> I think that if you run into this problem, it is still more flexible to leave
> mod_backhand as a shared module and just build your candidacy functions in.
>
> The strange thing is that I have only (heard of and replicated) this problem
> on Solaris. I have it running on many many linux boxes for testing purposes
> and I have never been able to cause the serverstats==NULL problem. Hmmm.

--
If the only tool you have is a hammer, every problem looks like a nail.