Command line version.

[sgbotsford]

I'd like a command line version of this. Otherwise I'll close the window by mistake, and then I won't get results, because it won't be running.

Ideally I'd something like:

testmynet

-u {string} username (required)

-c {string} connection name (required)

-l {pathname} path/to/logfile

-n {number} number of times to run

-i {time unit } interval between runs. Interval is from the END of the previous run.

-j {time unit} jitter. Random variation in when to run.

-min {number} mininum data size

-max {number} maximum data size

-auto base size on history.

-s servername

-d {direction: up, down, both}

The -j flag allows things like this:

testmynet -i 2:00 -j 0:30 this waits a random amount of time up to 30 minutes before running the test. If unspecified, j should default to something like 1/4 of the interval. This will prevent 5000 cron jobs all over the world hitting you at exactly 11 a.m.

If -i is set to zero, and n > 1 the tests will be back to back, but there is an implied -j of 1 minute per megabyte before the tests start.

The server can tell the client. "Busy now. Try in 5" and the client will wait 5 minutes and try again.

If you decide to do this, you also need some protection.

There are two risks:

1. Someone sets this up, and ignores it, and it runs whenever their machine is on. This is a mild waste of resources, except it's helping you build your database.

2. Some ISP who your records have really pissed off launches a DoS attack on you.

I would suggest something like this:

Set up dns records for tmn1.testmy.net tmn2.testmy.net qfmp.testmy.net

If you get hammered too hard, change the server names, or disable that user. By having a yearly server name change and announcing it on your site, you filter out risk #1.

I would also have a firewall setup that would allow me to block connections from an abusive player at the first SYN packet. pf, under any of the BSD unixes can be set up to do this.

An additional feature to prevent abuse.

Require the client to perform a complex calculation. This should be time consuming enough that it becomes unreasonable to run multiple copies of the client program.

testmynetclient: I want to run a test.

server:Very well, here is your challenge.

client: goes away and calculates for a while.

client: Here is the response to your challenge

server: go ahead. What are the test parameters?

Examples of difficult calculations:

Given the seed as the starting string into md5, what is the millionth iteration feeding each output of md5 as the seed for the next call. (It may have to be billionth -- you want the computational time to be comparable to the download time on an average connection.)

At your end you have to make the same calculations -- but you can save your results.

So pick a seed. Iterate it a billion times, but record all the results. (You could save space by recording only every thousanth result.)

When a client attaches you pick it's seed from the file, then look 1 million lines later for the expected reply.

The client can be programmed to have a wait call during each iteration. This will mean that the client won't annoy the client's owner, sucking up too many cpu cycles. This would allow you to reduce the number of required iterations.

You also set it up so that the server will not accept multiple connections from one IP address. This may be a problem with NATed networks.