tmodel is an application for modeling various types of Internet traffic. There is one executable, tmodel, which always operates as a server (see detailed descriptions for client and server roles in this application). If you specify a configuration file, tmodel will also operate as a client and initiate all traffic modeling sessions.
tmodel heavily uses the TCPLIB software package for generating random numbers based on cumulative distribution functions. The full TCPLIB package and documentation is available off of Sugih Jamin's papers page: http://irl.eecs.umich.edu/jamin/papers/
The HTTP traffic model is based on the work of Bruce A. Mah at UC-Berkeley. His work is available here: http://http.cs.berkeley.edu/~bmah/Software/HttpModel/
tmodel can be found in /home/borg/tmodel/ on FreeBSD machines,
/net/buzzard/dirt/borg/tmodel/ or ~borg/tmodel/ on AFS machines.
Underneath this directory, in src, is the latest source code.
Running tmodel is simple:
tmodel [-d] [-p##] [filename] (Default port = 6789)
The -d option throws the program into a debug mode, with
more verbose output.
The -p option allows you to specify a particular port to start
the server on. Note that tmodel will always spawn
a server (for some traffic models, the client must also have a server
ready to accept connections), so be wary of starting multiple instances
of tmodel on the same machine. You must specify different
ports for them to listen on.
The default port is 6789.
If a configuration filename is specified, tmodel spawns client processes to handle the sessions specified in the file. A detailed discussion of configuration files follows...
HTTP traffic
consecutivedocs: The number of consecutive documents, or pages, that the surfer will visit for his/her stay at this particular site.
filesperdoc: The number of files contained per document, or page. This simulates graphics, etc., contained in a page for which the surfer's browser must establish additional connections to receive all the data.
primaryrequest: The size of the initial "request" sent to the server.
primaryreply: The size of the first file in a page sent back to the surfer.
secondaryrequest: The size of subsequent "requests" made to the server.
secondaryreply: The size of the subsequent files sent back to the surfer.
thinktime: The length of time a surfer thinks before requesting the next document, or page.
FTP traffic
nitems: The number of items requested from a server at any given time. Similar to the filesperdoc quantity for http.
itemsize: Modeled for each item, this is the size of the file to be sent back to the client.
ctlsize: Size of the request packets and other control packets passed between the client and the server.
TELNET traffic
Sample configuration files are in /home/borg/tmodel/ on the FreeBSD machines (that's /net/buzzard/dirt/borg/tmodel/ or even ~borg/tmodel/ on AFS accounts).
Each line of each client specification is in the form
fieldname:value
Note that no spaces are allowed between the fieldname and the value.
Note also that all client specifications must end with a single "#"
on a line by itself.
Furthermore, multiple clients may be spawned from
the same clientfile by simply stringing client specifications together,
separated by single "#"'s on lines by themselves.
(These are all just the way my parser was hacked together ...
there are no comment lines.)
All traffic types can specify the following fields: (fields with a * are required fields)
port: The target (server) port number. (Default: 6789)
traffic*: The traffic type.
sbuffer: The size buffers to use on each side.
delay: The time (in seconds) after the client has been spawned until the time the traffic simulation begins.
duration: The length of time to run the simulation.
Bulk traffic
HTTP traffic
connection:{multiple,static}: multiple is the way current browsers work: a new connection is created for each file contained in a document. static is for the next generation of browsers: a single connection is maintained. In general, use "multiple". I think "static" may be broken.
interarrival: The exponential mean of the thinktime (in secs) between http sessions. The http model only models a browser's habits on a single website. When the model finishes, we want to start over again (simulate a new user hitting the website). I use "0". This means a new user hits the site as soon as the last one leaves.
FTP traffic
interarrival: The exponential mean of the thinktime between ftp sessions. This is exactly the same as the quantity for HTTP sessions. I have been using "9" just because.
TELNET traffic
Undoubtedly, someone is going to have to hack this up a bit, especially due to a lack of meaningful data statistics. It should be relatively easy to figure out, though. It's a very linear and mundane design ...
tcpt.h
main always forks a server process, and if a client file is specified, calls...
parse_client_file, which chugs through the file and spawns a client process for each entry.
One item of note about telnet: the telnet_timer_handler() routine does most of the dirty work, and is called by telnet(). All timing is done using usleep(), so there aren't any signals or complicated timers to deal with, despite the name telnet_timer_handler().
handler() is the main routine that sits and waits for connections. This routine calls the handle_* routines as it determines what type of traffic is being run on this connection. Note that for many traffic types, the server establishes its own unique connection to the client for the response-stream. Typically, this is handled by the sink routine. sink can probably be greatly modified for receiver-side statistics (hint hint).
traffic_type.h: this contains data structures of the actual cumulative distribution functions for each of the modeled data types.
traffic_type.c: the stubs for each of the modeled values. This file basically wraps the tcplib() routine, passing in a cdf defined in the corresponding traffic_type.h file.
The tcplib documentation contains detailed instructions for producing new libraries for new traffic types.
Good data for telnet and ftp is probably better obtained within the handle_sink() routine.