Subj : BBS architecture questions To : BBS Coder From : Digital Man Date : Sun Nov 06 2022 14:20:57 Re: BBS architecture questions By: BBS Coder to alt.bbs.synchronet on Sat Nov 05 2022 03:51 pm > From Newsgroup: alt.bbs.synchronet > > I have a few development-related questions, not explicitly about SBBS, but > the architecture of SBBS and other BBSs in general (mainly for Digital Man, > but any insights welcome). > I've been contemplating writing my own BBS software for a while, from the > ground up, in order to better accomplish certain objectives. I have a custom > board that's mainly a hacked hodge podge of shell scripts that I haven't > touched in years... at the time I wasn't interested in writing a real BBS > but I think it makes more sense now. SBBS is neat as well but I'd like to > write something of my own. > As background, I have a fair amount of C development experience working on > large, multi-threaded programs, sockets, shared object modules, > pseudoterminals, etc - a lot of the relevant systems programming. However, > I'm a bit stuck on conceiving the optimal architecture for something like > this, or how SBBS is architected. Synchronet is open source. You shouldn't be "stuck" with regards to determining how its architected. There is a (Windows-centric) architecture diagram here however: https://wiki.synchro.net/dev:architecture > I'm familiar with server processes that > run as a daemon where other "client" processes can connect to it using a > socket (commonly Unix domain socket) to get a "remote" console (remote as in > remote to the actual daemon process). Well unix domain sockets are "local", not "remote", but okay. > Each TTY is handled by a separate > "remote" process communicating with the daemon process via a socket, and the > daemon process has all the actual logic, loads all the dynamic modules, etc. This isn't any architecture I'm familiar with. > One thing I'd like to preserve is being able to dynamically reload modules. > If you have a single daemon process loading modules, you can dlclose and > dlopen them again and basically hot reload part of your program. The client > processes don't touch that, so you can reload functionality while the > program is running and users are connected. > I'm not 100% sure how this best translates into the BBS world. If you take > something like ncurses, ncurses really does not like multithreaded programs > (I know there is a version that supports it, but it's really not a widely > supported configuration). So I'm questioning the aspect of "everything" > actually being in a single process, and wondering if there's some other > architecture programs like SBBS, for good reason, that works better. SBBS v3 runs as a single multi-threaded process. It doesn't use ncurses within that process. > I've browsed through a lot of source code, and I understand some different > things that are going on, but SBBS is so large that I haven't gotten a crisp > understanding of everything this way. So kind of at a high level, I'm > curious if you could discuss a little bit about some of the following > things: > - Client server model: process/thread hierarchy, how remote > TTYs/pseudoterminals interact with the main server process (what processes > and threads are involved for a TTY) The servers are part of a monolithic process (not client/server) that includes several TCP servers. > - Usage of sockets vs. pseudoterminals in SBBS Pseudoterminals aren't used. > - How ncurses is used (all in one thread, all in separate processes, etc.) It's not. > As a specific example, say a new client connects (say via telnet), so the > SBBS telnet thread/process spawns a new thread/process for that, and the > main process gets a handle to the slave PTY. SBBS does not use a PTY in this way. > (I have to imagine the PTY is > needed, as opposed to just a Unix domain socket). SIGWINCH is per-process, > so now you have SIGWINCH going to the entire main process on a resize > (ouch?). And if you want to run ncurses, unlike normal text I/O, you can't > just do that in the threads in the main process handling the remote clients. The SBBS terminal server doesn't run/use ncurses. > Obviously I'm sure that's not quite how SBBS works but an example of things > I've been pondering. > Again, I'm not asking about how to program anything specifically, just > looking for some thoughts and explanation on the architecture itself. Sorry > if these questions are a little windy, but I think any insight you might > have would really help, and the rest will probably make more sense at that > point... Thanks! No problem! -- digital man (rob) This Is Spinal Tap quote #24: David St. Hubbins: You're a haughty one, saucy Jack. Norco, CA WX: 70.6øF, 43.0% humidity, 2 mph ESE wind, 0.00 inches rain/24hrs --- SBBSecho 3.15-Linux * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705) .