Posted by Gordon Burditt on 06/11/07 05:10

>> The problem here is the remote servers will have no idea what the current
>> status is from the central server - they'll have no way to communicate
>> anything, even the session id.

Assuming you can solve the problem of the session identifier
(something that can be dealt with by making the servers all have a
common domain with different subdomains), it is possible to use a
session save handler to store the session data in MySQL, not a local
file directory. This has potential to make the session data available
to multiple servers (a setup commonly used with round-robin DNS to
spread the load over several servers serving identical content).
You might have locking issues with changing the content of the
session, though. That might be solved with key changes (logging
in, logging out) handled by one specific server.

If you insist on no more than one session per user, you can use the
user id as a key for locating session data.


>Why is this? There surely could be something implement sorta like
>callbacks... or ajax.
>
>essentially on the remote computer you have a php script that is called by
>the central server when something chances or to pass on information. The php
>script then could either write them to a file or use shared memory or maybe
>run in the same process space as the session.

Having the central server call all the other servers can give you trouble
if one of them goes down. (On the other hand, a central database can be
a single point of failure for the whole group of systems if not designed
carefully).

>Sure there would have to be negotiations at the start but I don't see a
>problem with it. Instead of passing session through a url, say, your doing
>it over a remote connection.
>
>For example,
>
>User logs into RS(remote server). RS establishes a "session ID" for this
>user and calls central server and passes this session ID. All other servers
>are signaled that this user as logged into this server(or they could request
>each time a user logs onto them). Every time a state is changed its
>reflected back and forth. This isn't optimal of course and technically isn't
>probably very good but it should work.

I prefer to stick all this information in a database where the various
servers can access it. If necessary, the database can be replicated.

>The main problem, I suppose, is creating a unique ID for the user. Would
>have to atleast be the IP but then that causes problems with proxies and
>stuff. Maybe there is a way though...

If a user is required to log in, his user id may serve that purpose.

>I really don't see the issue though. After all you could have two servers
>running on the same computer but one listens on a different ip. Surely they
>would not have any issues sharing a session? (it might require some new
>software to handle it efficiently though) Doing it remotely shouldn't be
>that much more of a problem(aside from the security issues).
>
>of course I could be missing something but I don't think your reasoning is
>valid as its pretty easy to synchronize status.

[Back to original message]