maryam hasan wrote:
> Dear Mr. Kegel,
> My MSc?s Thesis is about firewall performance
> testing. I want to generate http, ftp and smtp load
> separately through the firewall. I read your ftp
> benchmark code, and decide to use your method for
> generating these loads, But with using real
> distribution file size and measuring throughput
> besides concurrent connections.
> Could you give me some advice. Can I use your
> design to generating http, ftp and smtp load and
> measuring throughput and concurrent connections. If it
> is possible please send me your design and say me
> which changes needed.

Hi Maryam,
my code currently does only ftp, but I've been considering bringing it
up to date and adding http and smtp support as well, and maybe
banging together a transparant proxy as a demo.

In general, I would have a class to represent a protocol unit
(e.g. an HTTP request, an SMTP mail/rcpt/data group, or an FTP command),
a class for the server end of a protocol connection (e.g. HTTPListener),
a class for the client end of a protocol connection (e.g. HTTPTalker),
and a class for the thread that drives the networking (e.g. NetworkPump),
which would call all the other code.

That particular design lends itself well to writing real servers, not
just benchmark specials. I used something like it for the keyserver
at Disappearing, Inc. The idea is to put all the state related to a
protocol command into a class rather than leaving it scattered across the stack
This lets you accept a protocol data unit from the client,
then ship it as a whole around to different parts of your program easily.
For instance, you could have a three-stage pipeline:
* a network thread accepts commands from all clients, then ships them off to ...
* a disk thread, which handles disk I/O for all clients; since disk I/O usually
blocks,
it's important to not do this in the network thread; when the disk I/O is
done,
the command struct is filled in with the result, and shipped off to ...
* the network thread again, which will transmit the result back to the client.
More complicated pipelines are easy to assemble and useful in some
circumstances.

The approach is just as applicable on the client side. In the real world,
programs often act as both clients and servers, so using the same architecture
for both sides makes life easier. Especially when writing benchmark load test
clients!

This kind of architecture is described by Matt Welsh at
http://www.cs.berkeley.edu/~mdw/proj/seda/

But that's all just so much hot air, as I dunno when I'd do it.
For the moment, my code only does FTP, and isn't designed terribly well.

Good luck with your thesis project! Let me know how you decide to approach it.

- Dan

--
"I have seen the future, and it licks itself clean." -- Bucky Katt