× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  1.  Home
  2. MIDRANGE-L
  3. June 2015

RE: 'green screen' not sellable --> WE(?) are the problem

This is not a windows limitation. It is a browser implementation detail.

http://www.browserscope.org/?category=network


-----Original Message-----
From: Bradley Stone [mailto:bvstone@xxxxxxxxx]
Sent: Thursday, June 11, 2015 1:01 PM
To: Midrange Systems Technical Discussion
Subject: Re: 'green screen' not sellable --> WE(?) are the problem

Another problem is most Windows PC limit to 4 (or is it 2?) connections at once... so if a page is loading images, running ajax, retrieving JS or anything else from a server it may not load as fluidly as possible. Not sure how *nix distros or iOS handle this.

As far as using session cookies, I've used them for years with great success. Just create 256 byte (or larger) random (but unique) keys and use that (as well as local IP address you can get from environment variables, or any other info) to tie it back to the info on the server side (ie, customer number, sign on info, etc). Base64 encode it too if you want. :)

Yes, someone could manipulate the cookie, but I doubt they'd figure out the proper 256 byte sequence to get logged onto someone else's PC as well as spoofing the local IP of the user.

Brad
www.bvstools.com


On Thu, Jun 11, 2015 at 10:40 AM, Henrik Rützou <hr@xxxxxxxxxxxx> wrote:

Nathan

<iframes> is not the problem, AJAX is since many modern UI's initiates
parallel AJAX conversations.

To illustrate that here is what happens when I fire up my Viewport.

The Viewport has an accordian menu where each main topic is an object
that is populated by the server through an AJAX call.

This means that if there are 5 main topics the client will fire five
AJAX call's to the server for the menu content under its topic.

What happens behind the scene is illustrated here:

http://www.powerext.com/RESTTIER0.png



On Thu, Jun 11, 2015 at 5:07 PM, Nathan Andelin <nandelin@xxxxxxxxx>
wrote:

Henrik,

Thanks for the reply. If I understand correctly, there are at least
two problems with "persistent CGI". First, when the "maximum"
threshold is reached, then existing "sessions" may be closed to accommodate new users.
The second problem is that developers may be forced to create some
rather unique plumbing in order to accommodate certain application
designs, such as using <iframes>, where each frame may need to implement AJAX.


On Thu, Jun 11, 2015 at 8:07 AM, Henrik Rützou <hr@xxxxxxxxxxxx> wrote:

Nathan



It is a combination of several things.



Normally the Apache server runs it QZSRCGI jobs under a common
userprofile
(serverUserId) in the config file. That is that the QZSRCGI job
actually
runs under user QTMHHTTP as job user id and the common user from
the
server
config as adopted/actual user profile.



The number of possible QZSRCGI jobs under and Apache instant is
also a config setting.



If all QZSRCGI jobs are active processing and a request comes in
the request I queued until a QZSRCGI job is idle.



When you set up the Apache to run persistent this scenario is changed.
QZSRCGI jobs now runs under the real user profile as
adopted/actual. A
new
request will cause apache to create a new QZSRCGI job for the
requesting
user.



When the allowed number of active QZSRCGI jobs is reached and a
new
user
makes a request the trouble starts. What Apache will do is to find
the first idle QZSRCGI job allocated to another user, close it
down and
start a
new QZSRCGI job for the new user. This will of course mean that
the
closed
job will lose persistency.



Now, today we run AJAX and AJAX may fire parallel requests from
one
client
against the Apache server. The Apache server will not queue this
request
for one QZSRCGI job but execute them in different QZSRCGI jobs and
that doesn’t matter if you run stateless or persistent.



So suddenly one user may have a number of in this case persistent
QZSRCGI
jobs and nobody knows which of the jobs are used for a single request.
This
will of course also add to the overhead of closing and restarting
QZSRCGI
jobs when the maximum threshold is reached.



There may be techniques to avoid this behavior, but as standard I
will
not
call it persistent.

On Thu, Jun 11, 2015 at 3:36 PM, Nathan Andelin
<nandelin@xxxxxxxxx>
wrote:


PS. If you run Apache there is no such thing as persistent CGI
but
that
is
another rather long story. If you like I could explain it.


Henrik,

Yes, I would be interested in your views about "persistent CGI"
under Apache. My understanding is that Profound UI uses it. And
it seems to maintain a session which may time-out after a period of inactivity.
What
makes you say there is "no such thing"?

BTW, I agree with your method of storing "session" variables in
an
IBM
i
DB, keyed by a secure value.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please
take a moment to review the archives at
http://archive.midrange.com/midrange-l.




--
Regards,
Henrik Rützou

http://powerEXT.com <http://powerext.com/>
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please
take a moment to review the archives at
http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please
take a moment to review the archives at
http://archive.midrange.com/midrange-l.




--
Regards,
Henrik Rützou

http://powerEXT.com <http://powerext.com/>
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...
Follow-Ups:
Replies:
Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.