One minor nit about the projects use of autoconf / automake. Projects should please check the generated files into git. Sure, they're auto-generated. But 90% of the time when they're not in git, I discover that I have a different version of autoconf, and I can't even build "configure" in order to build the project.

The cost of a few more bytes in git is more than outweighed by the benefits of allowing people to use your software.

This is inherently wrong. Auto-generated files should NEVER be in git.

However, they should be in the stable release tarball.

How am I supposed to contribute to your project if the files required to build it are in one place (the tarball) but patches have to be made in another (the git repo)?

If your best practices require you to make potential users and contributors jump through hoops, then maybe those best practices are a bit shit.

I do not understand this debate. The project should decide on which autotools version to use and everyone contributing should make sure everything can be generated and installed with roughly the following:

> autoreconf -ivf

> ./configure

> make

> sudo make install

Well, not only that, autoconf and automake files themselves can set a minimum version.

For the problem case of "my version was old, but still executed, and produced a build system that wouldn't build", this has already been handled for a long long time.

But yeah, either autoreconf or explicit autogen.sh works.

If you intend to use the software, you should generally download a release. Releases usually (as is the case here) include the configure scripts.

Checking in build products is not about saving a couple bytes. It's about having a DRY codebase that isn't of out sync with itself.

TcpKali mascot is an example of great visual identity for open source projects: kawaii-touched fearsome ancient god zapping servers. It's both memorable visual symbol and an apt metaphor for core feature (load generation).

RJ-45 connectors with a skull hanging from the neck and a latte cup are just cherries on top.

To give credit where the credit is due: the mascot was created by a great graphical designer - Tatyana Alexandrova (https://twitter.com/Alextanya)

Surprised to see the name and image in the site. If you're wondering about the name and the image there, "Kali" is the Hindu goddess and the image depicts her. https://en.wikipedia.org/wiki/Kali

Yes, I initially thought this was a part of the pen-testing linux distribution[0] also named Kali.

[0] https://www.kali.org/

My association with this name is the IPX over Internet app that was around in the 90s to play things like Doom over the internet. Strange :)

https://en.wikipedia.org/wiki/Kali_%28software%29

Is there a way to specify a sequence of messages every connection should send? Preferably even let it randomize it (want to load test a game with real input, not just set up the connection).

-m 'foo' -m 'bar' is one way. --message-file <filename1> --message-file <filename2> is another way.

You can randomize input somewhat by using \{connection.id % 100} expressions right in the -m and within the files.

But yes, tcpkali can do simple randomizations, but does not support full-blown scripting. For that, consider using http://github.com/machinezone/mzbench or other alternatives.

Something like Gattling or Artillery.io would probably be better for this use case. TcpKali looks good but purposed more for benchmarking servers than actual apps.

What is the best way to prevent tools like this from ddossing a simple sockets.io server?

Put a haproxy in front that does the rate-limiting and connection tracking.

abstinence ?

it has flags to tailor the number of connections, bandwidth, message rate, etc. or are you speaking to malicious use?