A question

[Isabella Pighi <is...@db.com>]

Does Flood reuse SSL session id's for ongoing connection requests to the same server? Or does Flood leave it empty for all new requests thus forcing regeneration and exchange of session keys and other related data?

I am doing some test over here and we are desperately looking for a tool which does it (which keeps sessions I mean).
If  sessions are destroyed anytime the system is overloaded to much and the test is not significant at all (actually users keeps sessions during browsing)

It's just and idea.

Thank you for your help.

Isabella


--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Re: A question

[Aaron Bannert <aa...@clove.org>]

On Thu, Dec 06, 2001 at 07:10:40PM +0000, Isabella Pighi wrote:
> Does Flood reuse SSL session id's for ongoing connection requests to the same server? Or does Flood leave it empty for all new requests thus forcing regeneration and exchange of session keys and other related data?
> 
> I am doing some test over here and we are desperately looking for a tool which does it (which keeps sessions I mean).
> If  sessions are destroyed anytime the system is overloaded to much and the test is not significant at all (actually users keeps sessions during browsing)
> 
> It's just and idea.
> 
> Thank you for your help.

To answer your question: No, flood has no session cache and will
renegotiate SSL sessions for each new connection. However, multiple HTTP
requests can be pipelined over one connection (aka "keepalive").

Having a client-side session cache may be something we will want to
optionally include for flood, but it doesn't seem like something that is
totally legitimate for what flood is trying to do. If one were trying
to load test the capabilities of an SSL server to handle a number of
simulated users, then reusing the same SSL session would inaccuratly
skew those results.

Consider this particular user profile:
1. open keepalive session to fetch foo.html
2. optionally open up to 3 other keepalive connections and service all
   subrequests (images, etc) from foo.html over those pipelines.
3. pause some random amount of time (representative of real user interactions
   on the particular website).
4. Repeat at step 1. with a new URL linked from foo.html

Now run this in parllel 100 times with random staring times and maybe
shuffle the URLs around a little bit, and you've got essentially 100
simulated users concurrently accessing the site. (One might point out
that at one time only a few users may be simultanously transfering data,
but from the user's standpoint they are all fully interacting with
the website.)

It would make sense, from the standpoint of properly emulating a real
user, to cache the session used in one thread (aka "farmer") as it
iterates through the above loop. I'd like to see something like this
added to flood, but I can't volunteer to do it right now. Of course,
you or anyone else are welcome to submit patches. :)

-aaron