Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

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