BBS Software for Raspberry Pi

-=> Paul Hayton wrote to All I run a retro BBS using Mystic BBS software. The author of the software PH> has been actively developing it for the last 15+ years. I thought I'd PH> post here to let anyone interested in BBSing that there is a Raspberry PH> Pi (ARM) version of Mystic available from mysticbbs.com

PH> Be sure to use the latest 1.12 Alpha, it's far more developed and PH> robust than the much earlier 1.11 release.

Yep yep yep! :)

... A man with an erection is in no need of advice. ___ MultiMail/Linux v0.50

On 12/04/17, robert wolfe pondered and said... rw> Yep yep yep! :) rw>

:) :) ... I feel I have read that somewhere before... wait a minute that's the kind of thing I'd say :)

Best, Paul

On 01/29/18, Diesel pondered and said... Di> Di> A blast from the past. :) I thought it was more than fifteen years Di> old though, alas.

nope its 2018 and still under active development. :-)

Best, Paul

`I'm not expendable, I'm not stupid, and I'm not going' - Kerr Avon, Blake's 7

Early 80s at 300 baud. Computer club BBS and Compuserve. I was able to pay bills through Huntington Bank connection in Compuserve.

CompuServe... I remember it! I still have its deep blue T-Shirt. :)

That would be a worthwhile project. You might want to use SSH, though.

Many of the functions of BBSes have been taken over by Facebook. This is unfortunate, since Facebook is a monopoly, while the BBSes of yore were independent.

Some web sites let you leave comments, which provides a lot of BBS functionality. Others, however, insist that you post via Facebook. Since I refuse to get a Facebook account, this deprives them of my pearls of wisdom. :-)

On Thu, 22 Feb 2018 12:56:11 -0500, Seymore4Head declaimed the following:

Would depend upon how the BBS software "answers" in coming calls.

In the time of the ancients, BBS software was connected to banks of modems (each having a phone line), and (hypothetical -- I've not looked at any such code) had pending threads (or a coroutine design) for each modem waiting for a login attempt; after which it would process the connection until a logoff or time-out, whereupon it would return to the pending connection state.

Concurrency would be limited to the number of modems. Each modem handler would loop: wait for login attempt; validate login; loop processing commands; return to top of outer loop on logout or timeout [probably long timeout to allow for slow human interaction, or some disconnect signal from the modem].

Conversion to Telnet/SSH basically means the "wait for login attempt" is a TCP/IP "accept" operation. After that, anything that can map TCP socket I/O to the equivalent of a serial modem stream should allow the rest of the code to remain unchanged.

I don't know if the AX.25 (Amateur Radio variant of X.25 Packet) is applicable -- in the 90s one still found AX.25 packet servers with email/BBS features. These days, AX.25 packet data seems to be relegated mostly to APRS (which is more UDP [unconnected broadcast] than TCP [point-to-point connection] style)

It would be tedious -- since the main idea behind HTTP is that EACH data transfer is independent and complete. Hence the need for either Cookies (which identify which transaction this transfer is associated with, and what stage that transaction is in) OR AJAX (running a Javascript program in the user's browser which is talking to a server and updating the browser "DOM" -- IE; writing a BBS client in Javascript that uses the browser to update the main browser window in place of loading new pages for every update).

Telnet/SSH/Serial would be all text based system, and might be dependent upon the client capability (can it handle ANSI escape sequences to clear screen, move cursor... etc.) but should be functional on a minimal system (remember printing terminals? -- a screen update would be scrolling a full screen of data, but still doable). A BBS specific client might be smart enough to buffer entire messages, and allow the user to scroll back and forth locally without having the server resend lines. The smartest clients would act similar to NNTP clients -- downloading all new messages to local storage, allowing the user to read/respond to those message while not connected, and then send all responses on the next connection {This is how the Aladdin clients for GEnie functioned -- since one was billed by connection time, no one wanted to read the messages while connected -- connect, spend 5 minutes transferring pending data, disconnect... Spend an hour reading/responding.}

UGH! this means one need a permanent connection, and one is basically acting on a per-message basis -- every change of message means hitting the server machine and transferring a packet.