response to your post on LJ re zeroconf-based formation/management feature...

[Ryan T. Dean]

--oXNgvKVxGWJ0RPMJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 09, 2003 at 11:03:10AM -0400, Justin Matlock wrote:
> This sounds like a great idea, from a very high level.  But I can't think=
 of
> a way to make this work with the PHP API, simply because it's completely
> stateless. There's not really any easy platform independent way to store
> data from one PHP script to the next, much less between different PHP
> processes running under different Apache threads.  I guess shared memory
> would work, but... I see some issues there, as well (Windows doesn't have
> shared memory, being one).
>=20
> It would suck to have to 'rediscover' all of the memcached servers every
> time a script starts up.
>=20
> One way this could happen is maybe have a "master" memcached server, that
> used multicast to find other memcached servers.  Have the clients contact
> that master server at script start up, get the list, and use it to spread
> the load.... but that's still a network call.   Or, use shared memory on =
the
> web server, and have it 'expire' every 10 minutes... when that 10 minutes=
 is
> up, it just fetches a new list from a master server?  Or, simply have
> memcached write a temporary file (actually a script) that is just included
> with every script (this, of course, opens up all sorts of scary security
> implications -- I know I wouldn't want my sites creating 'scripts on the
> fly', especially since my webservers are AFS mounted read only).
>=20
> I dunno... it's just something to keep in mind... I don't know how mod_pe=
rl
> is -- but PHP is completely stateless... when a script ends, any
> variables/etc are gone.


I can't think of any easy ways to store a server list from request to=20
request.  The only ways I can think of, off the top of my head, are...

   a) shared memory, be it through the sysvshm functionality or the=20
      shmop functionality

   b) writing out a .php file that gets include()'d

   c) writing out a text file (to the filesystem or to a memory-based=20
      disk) and parsing it out on every run.

Aside from that, I can't think of a way to hold the variables between=20
script executions.  The limited functionality PHP has for inter-module=20
communication (apache_note(), apache_setenv(), setenv()) all keep track=20
of what was done and un-does it at the end of script execution.

Of all of the options above, b is probably the least secure, and a is=20
probably the fastest.  b and c could (theoretically, at least) work on=20
multiple webservers at once (using the same file shared via nfs or afs),=20
while using a you would have a shared memory segment on every webserver.

Then, of course, is discovery.  Do we hard-code a master server that we=20
can do a lookup on to find all the other clients?  Do we broadcast a=20
multicast packet (assuming this is even possibly in PHP, I'll have to=20
check) and find all of the servers?  Or just a server, and then we poll=20
it for all the available servers?

I could maybe see downloading the server list every time from a master=20
server - LJ does this from MySQL, doesn't it?  For all its MySQL=20
servers? - that might not be too expensive.  But we still need a server=20
to poll from, which means hard coded or broadcast discovery.

As to memcached server(s) answering a request on what servers are=20
available, I imagine a flag could be added to memcached which takes a=20
ip:port argument, and then the server on startup would connect there and=20
announce its availability.  It could then download a copy of the current=20
server list, or the 'master server' could push it out onto all of the=20
slaves...  Alternatively, there is of course multicast traffic for=20
discovery.  But thats more out of my area.  :)

In any case, thats what I've got for the moment.

		-Ryan T. Dean

--oXNgvKVxGWJ0RPMJ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQE/hYVUW6VZzwycJGURAmguAJ9LgZn0RKDtfCnIZ56vP/vdwk85lACaAlbq
NLoVUHYErXG+M5z2G3Zxz0k=
=Y0St
-----END PGP SIGNATURE-----

--oXNgvKVxGWJ0RPMJ--