Rebol/command, fastCGI, session id, frames, etc....
[1/8] from: petr:krenzelok:trz:cz at: 23-Jun-2001 21:12
Hi,
today, I discussed our possible test Rebol/Command scenario, with my good
friend - Linux folk. We discussed the needs for serving our customers
requests via creating sessions, and I would like to ask following questions:
- of course he suggested me tools he knows and uses, which handle user
session issues - php, Java. AFAIK RT doesn't provide so called "added value"
to their products (additional XML tools, e.g. SOAP), etc. So - just only one
question here - am I on my own when I want to create session mechanism, when
using Rebol?
- has anyone solved anything like that in Rebol?
My friend suggested me to be aware of following problem areas:
- if you e.g. use frames, your browser sends three simultaneous requests to
web server, so you have to take care of it
- what if user opens second browser instance (or window) and sends second
request to web-server? What if result of such request is some database
operation?
- user presses "reload" button, while web server already handles previous
request, performing some database operation
- what is probably even worse, Rebol doesn't provide ipc mechanism (although
we can use fs sharing, tcp connection, or database for such purpose) and
when running in FastCGI mode, web server sends incoming request to one of
existing Rebol instances, which, in turn doesn't know of session states
handled by another one Rebol instance ...
All in all - I am starting to be afraid, creation of session mechanism in
Rebol will not be all that easy task and makes my situation overall harder
in comparison to free solutions, supporting sessions, various XML protocols
etc.
Has anyone used /Command for similar purposes? I would like to know possible
solutions, to better prepare to fight Rebol/Command position here ...
Thanks,
-pekr-
[2/8] from: agem:crosswinds at: 23-Jun-2001 21:30
RE: [REBOL] Rebol/command, fastCGI, session id, frames, etc....
Hi pekr,
there is ipc if there is tcp.
have a look at %lock-file.r in the reb-library.
Purpose: "To provide functions for voluntary resource locking in rebol"
it runs a on a seperate rebol as server,
you can lock and unlock names via network.
so if each user has a "name", you could
lock him and unlock if request finished.
other operations started have to fail or wait
when user locked.
should work even with multiple fast-cgi-rebols.
(i think similar stuff could be done with rugby?)
also there is a script %auth.r on rebol.org
which says
Purpose: "Provides secure authentication of users over a TCP connection"
had only a short look. communicators are rebols.
maybe somehow adaptable to html/cookies and that?
both by Cal Dixon
no idea about multi-requests for one frame yet.
-Volker
[petr--krenzelok--trz--cz] wrote:
[3/8] from: petr::krenzelok::trz::cz at: 23-Jun-2001 22:21
Hi,
thanks a lot - I am just discussing other possibilities with Allen in RIM
conference. Maybe another option is to completly bypass sessions at all?
Allen thinks sessions don't scale too well.
So what about using some form, hiddent field, post method, and some kind of
encrypted string (containing info about time, for detection of timeout),
which would be sent to page each time?
Thanks,
-pekr-
[4/8] from: gchiu:compkarori at: 24-Jun-2001 11:56
On Sat, 23 Jun 2001 22:21:27 +0200
"Petr Krenzelok" <[petr--krenzelok--trz--cz]> wrote:
> thanks a lot - I am just discussing other possibilities
> with Allen in RIM
> conference. Maybe another option is to completly bypass
> sessions at all?
> Allen thinks sessions don't scale too well.
Why not?
> So what about using some form, hiddent field, post
> method, and some kind of
> encrypted string (containing info about time, for
> detection of timeout),
> which would be sent to page each time?
>
These are just ways of implementing session handling.
If I had to do this, I would probably use cookies. And of
course advise the end user that cookies need to be enabled.
Hidden fields mean that every page has to be posted, and
mangling the URL is ugly.
So, something like this
1. browser request - no cookie? create new session id and
send cookie which holds the session id
2. store session id in session table with time stamp
3. has cookie - check to see if valid session id, and if it
is, update time stamp in session table. If not, create new
session id.
4. periodically remove expired session ids from session
table.
>From memory, session handling in PHP is done by cookies as
well.
--
Graham Chiu
[5/8] from: petr:krenzelok:trz:cz at: 24-Jun-2001 3:36
Hi,
found following on fastcgi.com website - maybe it would make our life
easier? Has anyone experience with session afinity patch for fastcgi mod on
Apache?
http://www.tfarmbruster.com/fcgi_sa.htm
Thanks,
-pekr-
[6/8] from: allenk:powerup:au at: 24-Jun-2001 13:50
----- Original Message -----
From: "Graham Chiu" <[gchiu--compkarori--co--nz]>
To: <[rebol-list--rebol--com]>
Sent: Sunday, June 24, 2001 9:56 AM
Subject: [REBOL] Re: Rebol/command, fastCGI, session id, frames, etc....
> On Sat, 23 Jun 2001 22:21:27 +0200
> "Petr Krenzelok" <[petr--krenzelok--trz--cz]> wrote:
<<quoted lines omitted: 21>>
> send cookie which holds the session id
> 2. store session id in session table with time stamp
Graham,
This is the point at which session handling does not scale well. The moment
you track anything on the server, you are reducing the scalability. Also
with a web app in largescale webfarm with load balancing there is no
guarantee that the same server will handle the next request from the client.
(Though there are some tools that try to make this happen with varying
success)
In ASP, sessions become even more dangerous to this scalability as it makes
incedibly easy and seductive to use variables within a session context. So
every current session could use 1k or so and under heavy load your windows
server uses up its memory in sessions and spends it time disk swapping the
virtually memory. And worse, a whole bunch of those are sessions from people
who aren't there anymore and probably left 5 minutes ago.
In designing session usage in REBOL it would be nice to avoid that,
particularly in fast-cgi.
These are extreme cases, but I was trying to explain that if Petr can design
a system that is largely stateless, just enough to recognise the validity of
the user at the current time the request comes through, then his system will
scale better. Storing & tracking session state on the server does not scale
well, was all I was trying to say.
Cheers,
Allen K
[7/8] from: allenk:powerup:au at: 24-Jun-2001 14:03
----- Original Message -----
From: "Graham Chiu" <[gchiu--compkarori--co--nz]>
To: <[rebol-list--rebol--com]>
Sent: Sunday, June 24, 2001 9:56 AM
Subject: [REBOL] Re: Rebol/command, fastCGI, session id, frames, etc....
> On Sat, 23 Jun 2001 22:21:27 +0200
> "Petr Krenzelok" <[petr--krenzelok--trz--cz]> wrote:
<<quoted lines omitted: 4>>
> > sessions at all?
> > Allen thinks sessions don't scale too well.
Petr they don't scale well. But if you aren't writing something on the scale
of E-bay, or expecting that level of load, or having your app working on
multiple server in a webfarm then you're probably aren't going to run into
trouble using sessions. I didn't mean to scare you off using simple session
state tracking, but if you can design your webapp to be as stateless as
possible then you know you could grow it to the that E-bay scale one day.
:-)
Cheers,
Allen
[8/8] from: allenk:powerup:au at: 24-Jun-2001 15:46
----- Original Message -----
From: "Graham Chiu" <[gchiu--compkarori--co--nz]>
To: "Allen Kamp" <[allenk--powerup--com--au]>
Sent: Sunday, June 24, 2001 2:33 PM
Subject: Re: [REBOL] Re: Rebol/command, fastCGI, session id, frames, etc....
> On Sun, 24 Jun 2001 13:50:35 +1000
> "Allen Kamp" <[allenk--powerup--com--au]> wrote:
<<quoted lines omitted: 27>>
> --
> Graham Chiu
The ASP model I'm talking about from ms IIS which is dangerous is holding
all those session vars in memory. ouch! Some developers even store entire
pages in a session var.
Graham what you are doing is fine. However you must also be aware that each
open connection to the db has a memory and look up time hit too. When does
the clean up happen? and is there a time/cycles cost there? Probably not a
big problem
Cheers,
Allen K
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted