Bots

Bots can be thought of as simple system components designed to do simple things. I’d like to present an example my physics teacher had given us once;

An exemplary system is no more than a system that regulates temperature using a sensor, such as a heat-regulator commonly found in cold-climate houses. A simple tension spring reacting to the temperature is sufficient to “program” the thermostat on user-controlled triggers.

The same can, and should, be said about Bots. Keep it simple and stupid should be the mantra of choice when designing bots. Last time I mention it.

Back in the 80s, Bots were developed for chat forums (IRC), and perhaps firstly for the BBS platform, my memory isn’t all that good now. (Bulletin Board Systems, that which existed before the Internet, ie; that old noisy modem that allowed you to dial in a friendly node over phone for a digital conversation, like in the movie Wargames).

Simple chat bots allow you to program a set of conversational, or functional responses to incoming messages. Someone says “hi!”, and the Bot picks it up, figures an answer from a pre-conceived table of messages and responds “hello! How are you?”

The real kicker concept with Bots was the client-server architecture that Bots had to function with. Today, with the Internet, this concept is much better known to the general programming crowd, and even non-programmers. Furthermore, some programming libraries and languages offer easy constructs to build bots and encapsulate the client-server concepts.

Today, it has become as easy to program a bot to act locally as to act remotely. That’s what I mean. Bots can launch browsers, remote connections, transfer files over SSH, encrypt data using a variety of command line tools, open sockets, cause mayhem and ultimately, cause an infinite loop that brings your system to a screeching halt. I digress, but my point is, bot programming is a hacker’s skill first. It only became a system administration tool out of necessity. And I dare say a good number of system administrators have shied away from hacker tools since day 1. This is a prejudice to the technology, and a very big misconception for the industry that calls itself innovative. They’ll get hacked so bad, they won’t believe it, by an army of bots, and most of them won’t understand how or why they function.

So, Bots are not necessarily “automated” by their nature. In fact, in ancient computer times, Bots were either event-driven (responding to a message) or built around a command execution loop (while nothing happens, keep listening for something that triggers us).

But today, how we implement a Bot framework matters relatively little. For one, the Bot’s purposes will dictate the best methodology, and its peers or methods of transferring data will dictate how best to apply the “timing” to it.

The most basic ways of launching Bots would be using a crontab entry or the task scheduler under Windows. I personally like to keep my bots small and nimble, and that includes short-lived. All programming languages eventually leak memory, so keeping processes running 24hours a day is asking for a crash dump, exceptionally on Windows.

So, keeping the Bots small and nimble is an effective way of keeping the machine running a long time. Anyways, it just makes more sense to make short-lived bots for the error response that remains as important as a successful execution. Different concerns arise with load management, we’ll cover that as well.

---