BBS systems, file transfer protocols, design issues - Nostalgic moment, good old times

Post date: Jan 22, 2012 7:04:19 AM

Today some protocol discussion in one forum reminded my self about old good times as SysOp of BBS system.

Systems and protocols like: PCBoard, FidoCom, Rcom, Opus, SBBS, QBBS and file transfer protocols like Kermit, Xmodem, Ymodem, Zmodem, Smodem, HS/Link, BiModem and Hydracom came right back to my mind. Also with all their design issues.

BBS systems

PCBoard used index and message data files per board, it was pretty good design. FidoCom and Rcom stored each message in separate file, which was really bad thing for larger systems because of fat 16 limited number of files on disk. This also made collecting messages for QWK or BlueWave off-line message reader formats very slow.

SBBS and QBBS used one message database file for all messages. It caused huge problems when systems were connected to global fidonet, which replicated messages to systems all over the world. I assume that the designers of the system never realized how many messages there actually could be and therefore they used 16 bit message id. Maximum number of messages in database could be only 65536 messages. That caused message backlog to be really short for very active systems. Of course that was huge number of messages if you thought to have local system, with only one phoneline and single user at time. That is exactly how times change. When you design something, design it so that it won't run out. Eh, like IPv4. Benefits of having all messages in single file with index was that picking required messages for off-line reading was really super fast compared to other designs I mentioned ealier which required opening large number of individual files instead of using fast seeks in file.

File transfer protocols

HS/Link was near perfect with bidirectional transfers and full streaming. Except it didn not use adaptive block size. This critical issue caused big block size to discard almost all data on noisy line. Of course smaller block size could have been chosen when starting transfer. But if line was good using small block size was really inefficient. So lack of automatic adaption to line conditions made this protocol unusable at least for me.

Zmodem was nice, but it didn't have fully streaming error correction (causing every error to stop transfer and discard lots of perfectly good data.) BiModem just wasn't supported by any systems as well as Hydracom was poorly supported. But then came Smodem which was simply great. With adaptive blocksize and multiplexed simple ack/nak channels it was clearly superior to any other protocol implemented that far. Other older protocols like Xmodem were inefficient and also slow, no sliding window, simple single ack/nak syled transfer causing latency to cause wasted idle time. Smodem was actually so extremely good compared to competition that I was really bit sad that we didn't have it years before.

Modem protocols

Other protocols which were integrated to modem software directly came very familiar. v.42 error correction, v.42bis data compression and older MNP4 (EC) and MNP5 (DC). Not forgetting SREJ (Selective Reject) which allowed only corrupted frames to be resent. Working efficiently and very similarly (as end result) to Smodem, although technical approach and implementation was very different. Some terminal programs like Transend were able to implement MNP4 and MNP5 error correction and compression in terminal software, there fore you didn't need more expensive modem having those features. (1200 bps / 2400 bps era)

Terminal emulation

VT102 and ANSI were ruling terminal protocols for long time. But after that came Avatar, it was drastically faster and more efficient than those protocols. Which was especially needed for colorful SBBS systems. Avatar used one escape char and binary payload after that to give commands, so it was much more compact and efficient compared to ansicodes which were easily 5-10 characters long.

Some terminal apps I personally used: Kermit, ProComm, Transend, Telemate, Telix, Terminate.

End of BBS era

Well well, that was nice nostalgic moment. It was year 1995 when I completely stopped using BBS systems and Internet had fully replaced those for me as communication method. Some Finnish BBS continued running for a very long time after that. Most notable one was MikroBitti magazines PCBoard based system called MBnet. Also some BBS systems allowed connecting those over internet using telnet, but for me there was no reason to use those "closed and slow" systems anymore.

Want to read more? Check out: FidoNet, BBS, Zmodem, Smodem want broader description in form of documentary? Watch BBC's BBS documentary.