Posted by Jon Slaughter on 06/11/07 05:40

"Gordon Burditt" <gordonb.d9hh2@burditt.org> wrote in message
news:136pmaodlf97bb3@corp.supernews.com...
>>> 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.
>

No... You have to have some way for the other servers to recognize who the
user is when he comes to their page. Now if he is required to log into each
server then thats ok.. But if you want one server multiple logins then its
more difficult... although I suppose you could just broadcast the login
information to each one and they can create there own session id(although it
will then be hard to synch if they all have different session ids.

I was just giving some ideas though. I do not by any means think its
impossible. Just might require a little work.

Jon

[Back to original message]