
OTP Supervision tree:
====================

The application is now split in two (see tsunami-inside.png for an overview):

** a single controller (tsunami_controller)

 * ts_mon (gen_server). Each client send reports of stats to this
   server. Several types of messages are handled by ts_mon.

 * ts_timer  (used by ts_client_rcv when ack is global) (gen_fsm)

   servers used to construct messages:

 * ts_req_server (gen_server) can generate messages extracted from an external file 
 * ts_msg_server (gen_server) 
 * ts_user_server (gen_server) used by ts_launcher and jabber_* for unicity of users id

** several clients (tsunami) Several nodes can be used simultaneously

This application is simpler:
  
 * ts_launcher (gen_fsm) launch simulated users.

 * 2 process per simultated client (ts_client, ts_client_rcv), under
   the supervision of ts_clients_sup ( using simple_one_for_one )

Main modules:
============

   1/ ts_launcher. the master process that spawns other simulated clients:

   1.1/ client processes: at each simulated client correspond 2 erlang
        process: 

           a/one that will initiate TCP (UDP) connection and will send
           messages (ts_client module). These processes are spawns by
           ts_launcher (using an sleeping time between two clients
           following an exponential distribution).

           b/ Each of these process will spawn a new process to handle
           incoming data from the server (ts_client_rcv module).

	    The total number of clients (NCLIENTS) can be changed in the
	    config file. It represent the total number of clients that
	    will be launched, and not the maximal simultaneous number of
	    client.

	  Warning: All the messages for a user session are computed by
	  ts_launcher, just before spawning the user process (in a
	  list). Therefore, if the number of messages is huge, it can
	  takes A LOT of memory. If you want to do very long experiments,
	  use a single 'dynamic' messages (see jabber_dynamic and
	  Jabber.txt for an exemple), which will be send over and over by
	  the user.

      Important parameters for Jabber :
         1/ chat messages size, in bytes (250 by default) 

         2/ mean time elapsed between two consecutives messages sent by a user

         3/ number of messages sent by a user during a session

   1.2/ monitoring process (ts_mon)

   2/ statistical module (ts_stats)

   3/ a generic module for building user sessions (ts_profile)

   4/ protocol-specific modules (jabber_online or ts_http, for example).

How to add a new protocol, or extend an existing one: 
====================================================

    A protocol has to implement the API defined in profile.erl, ie.
    must implement these functions:
	 - get_client/2
	 - get_random_message/1

    If you have to parse the responses from the server, two other
    functions has to be implemented:
	 - parse/2
	 - new_session/0

References:
==========

  - Erlang

  http://www.erlang.org/

  Design principles: 
    http://www.erlang.org/doc/r7b/doc/design_principles/part_frame.html

  - Jabber

  http://docs.jabber.org/general/html/protocol.html

  
  - Stochastics models:

  For more details on stochastics models and application to Web
  workload generators, take a look at:

    Nicolas Niclausse. Modlisation, analyse de performance et
    dimensionnement du World Wide Web. Thse de Doctorat (PhD), Universit
    de Nice - Sophia Antipolis, Juin 1999.
    http://www-sop.inria.fr/mistral/personnel/Nicolas.Niclausse/these.html

	Z. Liu, N. Niclausse, C. Jalpa-Villanueva & S. Barbier. Traffic
    Model and Performance Evaluation of Web Servers Rapport de
    recherche INRIA, RR-3840 (http://www.inria.fr/rrrt/rr-3840.html)


