How do Bulletin Board Systems work? [closed]

Question

Recently, I've been very interested in old-school bulletin board systems (BBS) from the 90s. I'm interested in building my own (mostly as just a fun challenge), but to be honest, I'm not totally sure where to begin. I was wondering if anyone knew of any resources out there on the web that maybe have details how these things operate.

From a lot of BBSs I've been on, it seems like a lot of them use some kind of TUI to output information and menus to the user. I also would have no clue how to link Door Games/MUDS to my software.

I'm relatively experienced with programming, but not as experienced dealing with stuff like sending data over telnet, and how that protocol works, so if anyone could point me in the right direction or have any resources on how the older BBSs were built, that would be great!

Any help is much appreciated! :D

Answer 1

Back before the Internet, BBS systems were accessed by dialup modem connections. The caller would dial the phone number of the BBS, where it would connect to a modem (and then to the computer through the modem serial port).

A simple BBS might have one phone line, so only one caller could connect at any given time. If the phone line was busy, you would try again later.

A larger system might have more than one phone line, and therefore more than one modem. Sometimes the BBS operator would install extra serial port cards in a single computer to control multiple modems, or other systems would have one modem per computer and the computers would talk to each other via a LAN.

If there was more than one phone line, a simple setup would have different phone numbers to call for each line. A more sophisticated setup would have a single "rollover" number set up with the phone company which would automatically find the next available line.

The software running on the BBS would communicate with the caller through the serial port. To draw screens, the BBS would send ANSI escape codes which pretty much all terminal programs (that's the software the caller runs) supported. The BBS could then move the cursor around, draw lines, use colours, etc.

A "door game" was a separate program from the main BBS. When the caller chose to enter a door game, the BBS would effectively unload itself, and run the door game program, telling it to communicate with the same serial port. The BBS would be out of the picture for a while, until the caller chose to exit the door game and return to the BBS.

With the advent of the Internet, all this changed because you no longer needed a point-to-point modem connection for each caller. Many callers could simultaneously connect over the same net connection. Of course, the BBS software had to change a bit to accommodate this new way of working, and the whole mechanism that door games were run had to change too.

There are a handful of traditional BBS systems still out there today, but I doubt any of them actually support dialup modem connections. They probably all support telnet connections, using appropriate software that actually understands the internet.

I'm not sure whether there are any particular resources I could point you to, but I happen to know a thing or two about doing this from writing BBS systems a few decades ago.

Answer 2

Preface: That question is not only way to broad, but also not RC related in any way. A BBS is, per se, not more retro than word processing or a GUI. To make it retro, some genuine product from back then would need to be incorporated - and the question being about that, not generic.

---

Having said that, it feels as there is a very specific misconception about a BBS as being something special. But it isn't.

A BBS is a standard user program acting with its user.

There is no principal difference if the terminal is connected directly to the serial port of that machine, or via a modem. Depending on the modem setup, it might not even have to know about (*1). Of course, it may help. So a BBS program is nothing else than some application to access to the data stored via whatever user interface the programmer has in mind. Menu driven, command line or some weird control codes, pick your favourite.

Maybe think of it as a shell.

Doing the same via Telnet is no difference except for the programming interface. If at all. For example when using Unix, one can write a BBS application complete agnostic, by just reading from standard input and writing to standard output. BBS users get your BBS application set as shell in their /etc/passwd entry. Using this way even adds multi user capabilities.

Or go the 'hard' way and replace getty for all modem interfaces by your application. Now you can manage users on your own and don't have to add each as system user. For Telnet it's mostly the same, just a bit more configuration magic (like entries /etc/services and so on).

On non-Unix-systems it's no difference. Sure, if you want to support multiple lines under a non-multitasking system you may have to add some thought about managing concurrent interfaces and sessions. But that's no big deal either. The application itself will be way more code than a user or process management.

Bottom line: To write a BBS, write a program doing the interface and processing and offer it to the world.

---

*1 - Basic modems communicate over RS232/V.24 signal lines to signal and accept a call or hang up. So if these signals are handled correctly by the serial driver, any application can be operated remote. Smart modems (Hayes et.al.) can be even set up to take of more complicated load than answering.